[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgyt8j5rEnyKE8YdrRjQof1kvyom1CensTE0-Bp-meGnA@mail.gmail.com>
Date: Mon, 6 Apr 2020 10:11:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Joe Perches <joe@...ches.com>
Cc: David Howells <dhowells@...hat.com>,
Waiman Long <longman@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Linux-MM <linux-mm@...ck.org>, keyrings@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: Add kvfree_sensitive() for freeing sensitive data objects
On Mon, Apr 6, 2020 at 9:44 AM Joe Perches <joe@...ches.com> wrote:
>
> Dubious assertion. Both end up with zeroed memory.
You don't understand the function.
You ignored the part where the zeroed memory isn't even the _point_.
Yes, for kzalloc() it is. There the zero is inherent and important.
People very much depend on it, and it's the whole point of that
function. The 'z' is not silent.
But for kzfree() it really really isn't. There the zeroing is never
going to be seen by anybody wjho does the right thing, and is not
important at all - it's purely a "let's make sure old contents don't
leak".
The "zero" part is completely immaterial, it could just as well have
been a "memset(0xaa)" instead.
And you didn't seem to understand that kzfree() shouldn't use memset()
in the first place, so it's not even using the same operation.
You really don't seem to get the whole "kzfree() has absolutely
_nothing_ to do with kzalloc() apart from a dubious implementation
details".
Should you name all global variables with a 'z' in their name
somewhere? They start out zeroed too - so pretty much according to
your logic, they are exactly the same as 'kzalloc()'.
Linus
Powered by blists - more mailing lists