From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jason A. Donenfeld" Date: Tue, 14 Apr 2020 08:32:03 +0000 Subject: Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive() Message-Id: <4babf834-c531-50ba-53f6-e88410b15ce3@zx2c4.com> List-Id: References: <20200413211550.8307-1-longman@redhat.com> <20200413211550.8307-2-longman@redhat.com> In-Reply-To: <20200413211550.8307-2-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Waiman Long , Andrew Morton , David Howells , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Linus Torvalds , Joe Perches , Matthew Wilcox , David Rientjes Cc: samba-technical@lists.samba.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, linux-sctp@vger.kernel.org, target-devel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, devel@driverdev.osuosl.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, x86@kernel.org, kasan-dev@googlegroups.com, cocci@systeme.lip6.fr, linux-wpan@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-crypto@vger.kernel.org, linux-pm@vger.kernel.org, ecryptfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-cifs@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, tipc-discussion@lists.sourceforge.net, wireguard@lists.zx2c4.com, linux-ppp@vger.kernel.org, linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org 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...]