Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/13/20 3:15 PM, Waiman Long wrote:
As said by Linus:

   A symmetric naming is only helpful if it implies symmetries in use.
   Otherwise it's actively misleading.

   In "kzalloc()", the z is meaningful and an important part of what the
   caller wants.

   In "kzfree()", the z is actively detrimental, because maybe in the
   future we really _might_ want to use that "memfill(0xdeadbeef)" or
   something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the
recently added kvfree_sensitive() and make the intention of the API
more explicit.

Seems reasonable to me. One bikeshed, that you can safely discard and ignore as a mere bikeshed: kfree_memzero or kfree_scrub or kfree_{someverb} seems like a better function name, as it describes what the function does, rather than "_sensitive" that suggests something about the data maybe but who knows what that entails. If you disagree, not a big deal either way.

> In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.

This had occurred to me momentarily a number of years ago, but I was under the impression that the kernel presumes extern function calls to always imply a compiler barrier, making it difficult for the compiler to reason about what happens in/after kfree, in order to be able to optimize out the preceding memset. With LTO, that rule obviously changes. I guess new code should be written with cross-object optimizations in mind now a days? [Meanwhile, it would be sort of interesting to teach gcc about kfree to enable additional scary optimizations...]



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux