All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	David Laight <David.Laight@aculab.com>,
	linux-kernel@vger.kernel.org,
	Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH v2 1/6] crypto: Use memzero_explicit() for clearing state
Date: Fri, 23 Oct 2020 14:53:29 -0700	[thread overview]
Message-ID: <20201023215329.GA180517@gmail.com> (raw)
In-Reply-To: <20201023204536.GB27708@gondor.apana.org.au>

On Sat, Oct 24, 2020 at 07:45:36AM +1100, Herbert Xu wrote:
> On Fri, Oct 23, 2020 at 08:56:04AM -0700, Eric Biggers wrote:
> >
> > When clearing memory because "it may be sensitive" rather than "it's needed for
> > the code to behave correctly", I think it's best to use memzero_explicit() to
> > make the intent clear, even if it seems that memset() is sufficient.  Also keep
> > in mind that support for compiling the kernel with LTO (link-time optimization)
> > is being worked on (and some people already do it), which results in more code
> > being optimized out.
> 
> The rule up until now has been that we only use memzero_explicit for
> stack variables.  At this point please don't convert anything else
> as it will cause too much churn.
> 
> If LTO did arrive we should do a global conversion.
> 

LTO is actively being worked on, now up to v6:
https://lkml.kernel.org/lkml/20201013003203.4168817-1-samitolvanen@google.com/
And in the real world it's already being used; the Android Compatibility
Definition Document strongly recommends enabling CFI, which depends on LTO.

It's doubtful that anyone will do a global conversion from memset() to
memzero_explicit(), as it's too hard to find all the places that should be
converted.  They are in lots of different subsystems; the crypto subsystem will
have the most, but not all.  We just need to fix as many as we can.  If you'd
like to do something more comprehensive than this patch, that would be great,
but I hope we don't wait forever for a global conversion that never happens.

FWIW, kfree_sensitive() (formerly kzfree) already got converted by
https://git.kernel.org/linus/8982ae527fbef170, and it wasn't really
controversial.  Some people even wanted Cc stable (which I disagreed with, but
it apparently made the final version).

- Eric

  reply	other threads:[~2020-10-23 21:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20 20:39 [PATCH v2 0/6] crypto: lib/sha256 - cleanup/optimization Arvind Sankar
2020-10-20 20:39 ` [PATCH v2 1/6] crypto: Use memzero_explicit() for clearing state Arvind Sankar
2020-10-22  4:36   ` Eric Biggers
2020-10-23 15:39     ` Arvind Sankar
2020-10-23 15:56       ` Eric Biggers
2020-10-23 20:45         ` Herbert Xu
2020-10-23 21:53           ` Eric Biggers [this message]
2020-10-29  7:00             ` Herbert Xu
2020-10-20 20:39 ` [PATCH v2 2/6] crypto: lib/sha256 - Don't clear temporary variables Arvind Sankar
2020-10-22  4:58   ` Eric Biggers
2020-10-23  3:17     ` Arvind Sankar
2020-10-20 20:39 ` [PATCH v2 3/6] crypto: lib/sha256 - Clear W[] in sha256_update() instead of sha256_transform() Arvind Sankar
2020-10-22  4:59   ` Eric Biggers
2020-10-20 20:39 ` [PATCH v2 4/6] crypto: lib/sha256 - Unroll SHA256 loop 8 times intead of 64 Arvind Sankar
2020-10-22  5:02   ` Eric Biggers
2020-10-23  3:12     ` Arvind Sankar
2020-10-23  3:16       ` Herbert Xu
2020-10-20 20:39 ` [PATCH v2 5/6] crypto: lib/sha256 - Unroll LOAD and BLEND loops Arvind Sankar
2020-10-22  5:02   ` Eric Biggers
2020-10-20 20:39 ` [PATCH v2 6/6] crypto: lib/sha - Combine round constants and message schedule Arvind Sankar
2020-10-20 21:36   ` David Laight
2020-10-21 15:16     ` Arvind Sankar
2020-10-22  4:34   ` Eric Biggers
2020-10-22  8:20     ` David Laight

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=20201023215329.GA180517@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=David.Laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=samitolvanen@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.