All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>
Cc: 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: Wed, 06 May 2020 01:29:58 +0000	[thread overview]
Message-ID: <3be0ef1d-fe7f-6b02-d9c0-c6b750fd94f3@redhat.com> (raw)
In-Reply-To: <20200505133521.eb8901d0b92e09452191ab49@linux-foundation.org>

On 5/5/20 4:35 PM, Andrew Morton wrote:
> On Tue, 07 Apr 2020 21:21:57 +0100 David Howells <dhowells@redhat.com> wrote:
>
>> David Howells <dhowells@redhat.com> wrote:
>>
>>>>   			if (unlikely(key_data))
>>>> -				__kvzfree(key_data, key_data_len);
>>>> +				kvfree_sensitive(key_data, key_data_len);
>>> I think the if-statement is redundant.
>> Ah - I see that you explicitly wanted to keep it.
> Why's that?

There is a comment above it:

                 /*
                  * The key may change (unlikely) in between 2 consecutive
                  * __keyctl_read_key() calls. In this case, we reallocate
                  * a larger buffer and redo the key read when
                  * key_data_len < ret <= buflen.
                  */
                 if (ret > key_data_len) {
                         if (unlikely(key_data))
                                 __kvzfree(key_data, key_data_len);

key_data will be defined only if the unlikely case that the key increase 
in length between the 2 consecutive __keyctl_read_key() call and we have 
to enlarge the buffer and read the key again. I want to keep the 
unlikely() macro to emphasize the fact that this condition should not 
happen.

>> There's a good chance it'll get janitored at some point.
> Indeed.  Perhaps add a few little comments to explain the reasoning and
> to keep the janitorial fingers away?
>
I can reword the comment to make it more explicit and send a v4 if you 
think the current comment is not clear enough.

Cheers,
Longman

WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>
Cc: 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: Tue, 5 May 2020 21:29:58 -0400	[thread overview]
Message-ID: <3be0ef1d-fe7f-6b02-d9c0-c6b750fd94f3@redhat.com> (raw)
In-Reply-To: <20200505133521.eb8901d0b92e09452191ab49@linux-foundation.org>

On 5/5/20 4:35 PM, Andrew Morton wrote:
> On Tue, 07 Apr 2020 21:21:57 +0100 David Howells <dhowells@redhat.com> wrote:
>
>> David Howells <dhowells@redhat.com> wrote:
>>
>>>>   			if (unlikely(key_data))
>>>> -				__kvzfree(key_data, key_data_len);
>>>> +				kvfree_sensitive(key_data, key_data_len);
>>> I think the if-statement is redundant.
>> Ah - I see that you explicitly wanted to keep it.
> Why's that?

There is a comment above it:

                 /*
                  * The key may change (unlikely) in between 2 consecutive
                  * __keyctl_read_key() calls. In this case, we reallocate
                  * a larger buffer and redo the key read when
                  * key_data_len < ret <= buflen.
                  */
                 if (ret > key_data_len) {
                         if (unlikely(key_data))
                                 __kvzfree(key_data, key_data_len);

key_data will be defined only if the unlikely case that the key increase 
in length between the 2 consecutive __keyctl_read_key() call and we have 
to enlarge the buffer and read the key again. I want to keep the 
unlikely() macro to emphasize the fact that this condition should not 
happen.

>> There's a good chance it'll get janitored at some point.
> Indeed.  Perhaps add a few little comments to explain the reasoning and
> to keep the janitorial fingers away?
>
I can reword the comment to make it more explicit and send a v4 if you 
think the current comment is not clear enough.

Cheers,
Longman


  reply	other threads:[~2020-05-06  1:29 UTC|newest]

Thread overview: 53+ 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:09   ` Linus Torvalds
2020-04-07 20:19 ` David Howells
2020-04-07 20:19   ` David Howells
2020-04-07 20:24   ` Waiman Long
2020-04-07 20:24     ` Waiman Long
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 [this message]
2020-05-06  1:29       ` Waiman Long
2020-04-07 20:31 ` Joe Perches
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: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 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  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
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-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=3be0ef1d-fe7f-6b02-d9c0-c6b750fd94f3@redhat.com \
    --to=longman@redhat.com \
    --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=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.