search for: kzfree

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

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

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

v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what...

...t can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer especi...

...t can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer especi...

This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer. Inste...

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

On Mon 15-06-20 21:57:16, Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() is currently used for the buffer clearing. However, > it is entirely possible that the compiler may choose to optimize away the > memory...

...gt; diff --git a/mm/slab_common.c b/mm/slab_common.c > index 23c7500eea7d..c08bc7eb20bd 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1707,17 +1707,17 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) > EXPORT_SYMBOL(krealloc); > > /** > - * kzfree - like kfree but zero memory > + * kfree_sensitive - Clear sensitive information in memory before freeing > * @p: object to free memory of > * > * The memory of the object @p points to is zeroed before freed. > - * If @p is %NULL, kzfree() does nothing. > + * If @p is %NULL,...

On 6/15/20 11:30 PM, Eric Biggers wrote: > On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote: >> The kzfree() function is normally used to clear some sensitive >> information, like encryption keys, in the buffer before freeing it back >> to the pool. Memset() is currently used for the buffer clearing. However, >> it is entirely possible that the compiler may choose to optimize away the...

The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for the buffer clearing. However, it is entirely possible that the compiler may choose to optimize away the memory clearing especially...

Last time you sent this we couldn't decide which tree it should go through. Either the crypto tree or through Andrew seems like the right thing to me. Also the other issue is that it risks breaking things if people add new kzfree() instances while we are doing the transition. Could you just add a "#define kzfree kfree_sensitive" so that things continue to compile and we can remove it in the next kernel release? regards, dan carpenter

...trfs/ioctl.c > index 40b729dce91c..eab3f8510426 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -2691,7 +2691,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp) > btrfs_put_root(root); > out_free: > btrfs_free_path(path); > - kzfree(subvol_info); > + kfree_sensitive(subvol_info); This is not in a sensitive context so please switch it to plain kfree. With that you have my acked-by. Thanks.

Waiman Long <longman at redhat.com> wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() "memset()" is all lowercase. > is currently used for buffer clearing. However unlikely, there is still a > non-zero probabili...

On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote: > In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc() > was incorrectly paired with kzfree(). According to David Sterba, there > isn't any sensitive information in the subvol_info that needs to be > cleared before freeing. So kfree_sensitive() isn't really needed, > use kfree() instead. > > Reported-by: David Sterba <dsterba at suse.cz> > Signed-off-by: W...

On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > v4: > - Break out the memzero_explicit() change as suggested by Dan Carpenter > so that it can be backported to stable. > - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for > now as there can be a bit more discussion on what is best. It will be > introduced as a separate patch

On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote: > On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote: > > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: > > > v4: > > > - Break out the memzero_explicit() change as suggested by Dan Carpenter > > > so that it can be backported to stable. > > > - Drop the

On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote: > On Tue 16-06-20 17:37:11, Matthew Wilcox wrote: > > Not just performance critical, but correctness critical. Since kvfree() > > may allocate from the vmalloc allocator, I really think that kvfree() > > should assert that it's !in_atomic(). Otherwise we can get into trouble > > if we end up calling

On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote: > On Wed 17-06-20 04:08:20, Matthew Wilcox wrote: > > If you call vfree() under > > a spinlock, you're in trouble. in_atomic() only knows if we hold a > > spinlock for CONFIG_PREEMPT, so it's not safe to check for in_atomic() > > in __vfree(). So we need the warning in order that preempt people can