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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 C533DC2D0EC for ; Tue, 7 Apr 2020 23:50:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D7F720719 for ; Tue, 7 Apr 2020 23:50:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Td8kk/ww" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D7F720719 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9E6038E0005; Tue, 7 Apr 2020 19:50:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9970F8E0001; Tue, 7 Apr 2020 19:50:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 885358E0005; Tue, 7 Apr 2020 19:50:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6EB308E0001 for ; Tue, 7 Apr 2020 19:50:33 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1DE21180AD802 for ; Tue, 7 Apr 2020 23:50:33 +0000 (UTC) X-FDA: 76682705946.17.straw07_3ef86e9d8b31b X-HE-Tag: straw07_3ef86e9d8b31b X-Filterd-Recvd-Size: 6129 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 23:50:32 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id x23so3765392lfq.1 for ; Tue, 07 Apr 2020 16:50:32 -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=zksoCklR8z1unQJuTBJp3Rro9MEQv7rmoj+ED3C7oyg=; b=Td8kk/wwBIcNQ5/edS+wLaYx9ypQ0Xx+RdI4BqPcVFzedqFgesVW8C0IjQkk8xO+9c GFfwVFDIaBwoUeYyZ+F2+9SFOMkc4tW9LFJGDZ9t5P2P4MDclhoZQ8m9RwKd8bXmmICe ThbWpWcO8nS2CaXOD7SirGXBzJ6n6RI04OA4Q= 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=zksoCklR8z1unQJuTBJp3Rro9MEQv7rmoj+ED3C7oyg=; b=EWG2tMINyvmCuyYYnVlwbtawdUd3EjKrkc+jE7FEy+BkEmQlbdMlh9OE9v/K316qWD I2iFe5xFVp+UNl8DoItONBbmR3QxJcEwTUmAdAuh07c2c7VyHP9PG2dNe92liYd6MpUD Ed9/zUeztmmFmGgX2H5zz4TNYv+Dn43ZI72WRfk9CbeVydRV1vLvp3AQDD4Kt2Y+PFg/ EIBOi2GT0IYps6FBZRDAS+SLE1Rv3/IzkagGq32FnaOApADUweaO+gDBDVt1Rf41oMbf S2r1JGNVttMO05Skz7XCW5M26aOkUtIWGk0ZlV4euMZFVT7fgtSewbfj+0iz8/JTGs3m 60QA== X-Gm-Message-State: AGi0PuZNQamIgXs1PehR8m6B7HVARcylDjs7w8FRde9O7IuCbYxsnTFl 39U060068uruR5iam14T8GNOiCcynss= X-Google-Smtp-Source: APiQypIu6e4VzajE5cgP3I9gUmT2l/F0BrG0T8K7eZZ/V98M2cRtc/HEPPZhF7yfnjIHF6Wru1IH8Q== X-Received: by 2002:a19:85d5:: with SMTP id h204mr2895906lfd.175.1586303429678; Tue, 07 Apr 2020 16:50:29 -0700 (PDT) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id d21sm12539918ljc.49.2020.04.07.16.50.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 16:50:28 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id q19so5636948ljp.9 for ; Tue, 07 Apr 2020 16:50:27 -0700 (PDT) X-Received: by 2002:a2e:7c1a:: with SMTP id x26mr2966560ljc.209.1586303427328; Tue, 07 Apr 2020 16:50:27 -0700 (PDT) MIME-Version: 1.0 References: <20200406185827.22249-1-longman@redhat.com> <699292.1586294051@warthog.procyon.org.uk> <749735.1586300050@warthog.procyon.org.uk> In-Reply-To: <749735.1586300050@warthog.procyon.org.uk> From: Linus Torvalds Date: Tue, 7 Apr 2020 16:50:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm: Add kvfree_sensitive() for freeing sensitive data objects To: David Howells Cc: Joe Perches , Waiman Long , Andrew Morton , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , Linux-MM , keyrings@vger.kernel.org, Linux Kernel Mailing List , Matthew Wilcox , David Rientjes , law@redhat.com Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 7, 2020 at 3:54 PM David Howells wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 > > With regard to this, I've got back "not sure what Linus was talking about WRT > DSE, if he's got examples he could pass along, they'd be appreciated" I'll do that. We have real examples in the kernel, although they probably aren't all that _important_. I don't see that comment on the bugzilla, but I'll put the stupid example in there too. One such example would be kernel/async.c: async_run_entry_fn(), where we have /* 2) remove self from the pending queues */ spin_lock_irqsave(&async_lock, flags); list_del_init(&entry->domain_list); list_del_init(&entry->global_list); /* 3) free the entry */ kfree(entry); atomic_dec(&entry_count); and while it's good form to do "list_del_init()" on those fields in entry, the fact that we then do "kfree(entry)" right afterwards means that the stores that re-initialize the entry list are dead. So _if_ we had some way to tell the compiler that "hey, kfree(ptr) kills the lifetime of that object", the compiler could eliminate the dead stores. I think that dead store elimination is perhaps less important than if the compiler could warn about us stupidly using the dead storage afterwards, but I mention it as a "it can actually matter for code generation" example too. Now, the above is a particularly stupid example, because if we cared, we could just turn the "list_del_init()" into a plain "list_del()", and simply not do the unnecessary re-initialization of the list entry after removing it. But I picked a stupid example because it's easy to understand. Less stupidly, we sometimes have "cleanup" functions that get rid of things, and are called before you free the underlying storage. And there, the cleanup function might be used in general, and not only just before freeing. So the re-initialization could make sense in that context, but might again be just dead stores for the actual final freeing case. Is this a big deal? No it's not. But it's not really any different from the dead store elimination that gcc already does for local variables on stack. Linus