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.
