[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YZSaybga3KV/fimg@kroah.com>
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