linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH 1/8] Replace memset() with memzero_explicit()
Date: Wed, 17 Nov 2021 07:01:45 +0100	[thread overview]
Message-ID: <YZSaybga3KV/fimg@kroah.com> (raw)
In-Reply-To: <CACXcFm=bPdoLqYHEUpeZEQEULVGW6ej4ESHX+vMdeGfvjc51tg@mail.gmail.com>

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@linuxfoundation.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

      reply	other threads:[~2021-11-17  6:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 11:25 [PATCH 1/8] Replace memset() with memzero_explicit() Sandy Harris
2021-11-16 11:49 ` Greg Kroah-Hartman
2021-11-16 11:50 ` Greg Kroah-Hartman
2021-11-16 12:52   ` Greg Kroah-Hartman
2021-11-17  3:08   ` Sandy Harris
2021-11-17  6:01     ` Greg Kroah-Hartman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YZSaybga3KV/fimg@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandyinchina@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).