Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3442520ybb; Mon, 6 Apr 2020 09:01:42 -0700 (PDT) X-Google-Smtp-Source: APiQypIJCiftwjRpad0LNWwaQI/Fz58lb0k01YIxlNVHWlBp6Lfzw/Zrpp/pOtIzydIllrI6C7o/ X-Received: by 2002:aca:2811:: with SMTP id 17mr3604oix.126.1586188902413; Mon, 06 Apr 2020 09:01:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586188902; cv=none; d=google.com; s=arc-20160816; b=YsfMwjde1a9yAi+GtUgRhlDmV/ApQU2fgrjVuzmnP4kopcntgkNOLdSfsuBAuXDqdU 1wM1hzQEK2U+tryDJATFprQKzfMJQK8XVro8dtnCQQKalaFmc52adXfmqQIEpd7G9V89 6yKR2GsWSJg9/SoBEiLcfcmGIA5dlzWVJ7qhTJxj+zyKvM3qt/X9SV8YM1whjCftkB+A FDfQra2bky67bEEHw/lD51DiCsjuohcE2fUIcBXOki5+RUNSMTc4b2Eo/epdReR3AcWC 1tXbbo+qidEuRC/OI+3vSElnk9y1pEKDOTcOQhsVFFiAFwaDJ/rnL544bdniX/jKy5z0 sd4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:content-id:mime-version :subject:cc:to:references:in-reply-to:from:organization :dkim-signature; bh=Q6kZ7ASO5bOsyaLXnJ3Ux1/QL48SgEahPH8hNJMUrGo=; b=MhpcmdI1+H1VNYiXm8uPkIarSJHzfZ6nHqiOf2WS1pXx1tf5KtSf0OafrkBHTi3Llk e3Hma9tOFuRwIBt2F1sARoulTK3mxvDuaPZVMBwDMIAIcvR/vZyEsPby1YBnC5UcSJtc TGMqg1kMTTAGc4+r+5kXZEpM2cU2ZqohyXr1OYJFzfsKpaEKSyvfpMFai6+q23jBva4d ZDMnWbaBKWMOxAs27kPQlnVzsIAtW+sRmctJwU+JUQcigQtzRhYHM75fMwF+dhJ1iJR2 VU66gji6+pdAYdIHWYcWe/cjTuIT3qBi7oNSD97ibZ5a/PUwJM8bKD9W+vKBgK24FG22 BgEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EQwILJKu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si8087799oto.72.2020.04.06.09.01.26; Mon, 06 Apr 2020 09:01:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EQwILJKu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729139AbgDFQAy (ORCPT + 99 others); Mon, 6 Apr 2020 12:00:54 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:44076 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728976AbgDFQAx (ORCPT ); Mon, 6 Apr 2020 12:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586188852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Q6kZ7ASO5bOsyaLXnJ3Ux1/QL48SgEahPH8hNJMUrGo=; b=EQwILJKu2Dk5vYvkAF9TO3q1V6lPfPbANAymKHYtdfg0kjglyB1+TqfcxrsNyRSLkQULge CDqV5Aq/WiO59tlQc+xuGoXQCad7N7B+tjZpuSyDfQOTj2f72CGKKPbXJeBmVKukOlgoIL K/eyLdnL3/RzjbRi1n0ic8olFAUWSd0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-27-IZyOAiQXMpmCLJhwlRYpoA-1; Mon, 06 Apr 2020 12:00:48 -0400 X-MC-Unique: IZyOAiQXMpmCLJhwlRYpoA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 118828017F3; Mon, 6 Apr 2020 16:00:46 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-112-224.rdu2.redhat.com [10.10.112.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id DE3A5118F46; Mon, 6 Apr 2020 16:00:40 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <20200406023700.1367-1-longman@redhat.com> To: Joe Perches Cc: dhowells@redhat.com, Waiman Long , Andrew Morton , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , linux-mm@kvack.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH] mm: Add kvfree_sensitive() for freeing sensitive data objects MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <319764.1586188840.1@warthog.procyon.org.uk> Date: Mon, 06 Apr 2020 17:00:40 +0100 Message-ID: <319765.1586188840@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Joe Perches wrote: > > This patch introduces a new kvfree_sensitive() for freeing those > > sensitive data objects allocated by kvmalloc(). The relevnat places > > where kvfree_sensitive() can be used are modified to use it. > > Why isn't this called kvzfree like the existing kzfree? To quote Linus: We have a function for clearing sensitive information: it's called "memclear_explicit()", and it's about forced (explicit) clearing even if the data might look dead afterwards. The other problem with that function is the name: "__kvzfree()" is not a useful name for this function. We use the "__" format for internal low-level helpers, and it generally means that it does *less* than the full function. This does more, not less, and "__" is not following any sane naming model. So the name should probably be something like "kvfree_sensitive()" or similar. Or maybe it could go even further, and talk about _why_ it's sensitive, and call it "kvfree_cleartext()" or something like that. Because the clearing is really not what even matters. It might choose other patterns to overwrite things with, but it might do other things too, like putting special barriers for data leakage (or flags to tell return-to-user-mode to do so). And yes, kzfree() isn't a good name either, and had that same memset(), but at least it doesn't do the dual-underscore mistake. Including some kzfree()/crypto people explicitly - I hope we can get away from this incorrect and actively wrong pattern of thinking that "sensitive data should be memset(), and then we should add a random 'z' in the name somewhere to 'document' that". David