search for: kfree_sensitive

...t 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. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: gi...

...t 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. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: gi...

...t 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. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: gi...

...kported 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 especially if LTO is used....

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. Instead, the new kfree_sen...

...kported 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 especially if LTO is used....

...kported 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 especially if LTO is used....

...eef)" 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. In addition, memzero_explicit() is used to clear the > memory to make sure that it won't get optimized away by the compiler. > > The renaming is done by using th...

...ommon.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, kfree_sensitive() does nothing. > * > * Not...

Le 14/04/2020 ? 00:28, Waiman Long a ?crit?: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. For better correctness, > the setting of keylen is also moved down after the key pointer check. > > Signed-off-by: Wai...

Le 14/04/2020 ? 00:28, Waiman Long a ?crit?: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. For better correctness, > the setting of keylen is also moved down after the key pointer check. > > Signed-off-by: Wai...

Since kfree_sensitive() will do an implicit memzero_explicit(), there is no need to call memzero_explicit() before it. Eliminate those memzero_explicit() and simplify the call sites. For better correctness, the setting of keylen is also moved down after the key pointer check. Signed-off-by: Waiman Long <longman at r...

Since kfree_sensitive() will do an implicit memzero_explicit(), there is no need to call memzero_explicit() before it. Eliminate those memzero_explicit() and simplify the call sites. Signed-off-by: Waiman Long <longman at redhat.com> --- .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 15 +++------------ .../...

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

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

On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. 2 bits of trivia: > diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/su...

On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. 2 bits of trivia: > diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/su...

...9: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: Waiman Long <longman at redhat.com> > --- > fs/btrfs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/bt...

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