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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 17 Nov 2021 07:01:45 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sandy Harris <sandyinchina@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH 1/8] Replace memset() with memzero_explicit()

On Wed, Nov 17, 2021 at 11:08:45AM +0800, Sandy Harris wrote:
> On Tue, Nov 16, 2021 at 7:51 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> 
> > Have you looked at the output of the compiler to see if this really is
> > needed or not?
> 
> No. To do that right you'd need to look at (at least) gcc & clang,
> multiple architectures (cross-compiled & native) & various levels
> of optimisation. I just looked at the C code.

You should at least look, right?

> > And what exactly are you zeroing out that could be read afterward
> > somehow?
> 
> Whatever it is, the person who wrote the code thought it was
> worth zeroing out with memset(). The only question is whether
> it is safer to use memzero_explicit().
> 
> Granted in many cases this will not matter unless the kernel
> is compiled at some optimisation level that does cross-function
> analysis so it might be "smart" enough to optimise out the
> memset(). Also granted it does not matter unless an attacker
> can look inside the running kernel & if  he or she has that
> level of privilege, then you have much else to worry about.

As Ard said, there should not be any such "optimization" as this is not
something that any non-broken compiler should do.

> Still, it seemed safer to me to use memzero_explicit() in
> these cases.

I do not see why these cases are any different than any other call to
memset() is, because this data is not on the stack so nothing should be
removed by the compiler, right?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ