From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE23FC3815B for ; Tue, 14 Apr 2020 08:33:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ABF892074D for ; Tue, 14 Apr 2020 08:33:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="sx6IKJIx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436882AbgDNIcS (ORCPT ); Tue, 14 Apr 2020 04:32:18 -0400 Received: from mail.zx2c4.com ([192.95.5.64]:52379 "EHLO mail.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436826AbgDNIcL (ORCPT ); Tue, 14 Apr 2020 04:32:11 -0400 Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 9d220a78; Tue, 14 Apr 2020 08:22:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=subject:to:cc :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=Bn42dUX94nPZ VI2aresTt2verm4=; b=sx6IKJIxzuEOA3MDWmGK5eH/64R8mpMYlG8WURWdfzRD XFeah0rjLnpfJ/wNxDNPuLqvGkOXg2tTc6/J9yxFJV/B/IyVASTm/xV1AWFh8sOT E+Zkl2VUcl4Y0wf6Mu5iapMmn3g8Ztyi36JLXdlWN66PEuOJynjCGScQFzOu0tep 4+h/FZal3et8UceGQF9vqtL2mbwwUOtzAFh6NniwZkygh5iiMorXd4zwhnYD2AoL UBjxDBvR+PqwgLJDDNN43HRxAe1Ka1ICHvrV5FNQIfjCNS9xZTJzxiJXAqnsHyrN w3BT8jw4OmracAotC1L9+6WCZMUQn8YWdWOjpIB/Jw== Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id e4f42b92 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 14 Apr 2020 08:22:18 +0000 (UTC) Subject: Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive() To: Waiman Long , Andrew Morton , David Howells , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Linus Torvalds , Joe Perches , Matthew Wilcox , David Rientjes Cc: linux-mm@kvack.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org, linux-pm@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-mediatek@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-ppp@vger.kernel.org, wireguard@lists.zx2c4.com, linux-wireless@vger.kernel.org, devel@driverdev.osuosl.org, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-fscrypt@vger.kernel.org, ecryptfs@vger.kernel.org, kasan-dev@googlegroups.com, linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-nfs@vger.kernel.org, tipc-discussion@lists.sourceforge.net, cocci@systeme.lip6.fr, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org References: <20200413211550.8307-1-longman@redhat.com> <20200413211550.8307-2-longman@redhat.com> From: "Jason A. Donenfeld" Message-ID: <4babf834-c531-50ba-53f6-e88410b15ce3@zx2c4.com> Date: Tue, 14 Apr 2020 02:32:03 -0600 MIME-Version: 1.0 In-Reply-To: <20200413211550.8307-2-longman@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@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...]