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...]