linux-kernel - Re: [PATCH V2] livepatch: fix non-static warnings

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: <alpine.LSU.2.21.1812180956460.9644@pobox.suse.cz>
Date:   Tue, 18 Dec 2018 10:00:59 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Nicholas Mc Guire <der.herr@...r.at>
cc:     Joe Lawrence <joe.lawrence@...hat.com>,
        Nicholas Mc Guire <hofrat@...dl.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jessica Yu <jeyu@...nel.org>, Jiri Kosina <jikos@...nel.org>,
        Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] livepatch: fix non-static warnings

On Mon, 17 Dec 2018, Nicholas Mc Guire wrote:

> On Mon, Dec 17, 2018 at 10:44:36AM -0500, Joe Lawrence wrote:
> > On 12/17/2018 07:03 AM, Miroslav Benes wrote:
> > > Hi,
> > > 
> > > I'm sorry for being late to the party.
> > > 
> > > On Sun, 16 Dec 2018, Nicholas Mc Guire wrote:
> > > 
> > >> Sparse reported warnings about non-static symbols. For the variables
> > >> a simple static attribute is fine - for those symbols referenced by
> > >> livepatch via klp_func the symbol-names must be unmodified in the
> > >> symbol table - to resolve this the __noclone attribute is used
> > >> for the shared statically declared functions.
> > >>
> > >> Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> > >> Suggested-by: Joe Lawrence <joe.lawrence@...hat.com>
> > >> Link: https://lkml.org/lkml/2018/12/13/827
> > > 
> > > A nit, but I'd reorder the tags. Link, Suggested-by:, Signed-off-by:. Also 
> > > it would be great if you used https://lkml.kernel.org/r/${Msg-ID} 
> > > redirection.
> > > 
> > >> ---
> > >>
> > >> V2: not all static functions shared need to carry the __noclone
> > >>     attribute only those that need to be resolved at runtime by
> > >>     livepatch - so drop the unnecessary __noclone attributes as
> > >>     well as the Note on __noclone as suggested by Joe Lawrence
> > >>     <joe.lawrence@...hat.com> - thanks !
> > > 
> > > I talked to Martin Jambor (GCC) and he suggested __attribute__((used)). It 
> > > should be better than __noclone, which was reportedly implemented only for 
> > > testing purposes (which is why it does not imply noinline, although 
> > > inlining internally uses cloning). Newer gcc also has "noipa" attribute, 
> > > but "used" would definitely be safe.
> > > 
> > > Sorry for not responding earlier.
> > >
> > 
> > Hi Miroslav,
> > 
> > Thanks for following up on this. "noipa" would have been nice to use,
> > but as you say, is a newer gcc attribute.
> > 
> > Regarding "used" vs. "noclone", can we assume that "used" implies that
> > the function name remains unchanged?
> > 
> > The gcc online doc [1] speaks about ensuring that "code must be
> > emitted".  This reads like it solves our
> > static-function-not-directly-referenced problem, but isn't explicit
> > about naming.
> > 
> >     used
> > 
> >     This attribute, attached to a function, means that code must be
> >     emitted for the function even if it appears that the function is not
> >     referenced. This is useful, for example, when the function is
> >     referenced only in inline assembly.
> > 
> > Perhaps it's equivalent to a "I want to keep this function and leave
> > it's symbols alone" attribute.  FWIW, I modified Nicholas' change on my
> > box to use "used" and it worked as Martin advertised, so it would get my
> > Ack.
> > 
> > I'm just being picky about its documentation and how we should note its
> > usage in the v3 patch.  Think that s/__noclone/used/g of the v2 commit
> > message would be sufficient?
> >
> should that then not be  __used  as this is provided in compiler_attributes.h
> see also: https://lkml.org/lkml/2018/9/20/909

Yes, __used is better.

> also would it be reasonable to maybe add something like:
>   #define __livepatch         __attribute__((__noclone__, __noinline__))
> in compiler_attributes.h ? it would make it imediately clear that the attributes
> are related to the way lp works internally.

No, I don't think so. The samples (and selftests) are special in that we 
would like to provide minimal examples (or testcases). GCC is in the way 
due to its optimizations. It is not the case with the common code (the 
problem there is a bit different. Some optimizations are just dangerous 
for livepatching. However that is tangential to this patch and will be 
solved elsewhere).

Thanks,
Miroslav