Message ID | 20250110-asi-rfc-v2-v2-0-8419288bc805@google.com (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 72F11E77188 for <linux-mm@archiver.kernel.org>; Fri, 10 Jan 2025 18:40:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E9BA6B00B0; Fri, 10 Jan 2025 13:40:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 09A426B00B1; Fri, 10 Jan 2025 13:40:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7CBB6B00B4; Fri, 10 Jan 2025 13:40:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C3A6A6B00B0 for <linux-mm@kvack.org>; Fri, 10 Jan 2025 13:40:49 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4169B1C7D7A for <linux-mm@kvack.org>; Fri, 10 Jan 2025 18:40:49 +0000 (UTC) X-FDA: 82992408618.08.AEBB355 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) by imf23.hostedemail.com (Postfix) with ESMTP id 2FD3B14000D for <linux-mm@kvack.org>; Fri, 10 Jan 2025 18:40:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ehFeqm1g; spf=pass (imf23.hostedemail.com: domain of 3rWmBZwgKCMgxoqy0o1pu22uzs.q20zw18B-00y9oqy.25u@flex--jackmanb.bounces.google.com designates 209.85.128.74 as permitted sender) smtp.mailfrom=3rWmBZwgKCMgxoqy0o1pu22uzs.q20zw18B-00y9oqy.25u@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736534447; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=jjtB5lRt7h5DA7GIgQanvF90WYFKTK1R3LPSOzDiibI=; b=kAYeBRNsSh0EAzFHTk9SrnObU+r1gayiH3Xk7eAqG5lObo1Wu+cF7dU2/MZcCgob5n8gVA FxFbVU234IX9Wk59IH4NqMkPXesEsgnGP9igoZjfLM7jPJCXrVcT6LYf8AMiJpLGxk2aZW hkJzEm/J+dL0HdOzl48FX3O1DsEYPA4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736534447; a=rsa-sha256; cv=none; b=cUEfuLH+vlBWX9vACBzrRrIRuGxbLwcC71Kz9V0HTC2daFfGDWTzQ33o5V++yriqoFxXg+ itqJCdL6oXYndVRGW7zw+xQD12Nx71MCoP4AXNV/BN9wmgZExpKmJvv6I1AnXDVpoLkquw BYe8bIU1ywWGMCpyITznRl0gBtnaPkU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ehFeqm1g; spf=pass (imf23.hostedemail.com: domain of 3rWmBZwgKCMgxoqy0o1pu22uzs.q20zw18B-00y9oqy.25u@flex--jackmanb.bounces.google.com designates 209.85.128.74 as permitted sender) smtp.mailfrom=3rWmBZwgKCMgxoqy0o1pu22uzs.q20zw18B-00y9oqy.25u@flex--jackmanb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-43623bf2a83so20551065e9.0 for <linux-mm@kvack.org>; Fri, 10 Jan 2025 10:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736534446; x=1737139246; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date:message-id:reply-to; bh=jjtB5lRt7h5DA7GIgQanvF90WYFKTK1R3LPSOzDiibI=; b=ehFeqm1gw5GXaCTSunLn0tpZh4r8TpzT+3FAmct/u48T5ROWmNm/k/VX7Ixke7wDaL f9UtwDT/raIrFa4sTk1VxseyDZ96F3WfymN5Tc44nwDWoEykCEJXHTwL48uv8z5pOGMr /Mj02GI+SoKi/1wfig4ktjir+wi1ipVMaAcNd672PFCqqNDeWBJ8GkaYF7THmcPAKK9T yb+ZY4MuK3PZj2tZPAdllQdjtl9pSCAPdyClrcYBm+NxWCX5FnmVVvGqXycJ9TDBqYb/ Y+TWSVU/TWW866f3YD9k21z6WcUCzkbCJQ2hx3drjj4XkQ3yd93re9TEGMbIhN8KD1+J UgmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736534446; x=1737139246; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jjtB5lRt7h5DA7GIgQanvF90WYFKTK1R3LPSOzDiibI=; b=lg/MJKlvEz7NhHPlBroTSLsDcHRqoN2q8n/mSDVu6fxKsWHbx5Kr7bKDJc2GEIF8MS u7E/YfB18lDTsIRCKNhw6ZFO7Ukc5OaBh4O125iROXzWtNsbwnQq+XGSPL+U5v832pQ3 21j4ts6mDz/AmQ9LAxnoW9shW5+2AL4gOP9960fZHsaJzcBjqiPCrtr1yk/735oIYOYD Y5RYAEVM1avftGKkYKjzaH34ovjQGMIYJob7YcqBab2JKIwAsrWY1582l3ZlC1VuywnV EaEAsOv8Qr0iYQ/dkdCozbNBHYB+Bu5DwgRzTffatLNACADYqewhHBFgcR6CjRAz2iXx ZM1g== X-Forwarded-Encrypted: i=1; AJvYcCU0ylKGgzyTY+icn5tJNJZEI5bBTttAqcrKLa9DhhbAoSzzYgNkOnHLaNxp2ZeEikZ5jAiNT4r3eA==@kvack.org X-Gm-Message-State: AOJu0YxxcXPQincBhmgJ66LuTA5TkpKBtDSQlqCbyUMoR+HmqIeamiHO fBiJWWXtXdxcCqlxk1cWzo4U1g/8jNBfIqkLNz02pAqH6QI6wRGl1fzhvn3tZBO/I/SpyEOsANR Pu8IpceULVA== X-Google-Smtp-Source: AGHT+IGn62s/zpmNlw6cS/dnEppCTrQbKdqDl7tm1TqotCpul8Aao0CteIYxi5s8bW0nJPjX7qZkFnpNt2sQAQ== X-Received: from wmbjw19.prod.google.com ([2002:a05:600c:5753:b0:434:a4bc:534f]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a7b:c315:0:b0:434:ffb2:f9df with SMTP id 5b1f17b1804b1-436e26adf94mr117996365e9.17.1736534445509; Fri, 10 Jan 2025 10:40:45 -0800 (PST) Date: Fri, 10 Jan 2025 18:40:26 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAJtpgWcC/z2NwQrCMBBEf6Xs2ZVsTLX1JAh+gFfpIWnTdkEbS SQoJf9uzMHjvGHerBCsZxvgWK3gbeTAbslBbiroZ71MFnnIGaSQiohq1IHRjz1GifXQGmNU5s0 e8uDp7cjvIrvB9XKGLsOZw8v5TzmIVKqfSxxI/l1SYSQUSEqZHbVaiaE5Tc5Nd7vt3QO6lNIXN mCbbqoAAAA= X-Change-Id: 20241115-asi-rfc-v2-5d9bbb441186 X-Mailer: b4 0.15-dev Message-ID: <20250110-asi-rfc-v2-v2-0-8419288bc805@google.com> Subject: [PATCH RFC v2 00/29] Address Space Isolation (ASI) From: Brendan Jackman <jackmanb@google.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Richard Henderson <richard.henderson@linaro.org>, Matt Turner <mattst88@gmail.com>, Vineet Gupta <vgupta@kernel.org>, Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>, Brian Cain <bcain@quicinc.com>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Geert Uytterhoeven <geert@linux-m68k.org>, Michal Simek <monstr@monstr.eu>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Dinh Nguyen <dinguyen@kernel.org>, Jonas Bonn <jonas@southpole.se>, Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>, Stafford Horne <shorne@gmail.com>, "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>, Helge Deller <deller@gmx.de>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, Naveen N Rao <naveen@kernel.org>, Madhavan Srinivasan <maddy@linux.ibm.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle <svens@linux.ibm.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, Rich Felker <dalias@libc.org>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, "David S. Miller" <davem@davemloft.net>, Andreas Larsson <andreas@gaisler.com>, Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>, Andrew Morton <akpm@linux-foundation.org>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>, Valentin Schneider <vschneid@redhat.com>, Uladzislau Rezki <urezki@gmail.com>, Christoph Hellwig <hch@infradead.org>, Masami Hiramatsu <mhiramat@kernel.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Mike Rapoport <rppt@kernel.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>, Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Ard Biesheuvel <ardb@kernel.org>, Josh Poimboeuf <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, Brendan Jackman <jackmanb@google.com>, Junaid Shahid <junaids@google.com>, Ofir Weisse <oweisse@google.com>, Yosry Ahmed <yosryahmed@google.com>, Kevin Cheng <chengkev@google.com>, Reiji Watanabe <reijiw@google.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2FD3B14000D X-Stat-Signature: yfn9krcz57mwweqsb5gqxdiex9wxbwqc X-Rspam-User: X-HE-Tag: 1736534446-555712 X-HE-Meta: U2FsdGVkX18J31oslO3B28Is0aKVZ6KUG67WYePXnTK7ybZ3KfLbwxFvpvBJoRvaeczPwIdFisoOOd3MgBWZc0UX/dLybk9O888ldSm+w6LM21r77Ls7w7+dCxvgvOgVVJQBY9aMs4LMB8YTYpNKsYbAoEtiHN9RPmfgtEbWDzbyATQfbB7rtp1WYpeXbFs7wqNQYmLeA0Du+jAklVx+43zr4eO7DmxN+eTBvmUpZFv3wyokEXua9135akf4nCGQCfSjcnSdbk8mKxP6oW9PsJ4S1wV5kA65nQGPEMDJPTnLh7td8wUq/dtaKokRGeiVBuWXoxtXXF9BEadZ8RmqnN0CVHxcoFOPBDuyNUGTVrMrG2ut9psaxh1XXerHOTzZPL8/i/BUtkDhOV464NZ4HRkuSE8sG09PytEhdAARhAyddJXQKPQ3qObgk5pUEEgadqY4cz+btOEFR+k0JGMGZ7M+eiimj+LzgnqAdo96XYMw2tiHVMSVx9Qyw87oSYP4mM6b3Ehg6Kr8V24yhEzov1u1jE4FJIiyzV8lDT2D58Umyn7j+ugLczaiCV9ZvVJw4tE4MLAbLq+xjbwlru0hvcfRt6KIlukE78oGE77orpfkMus2YnA2OzgaiZrwXUaD5T9sKYgN3O7Q0jzHj+Y5Pa+1x8H9UiVaVn1EJamNjiZFazc2fkzisRNCDEEZtMOWv0ygP3N+X89dfOiaYyMmOy2xW6EwdhJmggeIGJm48lB/5pR5HlwIhH3dpkhbUVYkrWzxHhYFPRvd6Fs09zCogiDxPSnzBJcgbcHVxsKl0wtB6Gx9/83SPsysn5xK+avCKG0TSzDMzE8QdgWepMW6ZByOFXqtmsjSfHhXTy4czdg3CXeBk5++MrhThYnQlMEA8ahBhNlKq8vPb7pfimYMRRauhvYr2XfvvNGJBFBEY3QjZGdrhoaTYPeN8Ma35BjOAwXNIgA0t3iZKFRhkTr /hGMWdc3 O+NRRTy7a1jVoG3DmyrgPdh1VMf6z3tjHpmGvub5vLwEiVqwIfsOkJAGCr8Uz6OygniOgxC4w4YDnyOJ69NxSZl9ox2txEsv78WkuYO0QtdDdtS1OBHNXHoCALpaceD0uWfSQy4knoRvUdFE2FsKsIsgAFclklCO9EJznjDiwJWe1z3Zd28XIFtu2ub8cUnMQ3WX8T2Pg5lMX2WN83YbV6+V1LaI/1gmiU0zzD5foehWTeFkyYyXJsxT5P/AOM7XzVjoVlD6fJ+kSr1G0TFLFyGeTXIn5r6LEmMJYzJTWH4sLhownNZsBXbumjln/FF/+q+Xe/ERmEmpHwsTBciCj/9qeKU6h8irmFf4161bonBjrtlnc3Bt424mc0RXj8cD3XyYWKKzk8LDsZnzjONTROA2hPc195u/WsX1SKl6lekAUT/jJZ7L9P7gA6kSr2M7oRr6fgqvvBZ4UnSawpytzqfvW2wUN/ko/tl77FZ1VJRPkI1CMxZ7xbCQQwgDhNmqSr1ll4lhafp+y9fPtCSvzvzsFg6bM/rmaoBHxKiHgxgHoez3i9XthL8mh1Qwh1yHSJIS9dSWOMdO2PGqPcY4yfZaj5GpsD+yR6Oa0sIOWkCyDBovTR1tuRmYPQt0RjiCvloeG7B7fJCvrBHjQwARV6W9hL8vYJS4nE5sGuO0mtgKp9y86Wz6eddhfZvIu5vZPh9VCh+uWnf4CapaK+2ZIcEhXpfeix4+qzjZFj7ywA0LnqvEy9V7Fle20O8CZCwrOeae6oy46e8Mt2ZjMfwl5BOt330IWCBnAv8Zc5tfiC4kxqkdA78ol6ydtuJ+QRxsDPBj4vn4ZpEchoOWKXlCck0AMuu5CubnNAeANMz1EQmbJCU8XWgHRp7c3L4X8AhanI2D/eQPeoZijwAw3McdVaAku6feb2u6hBf7TSIirgPD3rRBM1bx17jATfqRbD00c0/GTssj0yT8VPKzla51wV0z4qEbs lop4Lbgi 1ox9r/IsMswhphX1xgceb1pwtdBh1Deus7LptjP9nALnWKimNIacai0lAq0T7bmrnOFrxqj6Vqxt/lOcgSPUG9LUnxwA/TmjA77ov3GNdCgVVwY/oeMJbQZNz8EPK2w5uEDs2GxNtH9+WzvkcVW/qgbV8w91WkWQ 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
Address Space Isolation (ASI)
|
expand
|
ASI is a technique to mitigate a broad class of CPU vulnerabilities by unmapping sensitive data from the kernel address space. If no data is mapped that needs protecting, this class of exploits cannot leak that data and so the kernel can skip expensive mitigation actions. For a more detailed overview, see the v1 RFC (which was wrongly labeled as a PATCH) [0]. This new iteration adds support for protecting against bare-metal processes as well as KVM guests. The basic principle is unchanged. .:: Multi-class ASI So far ASI has been a KVM-only solution, although I've been claiming that in principle it can be extended to also sandbox userspace. Dave Hansen's most important feedback at LPC [1] was that he wanted some evidence to support this claim. If it can be shown that ASI is just as powerful for bare-metal as for KVM, it's much more likely to actually offer an escape path from maintaining and reactively developing per-exploit mitigations. v1 already supported a notion of "ASI classes", with the only class being KVM. This RFC introduces a second class for userspace. Each process has a separate restricted address space ("domain") for each class. In v1, the only possible ASI transitions were between the KVM restricted address space, and the unrestricted address space. Now that there are multiple classes, it's possible to transition directly between two restricted address spaces. (Could we dodge this complexity by just transitioning via the unrestricted address space? Yes, but experience from Google's internal deployment suggests there's a significant benefit in avoiding an asi_exit() when switching between userspace and KVM, despite all the optimizations that exist to avoid that switching). Compared to v1, this version has a new mechanism to determine what mitigation actions are required when switching between address spaces. ASI classes provide a "taint policy" which describes what uarch state their sandboxee might leave behind, and what uarch state needs to be purged before their sandboxee can safely be run. The ASI core takes care of doing the actual flushes. This enables a reasonably advanced model of what flushes are needed when; for example the kernel is now able to model "when transitioning from a VMM to its KVM guest there is no point in flushing speculative control flow state, but if we _later_ exit to the unrestricted address space we do need to flush it". It's quite possible this is actually more advanced than what is needed so suggestions are welcome. .:: Performance issues: bogus mitigation costs Although this implementation of ASI is pretty generous in what it considers "nonsensitive", there remain unnecessary performance costs that need to be addressed. For example: - The entire page cache is removed from the direct map. Traditional file operations will hit an asi_exit(), paying a pointless cost to protect data from a process that obviously has the right to read that data. - Anything that accesses guest or user memory via the direct map instead of the user address space will hit an asi_exit(). - Pages being zeroed in the page allocator Most of these issues existed in v1 too, but now that ASI sandboxes userspace processes, the page-cache issue becomes very significant. For FIO 4k read (I suppose this workload is maximally sensitive to this issue) I saw a 70% degradation in throughput, with a Sapphire Rapids machine hard-coded to perform IBPB and RSB-stuffing on asi_exit(). Given a result like that I haven't gone into more detailed analysis. Note also that I ran with an unrealistic mitigation policy, results would be much different if ran with platform-appropriate flushes, but it would presumably lead to the same conclusion. There are some interesting discussions to be had about tackling that problem (e.g. reintroducing "local-nonsensitivity" from Junaid's 2022 ASI implementation [2], or creating ephemeral CPU-local mappings), but for this RFC I prefer to focus on deciding if the overall framework makes sense. .:: Next steps Aside from lack of userspace support, all the other issues listed in RFCv1 remain. I'll also need a proof-of-concept solution for the page-cache issue before we can credibly claim to be reaching a [PATCH], but before that I want to develop a more complete page_alloc integration. I plan to propose a topic about that at LSF/MM/BPF. Anyway, despite the further research needed on my side I think there's still useful stuff to discuss here. For example: - Does the "tainting" model make intuitive sense? Is there a simpler way to achieve something similar? - The taints offer a model for different parts of the kernel to communicate with each other about what mitigations they've taken care of. For example, KVM could clear ASI taints if it existing conditional-L1D-flush logic fires. Does it make sense to take advantage of this? (I think yes). How does this influence the design of the bugs.c kernel arguments? - Suggestions on how to map file pages into processes that can read them, while minimizing TLB management pain. Finally, a more extensive branch can be found at [3]. It has some tests and some of the lower-hanging fruit for optimising performance of KVM guests. [0] RFC v1: https://lore.kernel.org/linux-mm/20240712-asi-rfc-24-v1-0-144b319a40d8@google.com/ [1] LPC session: https://lpc.events/event/18/contributions/1761/ [2] Junaid’s RFC: https://lore.kernel.org/all/20220223052223.1202152-1-junaids@google.com/ [3] GitHub branch: https://github.com/googleprodkernel/linux-kvm/tree/asi-rfcv2-preview Signed-off-by: Brendan Jackman <jackmanb@google.com> Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Alexandre Chartre <alexandre.chartre@oracle.com>, Liran Alon <liran.alon@oracle.com>, Jan Setje-Eilers <jan.setjeeilers@oracle.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Lorenzo Stoakes <lstoakes@gmail.com>, David Hildenbrand <david@redhat.com>, Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@kernel.org>, Khalid Aziz <khalid.aziz@oracle.com>, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Valentin Schneider <vschneid@redhat.com>, Paul Turner <pjt@google.com>, Reiji Watanabe <reijiw@google.com>, Junaid Shahid <junaids@google.com>, Ofir Weisse <oweisse@google.com>, Yosry Ahmed <yosryahmed@google.com>, Patrick Bellasi <derkling@google.com>, KP Singh <kpsingh@google.com>, Alexandra Sandulescu <aesa@google.com>, Matteo Rizzo <matteorizzo@google.com>, Jann Horn <jannh@google.com> kvm@vger.kernel.org, Brendan Jackman <jackmanb@google.com>, Dennis Zhou <dennis@kernel.org> --- Changes in v2: - Added support for sandboxing userspace processes. - Link to v1: https://lore.kernel.org/r/20240712-asi-rfc-24-v1-0-144b319a40d8@google.com --- Brendan Jackman (21): mm: asi: Make some utility functions noinstr compatible x86: Create CONFIG_MITIGATION_ADDRESS_SPACE_ISOLATION mm: asi: Introduce ASI core API mm: asi: Add infrastructure for boot-time enablement mm: asi: ASI support in interrupts/exceptions mm: asi: Avoid warning from NMI userspace accesses in ASI context mm: Add __PAGEFLAG_FALSE mm: asi: Map non-user buddy allocations as nonsensitive [TEMP WORKAROUND] mm: asi: Workaround missing partial-unmap support mm: asi: Map kernel text and static data as nonsensitive mm: asi: Map vmalloc/vmap data as nonsensitive mm: asi: Stabilize CR3 in switch_mm_irqs_off() mm: asi: Make TLB flushing correct under ASI KVM: x86: asi: Restricted address space for VM execution mm: asi: exit ASI before accessing CR3 from C code where appropriate mm: asi: Add infrastructure for mapping userspace addresses mm: asi: Restricted execution fore bare-metal processes x86: Create library for flushing L1D for L1TF mm: asi: Add some mitigations on address space transitions x86/pti: Disable PTI when ASI is on mm: asi: Stop ignoring asi=on cmdline flag Junaid Shahid (4): mm: asi: Make __get_current_cr3_fast() ASI-aware mm: asi: ASI page table allocation functions mm: asi: Functions to map/unmap a memory range into ASI page tables mm: asi: Add basic infrastructure for global non-sensitive mappings Ofir Weisse (1): mm: asi: asi_exit() on PF, skip handling if address is accessible Reiji Watanabe (1): mm: asi: Map dynamic percpu memory as nonsensitive Yosry Ahmed (2): mm: asi: Use separate PCIDs for restricted address spaces mm: asi: exit ASI before suspend-like operations arch/alpha/include/asm/Kbuild | 1 + arch/arc/include/asm/Kbuild | 1 + arch/arm/include/asm/Kbuild | 1 + arch/arm64/include/asm/Kbuild | 1 + arch/csky/include/asm/Kbuild | 1 + arch/hexagon/include/asm/Kbuild | 1 + arch/loongarch/include/asm/Kbuild | 3 + arch/m68k/include/asm/Kbuild | 1 + arch/microblaze/include/asm/Kbuild | 1 + arch/mips/include/asm/Kbuild | 1 + arch/nios2/include/asm/Kbuild | 1 + arch/openrisc/include/asm/Kbuild | 1 + arch/parisc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/Kbuild | 1 + arch/riscv/include/asm/Kbuild | 1 + arch/s390/include/asm/Kbuild | 1 + arch/sh/include/asm/Kbuild | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/um/include/asm/Kbuild | 2 +- arch/x86/Kconfig | 27 + arch/x86/boot/compressed/ident_map_64.c | 10 + arch/x86/boot/compressed/pgtable_64.c | 11 + arch/x86/include/asm/asi.h | 306 +++++++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/idtentry.h | 50 +- arch/x86/include/asm/kvm_host.h | 3 + arch/x86/include/asm/l1tf.h | 11 + arch/x86/include/asm/nospec-branch.h | 2 + arch/x86/include/asm/pgalloc.h | 6 + arch/x86/include/asm/pgtable_64.h | 4 + arch/x86/include/asm/processor-flags.h | 24 + arch/x86/include/asm/processor.h | 20 +- arch/x86/include/asm/pti.h | 6 +- arch/x86/include/asm/special_insns.h | 45 +- arch/x86/include/asm/tlbflush.h | 6 + arch/x86/kernel/process.c | 2 + arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/traps.c | 22 + arch/x86/kvm/Kconfig | 1 + arch/x86/kvm/svm/svm.c | 2 + arch/x86/kvm/vmx/nested.c | 6 + arch/x86/kvm/vmx/vmx.c | 113 ++-- arch/x86/kvm/x86.c | 81 ++- arch/x86/lib/Makefile | 1 + arch/x86/lib/l1tf.c | 96 +++ arch/x86/lib/retpoline.S | 10 + arch/x86/mm/Makefile | 1 + arch/x86/mm/asi.c | 1039 ++++++++++++++++++++++++++++++ arch/x86/mm/fault.c | 124 +++- arch/x86/mm/init.c | 7 +- arch/x86/mm/init_64.c | 25 +- arch/x86/mm/mm_internal.h | 3 + arch/x86/mm/pti.c | 14 +- arch/x86/mm/tlb.c | 167 ++++- arch/x86/virt/svm/sev.c | 2 +- arch/xtensa/include/asm/Kbuild | 1 + drivers/firmware/efi/libstub/x86-5lvl.c | 2 +- include/asm-generic/asi.h | 113 ++++ include/asm-generic/vmlinux.lds.h | 11 + include/linux/entry-common.h | 11 + include/linux/gfp.h | 5 + include/linux/gfp_types.h | 15 +- include/linux/mm_types.h | 7 + include/linux/page-flags.h | 18 + include/linux/pgtable.h | 3 + include/trace/events/mmflags.h | 12 +- init/main.c | 2 + kernel/entry/common.c | 1 + kernel/fork.c | 5 + kernel/sched/core.c | 9 + mm/init-mm.c | 4 + mm/internal.h | 2 + mm/mm_init.c | 1 + mm/page_alloc.c | 160 ++++- mm/percpu-vm.c | 50 +- mm/percpu.c | 4 +- mm/vmalloc.c | 53 +- tools/perf/builtin-kmem.c | 1 + 80 files changed, 2582 insertions(+), 190 deletions(-) --- base-commit: ebd6ea9c6976c64ed5af3e6dce672616447e8e62 change-id: 20241115-asi-rfc-v2-5d9bbb441186 Best regards,