Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4737353ybb; Tue, 7 Apr 2020 13:28:16 -0700 (PDT) X-Google-Smtp-Source: APiQypI3smY9yZTjc6fVyiNkhjY5EWpd8CwhGYE0hVukIDgNo4D4LMVUwscJgAUpQ+eEZBgsH7ds X-Received: by 2002:a05:6830:19ce:: with SMTP id p14mr3073607otp.362.1586291296512; Tue, 07 Apr 2020 13:28:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586291296; cv=none; d=google.com; s=arc-20160816; b=NlBMAtU2kcaq3vXib/AOT9Fh+D4NdxO0Emj2oJScbynE34zAgpjylJr63Kqf6jlsMM j+vqH8gzLgq/1lbMu5oB/y20KrdDF61NJruR1L4i6cfTFwel5QqNz+q9Dz7O8LPT+inK Bew3PYpPQd/0Xit8NhZFke3bGNxpbzc37HYMwYeuFMM0sA/hNkNmVWm3RDjqJRs+0qBC xABJUeyGOg+xS29wCTnf9OEy+oWWzHvUEx9uI3Jaal2HXg9lSiIC2Akkt7MUmcMFeSC+ BdflnBD20zOom00QV0VbnPKqoIwB8tLESboyn1i1cJbIBSCjk4qCDJdf6k0ZT5PAlAbT ZCBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vULJyP67JBNxuLxHNrQncN4uZpPg3T+lQ2vheCSCnts=; b=l/lOWk3Lb7ckQPQL08NL7prv53/G0fVp/oS0K8jEk2BZpMXqVPQdQAjwqzIkAuIbDK tc71FegI2ejL3hSTgN8mJK6kyHgqq+GxU2dNg/sJe+OZmP4OYsavOT5QjVZ1DBa7XIGT yL5HZvX+Z2FDWAAmdUcEohWuqlJFeE19o4e7/7CMff06mDC8lboWcWoKkulj8LwLogMO P2hcEKmfSYaYOXx9Aychum90yixUforqqi3sXgF4cGA/dVGKZUG+qh5waFRH30K1VUuz yw28y08ciLaoPxcxzzI6+aznb8TFpBHm5zjzVflrv+vYPjRjQK5Ax+mmUjxmFlhkI5wz z3Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="Co/TSBn3"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si1574960ott.228.2020.04.07.13.28.01; Tue, 07 Apr 2020 13:28:16 -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=@linux-foundation.org header.s=google header.b="Co/TSBn3"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726403AbgDGU1T (ORCPT + 99 others); Tue, 7 Apr 2020 16:27:19 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:42229 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbgDGU1S (ORCPT ); Tue, 7 Apr 2020 16:27:18 -0400 Received: by mail-lj1-f194.google.com with SMTP id q19so5194609ljp.9 for ; Tue, 07 Apr 2020 13:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vULJyP67JBNxuLxHNrQncN4uZpPg3T+lQ2vheCSCnts=; b=Co/TSBn32SZzvluykyMIO4sU64Cf1AfgWv4n1Ae9afPaloY7VXr8XtXadW7RVEAJTs vKV3XqBLwUf5Lgvpk3GujRZVBG8OK5QgWjcN+ys77+yQtLlPkGtl5ki0fbBk2eZ4dECK i/T/hdMlpAbmHPRqD3BIA2AO4cpGwlth3++mE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vULJyP67JBNxuLxHNrQncN4uZpPg3T+lQ2vheCSCnts=; b=VTn3DPCfDzP6roQTIjoW30gKbkyMMfuvDWNuF8Xq8AMRE9JHKTbhFpU0bfT8ggCZrO p9qksBXDCakYKuqy4bZWpCtk5BEy5XqwQMnPIeeKtjstVBOeVZsYuV/4Nz4+E4Y+hbdN +Rk/NVVML3907vIqxIZVaHNvOuegTJbtP+jbMoMKC9+6sW7aO02McDIZ9lvWjRWMXRny UwZdI5ngk3Bmh9jzKoX6lnuk4MRYDmfNGMAfcWye2Q1eekpkfK7XbBZzqxKy8EvJ/6Gu 0IHKNf44d/a/OgOcBwfy1HJfNkELjyixNE3aWo0beYCTDyFZbSXjslf5XjOve8yL6NQj qpeQ== X-Gm-Message-State: AGi0PuaOaX3Wq0esKuCjO4m7NP3AEDYmBe85Ct7AsV9xgyYbeXeC1pjI CEdibkVg5Y7rX5d+qec9O2zyryMDcNQ= X-Received: by 2002:a2e:9f43:: with SMTP id v3mr407294ljk.129.1586291235210; Tue, 07 Apr 2020 13:27:15 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id f26sm13806243lfc.76.2020.04.07.13.27.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 13:27:13 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id r17so3438503lff.2 for ; Tue, 07 Apr 2020 13:27:13 -0700 (PDT) X-Received: by 2002:ac2:4466:: with SMTP id y6mr2501400lfl.125.1586291232936; Tue, 07 Apr 2020 13:27:12 -0700 (PDT) MIME-Version: 1.0 References: <20200406185827.22249-1-longman@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 7 Apr 2020 13:26:57 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects To: Joe Perches Cc: Waiman Long , Andrew Morton , David Howells , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Linux-MM , keyrings@vger.kernel.org, Linux Kernel Mailing List , Matthew Wilcox , David Rientjes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 7, 2020 at 1:16 PM Linus Torvalds wrote: > > Think of it this way: free() doesn't really change the data, it kills > the lifetime of it. You can't access it afterwards - you can neither > read it nor write it validly. That is a completely different - and > independent - operation from writing to it. Side note: I'd really love to be able to describe that operation, but there's sadly no such extension. So the _real_ prototype for 'free()'-like operations should be something like void free(const volatile killed void *ptr); where that "killed" also tells the compiler that the pointer lifetime is dead, so that using it afterwards is invalid. So that the compiler could warn us about some of the most trivial use-after-free cases. Because we've had even those trivially stupid ones Yes, obviously various analysis systems do exactly that kind of analysis (and usually go much further), but then it's external things like coverity etc. The point being that the lifetime of an object is independent from being able to write to an object, and the "const" in the "free()" is not "I promise to not write to it", but "I can accept a constant pointer". We've had a number of places in the kernel where we do that kind of "lifetime" marking explicitly by assigning a NULL (or invalid value) to the pointer when we free it. I have this dim memory of us even (long long long ago) trying to use a #define kfree() ... to do that, but it turns out to be basically impossible to get the proper "use once" semantics, so it doesn't work if the argument to kfree() has side effects. Linus