All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Waiman Long <longman@redhat.com>,
	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>
Cc: linux-mm@kvack.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Tue, 07 Apr 2020 06:41:23 +0000	[thread overview]
Message-ID: <07e49a285eff9a22476c6b1c396485f6d5d39002.camel@perches.com> (raw)
In-Reply-To: <1e4a6174-04be-6c05-fd6e-b43fefd317fc@redhat.com>

On Mon, 2020-04-06 at 22:16 -0400, Waiman Long wrote:
> On 4/6/20 3:38 PM, Joe Perches wrote:
> > On Mon, 2020-04-06 at 14:58 -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.
> > [] 
> > >  extern void kvfree(const void *addr);
> > > +extern void kvfree_sensitive(const void *addr, size_t len);
> > Question: why should this be const?
> > 
> > 2.1.44 changed kfree(void *) to kfree(const void *) but
> > I didn't find a particular reason why.
> 
> I am just following the function prototype used by kvfree(). Even
> kzfree(const void *) use const. I can remove "const" if others agree.

No worries.  Nevermind me...

Lots of warnings if allocated pointers are const, so const is necessary
in the definition and declaration.

struct foo {
	...
};

struct bar {
	const struct foo *baz;
	...
};

some_func(void)
{
	bar.baz = kvalloc(...);
}

kvfree can't free bar.baz if it's defined with void * without warning,
so it must be const void *.

Apologies for the noise.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Waiman Long <longman@redhat.com>,
	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>
Cc: linux-mm@kvack.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Mon, 06 Apr 2020 23:41:23 -0700	[thread overview]
Message-ID: <07e49a285eff9a22476c6b1c396485f6d5d39002.camel@perches.com> (raw)
In-Reply-To: <1e4a6174-04be-6c05-fd6e-b43fefd317fc@redhat.com>

On Mon, 2020-04-06 at 22:16 -0400, Waiman Long wrote:
> On 4/6/20 3:38 PM, Joe Perches wrote:
> > On Mon, 2020-04-06 at 14:58 -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.
> > [] 
> > >  extern void kvfree(const void *addr);
> > > +extern void kvfree_sensitive(const void *addr, size_t len);
> > Question: why should this be const?
> > 
> > 2.1.44 changed kfree(void *) to kfree(const void *) but
> > I didn't find a particular reason why.
> 
> I am just following the function prototype used by kvfree(). Even
> kzfree(const void *) use const. I can remove "const" if others agree.

No worries.  Nevermind me...

Lots of warnings if allocated pointers are const, so const is necessary
in the definition and declaration.

struct foo {
	...
};

struct bar {
	const struct foo *baz;
	...
};

some_func(void)
{
	bar.baz = kvalloc(...);
}

kvfree can't free bar.baz if it's defined with void * without warning,
so it must be const void *.

Apologies for the noise.



WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Waiman Long <longman@redhat.com>,
	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>
Cc: linux-mm@kvack.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects
Date: Mon, 06 Apr 2020 23:41:23 -0700	[thread overview]
Message-ID: <07e49a285eff9a22476c6b1c396485f6d5d39002.camel@perches.com> (raw)
In-Reply-To: <1e4a6174-04be-6c05-fd6e-b43fefd317fc@redhat.com>

On Mon, 2020-04-06 at 22:16 -0400, Waiman Long wrote:
> On 4/6/20 3:38 PM, Joe Perches wrote:
> > On Mon, 2020-04-06 at 14:58 -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.
> > [] 
> > >  extern void kvfree(const void *addr);
> > > +extern void kvfree_sensitive(const void *addr, size_t len);
> > Question: why should this be const?
> > 
> > 2.1.44 changed kfree(void *) to kfree(const void *) but
> > I didn't find a particular reason why.
> 
> I am just following the function prototype used by kvfree(). Even
> kzfree(const void *) use const. I can remove "const" if others agree.

No worries.  Nevermind me...

Lots of warnings if allocated pointers are const, so const is necessary
in the definition and declaration.

struct foo {
	...
};

struct bar {
	const struct foo *baz;
	...
};

some_func(void)
{
	bar.baz = kvalloc(...);
}

kvfree can't free bar.baz if it's defined with void * without warning,
so it must be const void *.

Apologies for the noise.




  reply	other threads:[~2020-04-07  6:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 18:58 [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects Waiman Long
2020-04-06 18:58 ` Waiman Long
2020-04-06 19:38 ` Joe Perches
2020-04-06 19:38   ` Joe Perches
2020-04-06 19:38   ` Joe Perches
2020-04-07  2:16   ` Waiman Long
2020-04-07  2:16     ` Waiman Long
2020-04-07  6:41     ` Joe Perches [this message]
2020-04-07  6:41       ` Joe Perches
2020-04-07  6:41       ` Joe Perches
2020-04-07 20:16   ` Linus Torvalds
2020-04-07 20:16     ` Linus Torvalds
2020-04-07 20:16     ` Linus Torvalds
2020-04-07 20:26     ` Linus Torvalds
2020-04-07 20:26       ` Linus Torvalds
2020-04-07 20:26       ` Linus Torvalds
2020-04-07 21:14     ` David Howells
2020-04-07 21:14       ` David Howells
2020-04-07 21:22       ` Linus Torvalds
2020-04-07 21:22         ` Linus Torvalds
2020-04-07 21:22         ` Linus Torvalds
2020-04-07 22:24       ` Matthew Wilcox
2020-04-07 22:24         ` Matthew Wilcox
2020-04-07 22:54       ` David Howells
2020-04-07 22:54         ` David Howells
2020-04-07 23:50         ` Linus Torvalds
2020-04-07 23:50           ` Linus Torvalds
2020-04-07 23:50           ` Linus Torvalds
2020-04-06 20:00 ` Matthew Wilcox
2020-04-06 20:00   ` Matthew Wilcox
2020-04-07 20:07   ` Waiman Long
2020-04-07 20:07     ` Waiman Long
2020-04-07 20:01 ` Waiman Long
2020-04-07 20:01   ` Waiman Long
2020-04-07 20:02   ` Waiman Long
2020-04-07 20:02     ` 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=07e49a285eff9a22476c6b1c396485f6d5d39002.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jmorris@namei.org \
    --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.