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 07005C63797 for ; Fri, 6 Jan 2023 21:36:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 620CC8E0002; Fri, 6 Jan 2023 16:36:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D12E8E0001; Fri, 6 Jan 2023 16:36:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 473758E0002; Fri, 6 Jan 2023 16:36:47 -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 38F468E0001 for ; Fri, 6 Jan 2023 16:36:47 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 14F12120EFE for ; Fri, 6 Jan 2023 21:36:47 +0000 (UTC) X-FDA: 80325684054.26.CFB234F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 5EA6714000A for ; Fri, 6 Jan 2023 21:36:45 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=Lw5J2oJG; spf=pass (imf23.hostedemail.com: domain of "SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673041005; h=from:from:sender: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:dkim-signature; bh=iBuV3hmE9MTswDExTCjyj/E1AIJfosMyykKtbV7OQBQ=; b=FX23nao31BJChYRwi5GQuRPDPkaj+wg3dtwbasP/GW2JCqq8RqG0T14Jx14XcJ905kZ5CU INqV39n+/Rnkz2DmmvqE7XSeI6W5RjlBLSOJM/OILvUEeY3P505L2XjM0KHDaxl4EdoQ6d aTSb5/4Q/0exTX9Z48A17BqV5339iVA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=Lw5J2oJG; spf=pass (imf23.hostedemail.com: domain of "SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=h6oe=5D=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673041005; a=rsa-sha256; cv=none; b=QSBGHJxjNfDdvTK7tPmQnQzZwkqmzLqAHtYTEl4NyK9hH1qd06+ziJgXN8XJxJ8IF1CRfZ jn+D85HwDB27rrEZt5tS0SQB3xruuKYOYRVyR6SOOk3HRtodFJGdsXoIYSId/xpUmrgsf0 CCAMfA94H36m/7mVyLysoXJYbJAifHI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6537A61F1E; Fri, 6 Jan 2023 21:36:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D53A2C433EF; Fri, 6 Jan 2023 21:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1673040999; 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=iBuV3hmE9MTswDExTCjyj/E1AIJfosMyykKtbV7OQBQ=; b=Lw5J2oJGEsVjlubs6QISg3WV7V7HRaEytxm4hiXK2JwyachDcJi7HU4HWIJVPwyz+rwzLE apbuJrPc6ZEHzDw5h3SQ0zATwxJawcJaypUv8oDWcu7Ooryx5hMzkzRAEAM2pLSi2iV3tH zZ7rD+4WJHGrP4AqYGzfhQPhxwKrw5U= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 1d0af2f9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 6 Jan 2023 21:36:39 +0000 (UTC) Date: Fri, 6 Jan 2023 22:36:38 +0100 From: "Jason A. Donenfeld" To: Andy Lutomirski Cc: Linus Torvalds , 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: References: <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5EA6714000A X-Rspam-User: X-Stat-Signature: 18t6xa4cimjocwj95j5534j9y8a53wzx X-HE-Tag: 1673041005-496889 X-HE-Meta: U2FsdGVkX19Kc6XQbWf9ja8fxFe9GpvJKN2jm/PvM7Rl7j+4S+MhkKr5IGzXMOb50xH3uaVTykBjnPbHrx7mgvxJqiyF+oSDUW5+5+DnfRev+uNZqpap3mSSkW9cgK7TZs0A0ZfCpZ24U3EiWU6yP6vTMS0Pn6GTqNAlhIEGEd3oWGBoAw7fD3gwboITDPzChbPWqa4GV12tkEi/VpaRyAANjvW3A8cyOVcdLNqeQHursGKxv+1r5luHzSDF+MkNKKDKaxCFXz0UTEfpWPTAUwoKB/fXW0i1u9vdp3Tp7MXKkG2qp8yKLSqqmT+MODR2VXxtc/9URp6k/4+FGiNQyZtV5Fst9WO9Som6GL5hvosWKbWoUUkigFVwP84vObO/eR9caM0vuWvsVV7cImr+3QNBZh2aRGOUhXztHbXvls3sblvL+Mm2os4DRTE5KfezDa8AYW7MnpeEt16L89KRfuKXWj/qLiqAqUmMlUzSVO4DCcAtOQNsiAeHhIVnC51FQOuLVld0Yf+jN6To7m/98UJuhUxZGOp0b1pQD9Ba3hRy+05qutTYH5Sry4UExuhdvpP04tWnypQkUBtS+O+aISiXl6bJOFmgmpxo8L1dFe1IN5KRk9zMv66QwMnRmxYmrKIf+Va4HC550obzNg0FO//Fu2RaR5XrrRSNfE3gBmKgMn8sDs7LuFIQYO/gWGPYk6MXCCpmmr6myMe9oRzBa+xe7OBE+wzLifna2XXMB6IHLJFvmbVP8KzRf92Lro/svOMre/oZWZ8N+X3mpUf5kJp3sNzREHWCMKiX309VYxIJwdHDDiRKKshoELyjdctJmuaFxA/Pg8rBCypLsnpYMTdyRCjBECE0Md6Kh4rrJ1gu5qkDrSud/JQ7TxlvCYqxpsm+EDKO6z7JG7DG5rFEoSyOQ7lFnuVRsRASvz10xUb6HjFJREVjMGSteOVcD1WyTIsfABIBg6T7y9J5VyZ nTsUCpV1 kZqgs8w5nd5cqQZcko1yuA6O4S4KCERncRlt7UvWDCyVdwo71byxNHRUP6Ez8LnpL8AIKU/2b1YS/RDGg+XkaH6ojiIcaH2omZTNcKctbifCwKwYOdlhtgk75hJz99q9lIw/vcM6M/uIWb1Ogwv5QENtB0/Gyw6WrDjWpzYZWzesrBDaSWDqRSqXitPwW4knPM/iSsLNa3TAhvVbYWCFQOirSf2sZHAQD7coH2d4CK86r8JJ6JxkZxxylm7M/fEg7is9TgzYHJSap114= 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 12:53:41PM -0800, Andy Lutomirski wrote: > > > On Thu, Jan 5, 2023, at 6:08 PM, Linus Torvalds wrote: > > On Thu, Jan 5, 2023 at 5:02 PM Linus Torvalds > > wrote: > >> > >> None of what you ask for is for any kind of real security, it's all > >> just crazy "but I want to feel the warm and fuzzies and take shortcuts > >> elsewhere, and push my pain onto other people". > > > > Actually, let me maybe soften that a bit and say that it's > > "convenience features". It might make some things more _convenient_ to > > do, exactly because it might allow other parts to do short-cuts. > > > > But because it's a convenience-feature, it had also better either be > > (a) really easy and clear to do in the kernel and (b) have > > sufficiently *wide* convenience so that it doesn't end up being one of > > those "corner case things we have to maintain forever and nobody > > uses". > > > > And I think VM_DROPPABLE matches (a), and would be fine if it had some > > other non-made-up use (although honestly, we should solve the 32-bit > > problem first - ignoring it isn't fine for anything that is supposed > > to be widely useful). > > > > We *have* talked about features kind of like it before, for people > > doing basically caches in user space that they can re-create on demand > > and are ok with just going away under memory pressure. > > > > But those people almost invariably want dropped pages to cause a > > SIGSEGV or SIGBUS, not to come back as zeroes. > > > > So you were insulting when you said kernel people don't care about > > security issues. And I'm just telling you that's not true, but it > > *is* 100% true that kernel people are often really fed up with > > security people who have their blinders on, focus on some small thing, > > and think nothing else ever matters. > > > > So yes, the way to get something like VM_DROPPABLE accepted is to > > remove the blinders, and have it be something more widely useful, and > > not be a "for made up bad code". > > 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. > > This boils down to implementing proper encrypted swap support, which is not conceptually that difficult. The kernel already has identifiers (mapping, offset, etc) for every page in swap and already stores some metadata. Using that as part of a cryptographic operation seems conceptually fairly straightforward. Not sure this solves the right problem, which is primarily related to forward secrecy, which means the important property is timely secret erasure. Writing things out to disk complicates that, and encrypted swap means moving the problem into key lifetime, which sounds like a can of worms to synchronize. So this doesn't sound so appealing to me as a solution. It does sound like a potentially nice thing for other uses, though. Jason