From: Eric Biggers <ebiggers@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
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>,
Joe Perches <joe@perches.com>,
Matthew Wilcox <willy@infradead.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Fri, 01 May 2020 23:22:24 +0000 [thread overview]
Message-ID: <20200501232224.GC915@sol.localdomain> (raw)
In-Reply-To: <20200407200318.11711-1-longman@redhat.com>
On Tue, Apr 07, 2020 at 04:03:18PM -0400, Waiman Long wrote:
> For kvmalloc'ed data object that contains sensitive information like
> cryptographic key, we need to make sure that the buffer is always
> cleared before freeing it. Using memset() alone for buffer clearing may
> not provide certainty as the compiler may compile it away. To be sure,
> the special memzero_explicit() has to be used.
>
> 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.
>
> Fixes: 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error on key read")
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Waiman Long <longman@redhat.com>
Looks good, feel free to add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
(I don't really buy the argument that the compiler could compile away memset()
before kvfree(). But I agree with using memzero_explicit() anyway to make the
intent explicit.)
I don't see this patch in linux-next yet. Who is planning to take this patch?
Presumably David through the keyrings tree, or Andrew through mm?
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
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>,
Joe Perches <joe@perches.com>,
Matthew Wilcox <willy@infradead.org>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Fri, 1 May 2020 16:22:24 -0700 [thread overview]
Message-ID: <20200501232224.GC915@sol.localdomain> (raw)
In-Reply-To: <20200407200318.11711-1-longman@redhat.com>
On Tue, Apr 07, 2020 at 04:03:18PM -0400, Waiman Long wrote:
> For kvmalloc'ed data object that contains sensitive information like
> cryptographic key, we need to make sure that the buffer is always
> cleared before freeing it. Using memset() alone for buffer clearing may
> not provide certainty as the compiler may compile it away. To be sure,
> the special memzero_explicit() has to be used.
>
> 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.
>
> Fixes: 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error on key read")
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Waiman Long <longman@redhat.com>
Looks good, feel free to add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
(I don't really buy the argument that the compiler could compile away memset()
before kvfree(). But I agree with using memzero_explicit() anyway to make the
intent explicit.)
I don't see this patch in linux-next yet. Who is planning to take this patch?
Presumably David through the keyrings tree, or Andrew through mm?
- Eric
next prev parent reply other threads:[~2020-05-01 23:22 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 20:03 [PATCH v3] mm: Add kvfree_sensitive() for freeing sensitive data objects Waiman Long
2020-04-07 20:03 ` Waiman Long
2020-04-07 20:09 ` Linus Torvalds
2020-04-07 20:09 ` Linus Torvalds
2020-04-07 20:19 ` David Howells
2020-04-07 20:19 ` David Howells
2020-04-07 20:21 ` David Howells
2020-04-07 20:21 ` David Howells
2020-04-07 20:21 ` David Howells
2020-05-05 20:35 ` Andrew Morton
2020-05-05 20:35 ` Andrew Morton
2020-05-06 1:29 ` Waiman Long
2020-05-06 1:29 ` Waiman Long
2020-04-07 20:24 ` Waiman Long
2020-04-07 20:24 ` Waiman Long
2020-04-07 20:31 ` Joe Perches
2020-04-07 20:31 ` Joe Perches
2020-04-07 20:45 ` Waiman Long
2020-04-07 20:45 ` Waiman Long
2020-04-07 21:01 ` Linus Torvalds
2020-04-07 21:01 ` Linus Torvalds
2020-04-07 21:24 ` Uladzislau Rezki
2020-04-07 21:24 ` Uladzislau Rezki
2020-04-07 21:30 ` Linus Torvalds
2020-04-07 21:30 ` Linus Torvalds
2020-04-07 22:12 ` Matthew Wilcox
2020-04-07 22:12 ` Matthew Wilcox
2020-04-08 0:35 ` Joe Perches
2020-04-08 0:35 ` Joe Perches
2020-04-08 13:38 ` Jarkko Sakkinen
2020-04-08 13:38 ` Jarkko Sakkinen
2020-05-01 23:22 ` Eric Biggers [this message]
2020-05-01 23:22 ` Eric Biggers
2020-05-04 2:57 ` Waiman Long
2020-05-04 2:57 ` Waiman Long
2020-05-14 11:00 ` Balbir Singh
2020-05-14 11:00 ` Balbir Singh
2020-05-14 12:00 ` Matthew Wilcox
2020-05-14 12:00 ` Matthew Wilcox
2020-05-14 12:08 ` Joe Perches
2020-05-14 12:08 ` Joe Perches
2020-05-17 0:27 ` Balbir Singh
2020-05-17 0:27 ` Balbir Singh
2020-05-17 0:44 ` Matthew Wilcox
2020-05-17 0:44 ` Matthew Wilcox
2020-05-18 2:39 ` Waiman Long
2020-05-18 2:39 ` Waiman Long
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=20200501232224.GC915@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--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=rientjes@google.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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 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.