From: Joe Perches <joe@perches.com>
To: David Howells <dhowells@redhat.com>
Cc: 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:10:20 +0000 [thread overview]
Message-ID: <dbfcbbd55c63fc87bfb31af3cae1b15e04d8a821.camel@perches.com> (raw)
In-Reply-To: <334933.1586190389@warthog.procyon.org.uk>
On Mon, 2020-04-06 at 17:26 +0100, David Howells wrote:
> Joe Perches <joe@perches.com> wrote:
>
> > While I agree with Linus about the __ prefix,
> > the z is pretty common and symmetric to all
> > the <foo>zalloc uses.
> >
> > And if _sensitive is actually used, it'd be
> > good to do a s/kzfree/kfree_sensitive/ one day
> > sooner than later.
>
> How much overhead would it be to always use kvfree_sensitive() and never have
> a kfree_sensitive()?
Another possibility:
Add yet another alloc flag like __GFP_SENSITIVE
and have kfree operate on that and not have a
kfree_sensitive at all.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: David Howells <dhowells@redhat.com>
Cc: 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 10:10:20 -0700 [thread overview]
Message-ID: <dbfcbbd55c63fc87bfb31af3cae1b15e04d8a821.camel@perches.com> (raw)
In-Reply-To: <334933.1586190389@warthog.procyon.org.uk>
On Mon, 2020-04-06 at 17:26 +0100, David Howells wrote:
> Joe Perches <joe@perches.com> wrote:
>
> > While I agree with Linus about the __ prefix,
> > the z is pretty common and symmetric to all
> > the <foo>zalloc uses.
> >
> > And if _sensitive is actually used, it'd be
> > good to do a s/kzfree/kfree_sensitive/ one day
> > sooner than later.
>
> How much overhead would it be to always use kvfree_sensitive() and never have
> a kfree_sensitive()?
Another possibility:
Add yet another alloc flag like __GFP_SENSITIVE
and have kfree operate on that and not have a
kfree_sensitive at all.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: David Howells <dhowells@redhat.com>
Cc: 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 10:10:20 -0700 [thread overview]
Message-ID: <dbfcbbd55c63fc87bfb31af3cae1b15e04d8a821.camel@perches.com> (raw)
In-Reply-To: <334933.1586190389@warthog.procyon.org.uk>
On Mon, 2020-04-06 at 17:26 +0100, David Howells wrote:
> Joe Perches <joe@perches.com> wrote:
>
> > While I agree with Linus about the __ prefix,
> > the z is pretty common and symmetric to all
> > the <foo>zalloc uses.
> >
> > And if _sensitive is actually used, it'd be
> > good to do a s/kzfree/kfree_sensitive/ one day
> > sooner than later.
>
> How much overhead would it be to always use kvfree_sensitive() and never have
> a kfree_sensitive()?
Another possibility:
Add yet another alloc flag like __GFP_SENSITIVE
and have kfree operate on that and not have a
kfree_sensitive at all.
next prev parent reply other threads:[~2020-04-06 17:10 UTC|newest]
Thread overview: 72+ 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 2:37 ` Waiman Long
2020-04-06 4:20 ` David Rientjes
2020-04-06 4:20 ` David Rientjes
2020-04-06 4:20 ` David Rientjes
2020-04-06 14:36 ` Waiman Long
2020-04-06 14:36 ` Waiman Long
2020-04-06 14:39 ` Matthew Wilcox
2020-04-06 14:39 ` Matthew Wilcox
2020-04-06 7:44 ` David Howells
2020-04-06 7:44 ` David Howells
2020-04-06 23:20 ` David Rientjes
2020-04-06 23:20 ` David Rientjes
2020-04-06 23:20 ` David Rientjes
2020-04-06 14:32 ` David Howells
2020-04-06 14:32 ` David Howells
2020-04-06 14:40 ` Waiman Long
2020-04-06 14:40 ` Waiman Long
2020-04-06 15:45 ` Joe Perches
2020-04-06 15:45 ` Joe Perches
2020-04-06 15:45 ` Joe Perches
2020-04-06 16:00 ` David Howells
2020-04-06 16:00 ` David Howells
2020-04-06 16:10 ` Joe Perches
2020-04-06 16:10 ` Joe Perches
2020-04-06 16:10 ` Joe Perches
2020-04-06 16:41 ` Linus Torvalds
2020-04-06 16:41 ` Linus Torvalds
2020-04-06 16:41 ` Linus Torvalds
2020-04-06 16:42 ` Joe Perches
2020-04-06 16:42 ` Joe Perches
2020-04-06 16:42 ` Joe Perches
2020-04-06 17:11 ` Linus Torvalds
2020-04-06 17:11 ` Linus Torvalds
2020-04-06 17:11 ` Linus Torvalds
2020-04-06 17:20 ` Joe Perches
2020-04-06 17:20 ` Joe Perches
2020-04-06 17:20 ` Joe Perches
2020-04-06 17:26 ` Matthew Wilcox
2020-04-06 17:26 ` Matthew Wilcox
2020-04-06 17:33 ` Linus Torvalds
2020-04-06 17:33 ` Linus Torvalds
2020-04-06 17:33 ` Linus Torvalds
2020-04-06 17:46 ` Joe Perches
2020-04-06 17:46 ` Joe Perches
2020-04-06 17:46 ` Joe Perches
2020-04-06 17:58 ` Waiman Long
2020-04-06 17:58 ` Waiman Long
2020-04-06 18:06 ` Linus Torvalds
2020-04-06 18:06 ` Linus Torvalds
2020-04-06 18:06 ` Linus Torvalds
2020-04-06 18:46 ` Joe Perches
2020-04-06 18:46 ` Joe Perches
2020-04-06 18:46 ` Joe Perches
2020-04-06 16:26 ` David Howells
2020-04-06 16:26 ` David Howells
2020-04-06 16:38 ` Joe Perches
2020-04-06 16:38 ` Joe Perches
2020-04-06 16:38 ` Joe Perches
2020-04-06 17:10 ` Joe Perches [this message]
2020-04-06 17:10 ` Joe Perches
2020-04-06 17:10 ` Joe Perches
2020-04-06 17:24 ` Matthew Wilcox
2020-04-06 17:24 ` Matthew Wilcox
2020-04-06 17:26 ` Linus Torvalds
2020-04-06 17:26 ` Linus Torvalds
2020-04-06 17:26 ` Linus Torvalds
2020-04-06 17:51 ` David Howells
2020-04-06 17:51 ` David Howells
2020-04-06 17:58 ` Linus Torvalds
2020-04-06 17:58 ` Linus Torvalds
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=dbfcbbd55c63fc87bfb31af3cae1b15e04d8a821.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=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 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.