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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB729C46467 for ; Tue, 10 Jan 2023 11:02:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91AEA900003; Tue, 10 Jan 2023 06:02:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CB4B900002; Tue, 10 Jan 2023 06:02:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 792E7900003; Tue, 10 Jan 2023 06:02:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6CB07900002 for ; Tue, 10 Jan 2023 06:02:02 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 49AC01A0CAA for ; Tue, 10 Jan 2023 11:02:02 +0000 (UTC) X-FDA: 80338599684.10.73D5F84 Received: from wind.enjellic.com (wind.enjellic.com [76.10.64.91]) by imf28.hostedemail.com (Postfix) with ESMTP id 86978C000D for ; Tue, 10 Jan 2023 11:01:59 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of greg@wind.enjellic.com designates 76.10.64.91 as permitted sender) smtp.mailfrom=greg@wind.enjellic.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673348519; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qvgS94vZPKHZGBqkd1Zmbi6/2qn/moyV/jrp+sW7fDI=; b=395iY8IRCG2fWwkwpOPzBGy+is0nkcaFiUGIVq6Xg3Ga1+FYAsbawFHw8SLmum6ktX+lfK TC6dBB7gGO3qy2hX1oLJFs0TL81AguhlSd2SI718EhRVPSU5KxNnh3xum3ImxjDSSLCOT+ xIT8GYZvDMPpJ0+pgWf6svuqbkdYKPs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of greg@wind.enjellic.com designates 76.10.64.91 as permitted sender) smtp.mailfrom=greg@wind.enjellic.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673348519; a=rsa-sha256; cv=none; b=lz9PACHmtWNphYXnEPtRyh3+wogzVlI/Q6+AUm/u3ZzQCp8wiobOgEkCO5EQrfXBjb1+Y3 G2HHrENGLIOuQS1g0AKmU+aNJC6iIXx1zTcoLlDB3RnuOPYBlx1k7qyKQJUJ4F7akdeFFx 8cgUWrFCuv+5X+sL+WXVQniEdDniqmc= Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 30AB1UCJ013380; Tue, 10 Jan 2023 05:01:30 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 30AB1SPZ013379; Tue, 10 Jan 2023 05:01:28 -0600 Date: Tue, 10 Jan 2023 05:01:28 -0600 From: "Dr. Greg" To: Linus Torvalds Cc: Andy Lutomirski , "Jason A. Donenfeld" , Yann Droneaud , Ingo Molnar , Linux Kernel Mailing List , patches@lists.linux.dev, Thomas Gleixner , Linux Crypto Mailing List , Linux API , the arch/x86 maintainers , Greg Kroah-Hartman , Adhemerval Zanella Netto , "Carlos O'Donell" , Florian Weimer , Arnd Bergmann , Jann Horn , Christian Brauner , linux-mm@kvack.org Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings Message-ID: <20230110110128.GA12987@wind.enjellic.com> Reply-To: "Dr. Greg" References: <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Tue, 10 Jan 2023 05:01:30 -0600 (CST) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 86978C000D X-Stat-Signature: 5x64nib4zej9kh5bmg7hsfzmmjn1gr9i X-Rspam-User: X-HE-Tag: 1673348519-233121 X-HE-Meta: U2FsdGVkX18lhOPOwbqibd0F2mmkjNR0wWAzF6KYMzQoE5hXhrBP39QRgiOz6Cm3yDyCNz/7iVz78QK6bUfC2NNnkTW9AlTMjT5bZTJ5MgrGagKGOjzrAlP+yaSfn0dpWzKGC40AUf6fC4T5Xo5OQ+ymllZvIphokdBCibNE5NbmjB/JqUp+wVCNuP2wA7MQ+y0tJnuOnU2VbtxIsd689WG4ZbC2b7ptSxT88IHzcoSfvZJHLLqcXHJKMaK+9P551OODIx3r0LysfUEU8QEP3nxQ0k2Co3ffnUWLVMLw/P+jANS9CBM0XHrXznEXAZxUeXvPfx+jccbQawYJYj9lmwoKQ2d2C2ovaiyDgJWKeVYt0DPQcMbakYoK72ZOaEtkZTWdLW0/9VV6BKfL8xWLwXXRPk6VtPbqefsSWsc29oHIcvNMW2rHPQO1YSLCRplY7zIAf35AewMxV3qSS9ul9t2XPGiwlKMO1hc3BO3GDT/Qibj8wm6DsO9YKpomQ739GltWRSNy6OCb8WWX+reF0psKmoPEzmVvSRRdWqQo//lLkGYfQyTVH92eqVv8n/bQLMkuu5+VnIdf76Jf8Ze5UMu8kj23WXzanXNiCxNKcTt7oVqA6iaGWwXCCO7ixRbKcDBhaMzoOmRx4g2UlLuWz95Dy5MaN2PGDyk8bWKxq8Hp/29Okb3YUO1kEvOPejICwp4qDLNa2Dwu1YdfQtoCS16PZY0zBTawd77pOuYLvNRP5JAb84VqMVl3Hm/58gjNsm2XPkXq3rvIdhRvjmWMSeEex5vtkpo8vntB7PtgcyTG22EM90hMWaKXbRW5u+WOu+2KPdBSxB0JoDWYHlUyE1rEpj5JSrnvZqD4rv5QtxHdzwa0TjUcCS2qU+2RWPNzBQ8Y8aKua0+EMVeU1+0B8AuZ8iqtaNAr1Wvh6GRy3TONKrQqC9RB/pgbbjHjdCPqDHbIQfecX0h23d0k9hv /e/lAy49 I2iA3Ztv2B6Spt+JQAHr7EHAQyJ3GvHRImK7drmkGn1jpzzGGZoydcrzlcr3v/eJTSt7FLk70SvFU50/7vkeG98nqF8AVvxIEw9hDdWqwV9yFEvxz62TordNCs0yUDeG4SEoW 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 Fri, Jan 06, 2023 at 01:10:44PM -0800, Linus Torvalds wrote: Good morning, I hope the week is going well for everyone. > On Fri, Jan 6, 2023 at 12:54 PM Andy Lutomirski wrote: > > > > I'm going to suggest a very very different approach: fix secret > > storage in memory for real. That is, don't lock "super secret > > sensitive stuff" into memory, and don't wipe it either. *Encrypt* it. > > I don't think you're wrong, but people will complain about key > management, and worry about that part instead. > > Honestly, this is what SGX and CPU enclaves is _supposed_ to all do > for you, but then nobody uses it for various reasons. The principal problem is that enclave technology was not made either ubiquitous or accessible, long story there, suitable for multiple snifters of single malt. Unfortunately, the same goes for just about every other hardware security technology. Every conversation comes down to; "what is the business case for the technology", which translated means, how much money are we going to make off it. Encrypting memory based secrets, as an alternative to wiping them, is attractive, but hardware support is needed to do key management securely and correctly. Even than, by definition, there will be a window when the material needs to be in memory as plaintext. A discussion can be had in this arena about perfection being the enemy of good. If you are truely interested in perfection in this endeavor, you need to have a trusted platform definition and implementation. Which, if history is any indication, needs to be an open architecture with respect to both software and hardware. > Linus Best wishes to everyone for a productive remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity