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: <20ef1d3a-2916-ce00-2938-3397746efac9@redhat.com>
Date:   Mon, 17 Dec 2018 10:44:36 -0500
From:   Joe Lawrence <joe.lawrence@...hat.com>
To:     Miroslav Benes <mbenes@...e.cz>,
        Nicholas Mc Guire <hofrat@...dl.org>
Cc:     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 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?


[1]
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noclone-function-attribute


Thanks,

-- Joe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ