linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Joe Perches <joe@perches.com>
Cc: dhowells@redhat.com, Waiman Long <longman@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-mm@kvack.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Mon, 06 Apr 2020 17:00:40 +0100	[thread overview]
Message-ID: <319765.1586188840@warthog.procyon.org.uk> (raw)
In-Reply-To: <a291cce3ff1ba978e7ad231a8e1b7d82f6164e86.camel@perches.com>

Joe Perches <joe@perches.com> wrote:

> > This patch introduces a new kvfree_sensitive() for freeing those
> > sensitive data objects allocated by kvmalloc(). The relevnat places
> > where kvfree_sensitive() can be used are modified to use it.
> 
> Why isn't this called kvzfree like the existing kzfree?

To quote Linus:

	We have a function for clearing sensitive information: it's called
	"memclear_explicit()", and it's about forced (explicit) clearing even
	if the data might look dead afterwards.

	The other problem with that function is the name: "__kvzfree()" is not
	a useful name for this function. We use the "__" format for internal
	low-level helpers, and it generally means that it does *less* than the
	full function. This does more, not less, and "__" is not following any
	sane naming model.

	So the name should probably be something like "kvfree_sensitive()" or
	similar. Or maybe it could go even further, and talk about _why_ it's
	sensitive, and call it "kvfree_cleartext()" or something like that.

	Because the clearing is really not what even matters. It might choose
	other patterns to overwrite things with, but it might do other things
	too, like putting special barriers for data leakage (or flags to tell
	return-to-user-mode to do so).

	And yes, kzfree() isn't a good name either, and had that same
	memset(), but at least it doesn't do the dual-underscore mistake.

	Including some kzfree()/crypto people explicitly - I hope we can get
	away from this incorrect and actively wrong pattern of thinking that
	"sensitive data should be memset(), and then we should add a random
	'z' in the name somewhere to 'document' that".

David



  parent reply	other threads:[~2020-04-06 16:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06  2:37 [PATCH] mm: Add kvfree_sensitive() for freeing sensitive data objects Waiman Long
2020-04-06  4:20 ` David Rientjes
2020-04-06 14:36   ` Waiman Long
2020-04-06 14:39     ` Matthew Wilcox
2020-04-06  7:44 ` David Howells
2020-04-06 23:20   ` David Rientjes
2020-04-06 14:32 ` David Howells
2020-04-06 14:40   ` Waiman Long
2020-04-06 15:45 ` Joe Perches
2020-04-06 16:00 ` David Howells [this message]
2020-04-06 16:10   ` Joe Perches
2020-04-06 16:41     ` Linus Torvalds
2020-04-06 16:42       ` Joe Perches
2020-04-06 17:11         ` Linus Torvalds
2020-04-06 17:20           ` Joe Perches
2020-04-06 17:26             ` Matthew Wilcox
2020-04-06 17:33             ` Linus Torvalds
2020-04-06 17:46               ` Joe Perches
2020-04-06 17:58     ` Waiman Long
2020-04-06 18:06       ` Linus Torvalds
2020-04-06 18:46         ` Joe Perches
2020-04-06 16:26   ` David Howells
2020-04-06 16:38     ` Joe Perches
2020-04-06 17:10     ` Joe Perches
2020-04-06 17:24       ` Matthew Wilcox
2020-04-06 17:26       ` Linus Torvalds
2020-04-06 17:51       ` David Howells
2020-04-06 17:58         ` Linus Torvalds

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=319765.1586188840@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jmorris@namei.org \
    --cc=joe@perches.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    /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).