On 4/6/20 12:10 PM, Joe Perches wrote: > On Mon, 2020-04-06 at 17:00 +0100, David Howells wrote: >> Joe Perches <joe@xxxxxxxxxxx> wrote: >> >>>> 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. >>> Why isn't this called kvzfree like the existing kzfree? >> To quote Linus: >> >> We have a function for clearing sensitive information: it's called >> "memclear_explicit()", and it's about forced (explicit) clearing even >> if the data might look dead afterwards. >> >> The other problem with that function is the name: "__kvzfree()" is not >> a useful name for this function. We use the "__" format for internal >> low-level helpers, and it generally means that it does *less* than the >> full function. This does more, not less, and "__" is not following any >> sane naming model. >> >> So the name should probably be something like "kvfree_sensitive()" or >> similar. Or maybe it could go even further, and talk about _why_ it's >> sensitive, and call it "kvfree_cleartext()" or something like that. >> >> Because the clearing is really not what even matters. It might choose >> other patterns to overwrite things with, but it might do other things >> too, like putting special barriers for data leakage (or flags to tell >> return-to-user-mode to do so). >> >> And yes, kzfree() isn't a good name either, and had that same >> memset(), but at least it doesn't do the dual-underscore mistake. >> >> Including some kzfree()/crypto people explicitly - I hope we can get >> away from this incorrect and actively wrong pattern of thinking that >> "sensitive data should be memset(), and then we should add a random >> 'z' in the name somewhere to 'document' that". > Thanks. > > 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. > > I have actually been thinking about that. I saw a couple of cases in the crypto code where a memzero_explicit() is followed by kfree(). Those can be replaced by kfree_sensitive. Cheers, Longman
