lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1904161453550.9803@cbobk.fhfr.pm>
Date:   Tue, 16 Apr 2019 14:54:44 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Petr Mladek <pmladek@...e.com>
cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH] livepatch: Enforce reliable stack trace as config
 dependency

On Tue, 16 Apr 2019, Jiri Kosina wrote:

> > Do you mean to convert the error into warning?
> > 
> > For example, the change below. Note that I did not mention
> > the possibility to force the transition by intention. It is risky
> > and people should not get used to it.
> > 
> > Heh, I think that this was the main reason why it was the error.
> > We did not want to get people used to forcing livepatches.
> > 
> > 
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index d1af69e9f0e3..8d9bce251516 100644
> > --- a/kernel/livepatch/core.c
> > +++ b/kernel/livepatch/core.c
> > @@ -1035,11 +1035,10 @@ int klp_enable_patch(struct klp_patch *patch)
> >  		return -ENODEV;
> >  
> >  	if (!klp_have_reliable_stack()) {
> > -		pr_err("This architecture doesn't have support for the livepatch consistency model.\n");
> > -		return -EOPNOTSUPP;
> > +		pr_warn("This architecture doesn't have support for the livepatch consistency model.\n");
> > +		pr_warn("Only one livepatch can be installed.\n");
> >  	}
> >  
> > -
> 
> This seems to have been lost.
> 
> I think we should take this aproach before Miroslav is ready with 
> realiable stack traces for s390. At the same time, I'd suggest issuing a 
> proper WARN() there instead of just pr_warn(). The kernel might be in a 
> potentially funky state, so let's at least get the 'W' taint in place.

Ignore the above, there is nothing wrong with the kernel unless the patch 
is forced.

So we should be good taking it as-is. Petr, could you please send it with 
proper changelog and signoff? Thanks,

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ