* [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() [not found] <20200616015718.7812-1-longman@redhat.com> @ 2020-06-16 1:57 ` Waiman Long 2020-06-16 3:30 ` Eric Biggers 2020-06-16 6:42 ` Michal Hocko 0 siblings, 2 replies; 6+ messages in thread From: Waiman Long @ 2020-06-16 1:57 UTC (permalink / raw) To: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox, David Rientjes Cc: Michal Hocko, Johannes Weiner, Dan Carpenter, David Sterba, Jason A . Donenfeld, linux-mm, keyrings, linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic, linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp, wireguard, linux-wireless, devel, linux-scsi, target-devel, linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev, linux-bluetooth, linux-wpan, linux-sctp, linux-nfs, tipc-discussion, linux-security-module, linux-integrity, Waiman Long, stable 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 if LTO is being used. To make sure that this optimization will not happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to do the clearing. Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") Cc: stable@vger.kernel.org Signed-off-by: Waiman Long <longman@redhat.com> --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 9e72ba224175..37d48a56431d 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1726,7 +1726,7 @@ void kzfree(const void *p) if (unlikely(ZERO_OR_NULL_PTR(mem))) return; ks = ksize(mem); - memset(mem, 0, ks); + memzero_explicit(mem, ks); kfree(mem); } EXPORT_SYMBOL(kzfree); -- 2.18.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() 2020-06-16 1:57 ` [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() Waiman Long @ 2020-06-16 3:30 ` Eric Biggers 2020-06-16 13:05 ` Waiman Long 2020-06-16 6:42 ` Michal Hocko 1 sibling, 1 reply; 6+ messages in thread From: Eric Biggers @ 2020-06-16 3:30 UTC (permalink / raw) To: Waiman Long Cc: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox, David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter, David Sterba, Jason A . Donenfeld, linux-mm, keyrings, linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic, linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp, wireguard, linux-wireless, devel, linux-scsi, target-devel, linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev, linux-bluetooth, linux-wpan, linux-sctp, linux-nfs, tipc-discussion, linux-security-module, linux-integrity, stable 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 > memory clearing especially if LTO is being used. To make sure that this > optimization will not happen, memzero_explicit(), which is introduced > in v3.18, is now used in kzfree() to do the clearing. > > Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") > Cc: stable@vger.kernel.org > Signed-off-by: Waiman Long <longman@redhat.com> > --- > mm/slab_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 9e72ba224175..37d48a56431d 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1726,7 +1726,7 @@ void kzfree(const void *p) > if (unlikely(ZERO_OR_NULL_PTR(mem))) > return; > ks = ksize(mem); > - memset(mem, 0, ks); > + memzero_explicit(mem, ks); > kfree(mem); > } > EXPORT_SYMBOL(kzfree); This is a good change, but the commit message isn't really accurate. AFAIK, no one has found any case where this memset() gets optimized out. And even with LTO, it would be virtually impossible due to all the synchronization and global data structures that kfree() uses. (Remember that this isn't the C standard function "free()", so the compiler can't assign it any special meaning.) Not to mention that LTO support isn't actually upstream yet. I still agree with the change, but it might be helpful if the commit message were honest that this is really a hardening measure and about properly conveying the intent. As-is this sounds like a critical fix, which might confuse people. - Eric ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() 2020-06-16 3:30 ` Eric Biggers @ 2020-06-16 13:05 ` Waiman Long 2020-06-16 15:46 ` David Howells 0 siblings, 1 reply; 6+ messages in thread From: Waiman Long @ 2020-06-16 13:05 UTC (permalink / raw) To: Eric Biggers Cc: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox, David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter, David Sterba, Jason A . Donenfeld, linux-mm, keyrings, linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic, linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp, wireguard, linux-wireless, devel, linux-scsi, target-devel, linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev, linux-bluetooth, linux-wpan, linux-sctp, linux-nfs, tipc-discussion, linux-security-module, linux-integrity, stable 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 >> memory clearing especially if LTO is being used. To make sure that this >> optimization will not happen, memzero_explicit(), which is introduced >> in v3.18, is now used in kzfree() to do the clearing. >> >> Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") >> Cc: stable@vger.kernel.org >> Signed-off-by: Waiman Long <longman@redhat.com> >> --- >> mm/slab_common.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/slab_common.c b/mm/slab_common.c >> index 9e72ba224175..37d48a56431d 100644 >> --- a/mm/slab_common.c >> +++ b/mm/slab_common.c >> @@ -1726,7 +1726,7 @@ void kzfree(const void *p) >> if (unlikely(ZERO_OR_NULL_PTR(mem))) >> return; >> ks = ksize(mem); >> - memset(mem, 0, ks); >> + memzero_explicit(mem, ks); >> kfree(mem); >> } >> EXPORT_SYMBOL(kzfree); > This is a good change, but the commit message isn't really accurate. AFAIK, no > one has found any case where this memset() gets optimized out. And even with > LTO, it would be virtually impossible due to all the synchronization and global > data structures that kfree() uses. (Remember that this isn't the C standard > function "free()", so the compiler can't assign it any special meaning.) > Not to mention that LTO support isn't actually upstream yet. > > I still agree with the change, but it might be helpful if the commit message > were honest that this is really a hardening measure and about properly conveying > the intent. As-is this sounds like a critical fix, which might confuse people. Yes, I agree that the commit log may look a bit scary. How about the following: 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 buffer clearing. However unlikely, there is still a non-zero probability that the compiler may choose to optimize away the memory clearing especially if LTO is being used in the future. To make sure that this optimization will never happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to future-proof it. Cheers, Longman ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() 2020-06-16 13:05 ` Waiman Long @ 2020-06-16 15:46 ` David Howells 0 siblings, 0 replies; 6+ messages in thread From: David Howells @ 2020-06-16 15:46 UTC (permalink / raw) To: Waiman Long Cc: Andrew Morton, ebiggers, David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox, David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter, David Sterba, Jason A . Donenfeld, linux-mm, keyrings, linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic, linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp, wireguard, linux-wireless, devel, linux-scsi, target-devel, linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev, linux-bluetooth, linux-wpan, linux-sctp, linux-nfs, tipc-discussion, linux-security-module, linux-integrity, stable Waiman Long <longman@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 probability I'd say "a possibility". > that and I'd move "in [the] future" here. > the compiler may choose to optimize away the > memory clearing especially if LTO is being used in the future. To make sure > that this optimization will never happen "in these cases" > , memzero_explicit(), which is introduced in v3.18, is now used in "instead of"? > kzfree() to future-proof it. Davod ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() 2020-06-16 1:57 ` [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() Waiman Long 2020-06-16 3:30 ` Eric Biggers @ 2020-06-16 6:42 ` Michal Hocko 2020-06-16 9:08 ` Dan Carpenter 1 sibling, 1 reply; 6+ messages in thread From: Michal Hocko @ 2020-06-16 6:42 UTC (permalink / raw) To: Waiman Long Cc: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox, David Rientjes, Johannes Weiner, Dan Carpenter, David Sterba, Jason A . Donenfeld, linux-mm, keyrings, linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic, linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp, wireguard, linux-wireless, devel, linux-scsi, target-devel, linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev, linux-bluetooth, linux-wpan, linux-sctp, linux-nfs, tipc-discussion, linux-security-module, linux-integrity, stable 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 clearing especially if LTO is being used. To make sure that this > optimization will not happen, memzero_explicit(), which is introduced > in v3.18, is now used in kzfree() to do the clearing. > > Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") > Cc: stable@vger.kernel.org > Signed-off-by: Waiman Long <longman@redhat.com> Acked-by: Michal Hocko <mhocko@suse.com> Although I am not really sure this is a stable material. Is there any known instance where the memset was optimized out from kzfree? > --- > mm/slab_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 9e72ba224175..37d48a56431d 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1726,7 +1726,7 @@ void kzfree(const void *p) > if (unlikely(ZERO_OR_NULL_PTR(mem))) > return; > ks = ksize(mem); > - memset(mem, 0, ks); > + memzero_explicit(mem, ks); > kfree(mem); > } > EXPORT_SYMBOL(kzfree); > -- > 2.18.1 > -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() 2020-06-16 6:42 ` Michal Hocko @ 2020-06-16 9:08 ` Dan Carpenter 0 siblings, 0 replies; 6+ messages in thread From: Dan Carpenter @ 2020-06-16 9:08 UTC (permalink / raw) To: Michal Hocko Cc: Waiman Long, Jason A . Donenfeld, linux-btrfs, Jarkko Sakkinen, David Sterba, David Howells, linux-mm, linux-sctp, keyrings, kasan-dev, linux-stm32, devel, linux-cifs, linux-scsi, James Morris, Matthew Wilcox, linux-wpan, David Rientjes, linux-pm, ecryptfs, linux-fscrypt, linux-mediatek, linux-amlogic, virtualization, linux-integrity, linux-nfs, Linus Torvalds, linux-wireless, linux-kernel, stable, linux-bluetooth, linux-security-module, target-devel, tipc-discussion, linux-crypto, Johannes Weiner, Joe Perches, Andrew Morton, linuxppc-dev, netdev, wireguard, linux-ppp On Tue, Jun 16, 2020 at 08:42:08AM +0200, Michal Hocko wrote: > 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 clearing especially if LTO is being used. To make sure that this > > optimization will not happen, memzero_explicit(), which is introduced > > in v3.18, is now used in kzfree() to do the clearing. > > > > Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") > > Cc: stable@vger.kernel.org > > Signed-off-by: Waiman Long <longman@redhat.com> > > Acked-by: Michal Hocko <mhocko@suse.com> > > Although I am not really sure this is a stable material. Is there any > known instance where the memset was optimized out from kzfree? I told him to add the stable. Otherwise it will just get reported to me again. It's a just safer to backport it before we forget. regards, dan carpenter ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-16 16:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200616015718.7812-1-longman@redhat.com>
2020-06-16 1:57 ` [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree() Waiman Long
2020-06-16 3:30 ` Eric Biggers
2020-06-16 13:05 ` Waiman Long
2020-06-16 15:46 ` David Howells
2020-06-16 6:42 ` Michal Hocko
2020-06-16 9:08 ` Dan Carpenter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).