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:   Fri, 19 Aug 2022 22:55:42 +0800
From:   Menglong Dong <menglong8.dong@...il.com>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>, kuba@...nel.org,
        miguel.ojeda.sandonis@...il.com, ojeda@...nel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        asml.silence@...il.com, imagedong@...cent.com,
        luiz.von.dentz@...el.com, vasily.averin@...ux.dev,
        jk@...econstruct.com.au, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, kernel test robot <lkp@...el.com>,
        linux-toolchains <linux-toolchains@...r.kernel.org>
Subject: Re: [PATCH net-next v4] net: skb: prevent the split of
 kfree_skb_reason() by gcc

Hello,

On Fri, Aug 19, 2022 at 1:00 AM Segher Boessenkool
<segher@...nel.crashing.org> wrote:
>
> Hi!
>
> On Fri, Aug 19, 2022 at 12:31:44AM +0800, Menglong Dong wrote:
> > On Wed, Aug 17, 2022 at 11:54 PM Nick Desaulniers
> > <ndesaulniers@...gle.com> wrote:
> > > Perhaps noipa might also work here?
> >
> > In my testing, both 'noclone' and 'noipa' both work! As for the
> > '-fdisable-ipa-fnsplit', it seems it's not supported by gcc, and I
> > failed to find any documentation of it.
>
> noipa is noinline+noclone+no_icf plus assorted not separately enablable
> things.  There is no reason you would want to disable all
> inter-procedural optimisations here, so you don't need noipa.
>
> You need both noinline and no_icf if you want all calls to this to be
> actual function calls, and using this specific function name.  If you
> don't have noinline some calls may go missing (which may be fine for
> how you use it).  If you don't have no_icf the compiler may replace the
> call with a call to another function, if that does the same thing
> semantically.  You may want to prevent that as well, depending on
> exactly what you have this for.
>

Thanks for your explanation about the usage of 'noinline' and 'no_icf'!
I think 'noclone' seems enough in this case? As the function
'kfree_skb_reason' we talk about is a global function, I think that the
compiler has no reason to make it inline, or be merged with another
function.

Meanwhile, I think that the functions which use '__builtin_return_address'
should consider the optimization you mentioned above, and
I'll have a check on them by the way.

Thanks!
Menglong Dong

>
> Segher

Powered by blists - more mailing lists