linux-kernel - Re: [PATCH] livepatch: Enforce reliable stack trace as config dependency

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]

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