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 D4B63C282EC for ; Tue, 18 Mar 2025 00:50:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F386280002; Mon, 17 Mar 2025 20:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97CA3280001; Mon, 17 Mar 2025 20:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D06E280002; Mon, 17 Mar 2025 20:50:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5BD75280001 for ; Mon, 17 Mar 2025 20:50:23 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8BDCD1A0681 for ; Tue, 18 Mar 2025 00:50:24 +0000 (UTC) X-FDA: 83232840768.18.7542A31 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf25.hostedemail.com (Postfix) with ESMTP id 9457CA0006 for ; Tue, 18 Mar 2025 00:50:22 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A7kfIw+Y; spf=pass (imf25.hostedemail.com: domain of junaids@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=junaids@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=1742259022; 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:in-reply-to:references:references:dkim-signature; bh=jyS5rCxr8EQqFWu2KoBKo/0nF0NkexL7fmn9bWW5ufc=; b=gblHhWfbMM1IJDjjWy8dmHd1CV5/qzNVKv+5Kfo7veCFq+W3LhjW4MrdDn8tdANHBsMdMe 1IoO2KNma0alTcCusxWMzHt75VBFyoiInxJVRc/d/XXYOhIlYvlxuU4/EH/RepGstmXIhX Y5mvc4sDW3HwzZBFmjwASkwzSpOhaAA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A7kfIw+Y; spf=pass (imf25.hostedemail.com: domain of junaids@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=junaids@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742259022; a=rsa-sha256; cv=none; b=No3RmqAF3c5FjQ8Shb9rG0MSTBACFUuQ5wk2RHchiFCvXuS762AmLSo9w60jPK2Y2ruz89 MWANOP6eKHhbVrPP/9GX0H3W2GA0mLyV86COFVpTvbS66tB7jEgn3PebdhYY45IV8vaojB yN09aDgbQtX0Acp2ThdtwCcpaYDTuqU= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2240aad70f2so80395ad.0 for ; Mon, 17 Mar 2025 17:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742259021; x=1742863821; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jyS5rCxr8EQqFWu2KoBKo/0nF0NkexL7fmn9bWW5ufc=; b=A7kfIw+YAQiCMjrm9PU8UGFBGU6i+nnw21pxv97zsYHV7nPHtqL2nEUW3Ep72AUpeE 8f0oFxOrB+6A2o7Si+B81bRR6XfKlbR62iuip3G72oEkLP+EME+gvn/0GBN2cZG2gtT2 U//ZAdQRFcYMnrmoQcwSWwlS1uTHAkpO+tZoYh1N/FbVfYTVKyPmhD6jmK3TZqdcc9/o hzpW8ud3Q0m5V7hltJzF0ljam+aShq7HVpiC/FYOFtFAU1bSCgsBpddFV9ezTRfTR9ns FegfuFurJB1GEHD1oDybuqOlmYMcOdEPuAyZ6g7ts/SQSY8d2+7bIJU/pWdA7MMQX0GV WMPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742259021; x=1742863821; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jyS5rCxr8EQqFWu2KoBKo/0nF0NkexL7fmn9bWW5ufc=; b=jRLlpVTpLvtx41WuXCGYTsTFqjpZO69P9ICUJ8e+IiNO0c5oSbrtc1io510Juid3Vi a9unNu7+0PrHmcB2+syux/5yYNqRZjjlldawIhgPg9EXoVl7LDjsESigQZ7/4ENjR1NG nsijWP4/FJCmQD1gWnvYjgA6I5PqAy9i7Yo4JsYmX9IntJgHyPoi+mXE1GI9TiF6zNMs 8+CxYcW6EgS0s0ci3OLGgRRg6H0l3BrrkwM7f4IpR3r7FMLFpS+pcSm6jIxosLXt+LI+ +HqpAkr8O9Sw/C9t1DN+aO9xcxQyZYfAQJFdhZK2Uc/XORhknAhtiwvaIYF6F+PQBtD+ 0/6A== X-Forwarded-Encrypted: i=1; AJvYcCX5g9nZBhFm4B/sfMtsSUvKeI2r0f2sGb7DfgT8/K0OfERGoiHHhVLkox/j3RcjsZQ+ptW+NTs21A==@kvack.org X-Gm-Message-State: AOJu0Yw9gEYVjD8oGpas60OyXJBQEzMaqkwsVw0BDohBusuYNde3pc4C G+Y7lQdPbBM5G2EHnfsOZ2OHu249F7WHn6ZJNgeOyAcijRF4CKqoHZ/reZBVcw== X-Gm-Gg: ASbGnctLJQe2bIBfMdHbvARwCPJpuhD+RrNcKj/e/0IloYLCa9pnegDPmbdmG48S76b cHARkuYQdmswuqbA7qTSlps4KcQBrG67G2EquvIY/WselpGOiw/KQHrngXU4B9LteUdo3DNQWlC kDnBCdaIco1Gp8rmoOw0CJXyR1IrVQXJtbq7yycALhVUgk65J467oiliyjJ+GUoOceOSuN+oE2Q kFOHdiyZHGT9+NKjjjKL+JLEZP7xAqiYp9Hi0gBnbXAI5D+XDh+r1DohU4pZrZUO9JfxAAFBHfP u1EjFAMwD7h72rZOBBfTB/ULcymjXvacYYmRXYmUtkvOsDsg1+F4sMW8M1SXRYV314NSbGpwMz8 JMMd+Ij+NDJQtYPf5mQ== X-Google-Smtp-Source: AGHT+IHphGAwUXfXr7Mrrbm3vJ5pDrNsyjOLR/aaUMGpU3EUMn5PRxeescEk16cYhxEl8m70XssWNA== X-Received: by 2002:a17:903:8c4:b0:216:21cb:2e14 with SMTP id d9443c01a7336-226357e0c41mr127135ad.21.1742259021211; Mon, 17 Mar 2025 17:50:21 -0700 (PDT) Received: from ?IPV6:2600:1700:38d4:55d0:4268:be3e:41c6:d4b4? ([2600:1700:38d4:55d0:4268:be3e:41c6:d4b4]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-301539d3f4bsm6814559a91.5.2025.03.17.17.50.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Mar 2025 17:50:20 -0700 (PDT) Message-ID: <4ce0b11c-d2fd-4dff-b9db-30e50500ee83@google.com> Date: Mon, 17 Mar 2025 17:50:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API To: Brendan Jackman , Borislav Petkov Cc: akpm@linux-foundation.org, dave.hansen@linux.intel.com, yosryahmed@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, seanjc@google.com, tglx@linutronix.de, x86@kernel.org References: <20250227120607.GPZ8BVL2762we1j3uE@fat_crate.local> <20250228084355.2061899-1-jackmanb@google.com> <20250314131419.GJZ9Qrq8scAtDyBUcg@fat_crate.local> <5aa114f7-3efb-4dab-8579-cb9af4abd3c0@google.com> <20250315123621.GCZ9V0RWGFapbQNL1w@fat_crate.local> Content-Language: en-US From: Junaid Shahid In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9457CA0006 X-Stat-Signature: 645gmi8csjwcesucfk464a7yusthagqh X-HE-Tag: 1742259022-569087 X-HE-Meta: U2FsdGVkX1/DSYnSUKUdZ/8TPx1w+WZEtWir78jrhJ3dJ5VmOMu6zNtiQyt3ykYgpLmh1v1ag6kB/6+W3ytugU/3x5UTknbiUcd6+a+4UzzDW8WubyJAhi3GH2ZrUqMBXtVxeizs/ggYEV8/S5FKNOvaT1hAGeM2zLZKchaI+YxbboJGRP3K1LKfPBJVsAHToeU66q1XbPXUnBGDhl/7/+QZBEZobMSX9+NdMjYCEV+/mSFlJFzlgumIBC3mG13xxyd65Jba43NDD+t4PXuleJNX9gppMN0ZGvTWPBFdWRrE9ui1kN7X0mxmBEgO56fhkhxECM7cpSfyYlzB566RO6nMNonBhVzdxmUjHNnw2FEMLd7MwQ0FvAa8OKiPvr4Z9iIn+/egvZrttjeZH/lxH7zmaRoT0HeXf4gPbykMn1W6syUu6+S1GwfQgV9xl24DFmcnzDGpU/Hoj6ZNdWoyTAk8sMI3Z3qyE25ZhBEzlQRUUUg4CKpSVrYlDvZFFMZjsoHfOVFPTG5nhIrI+xgxhgzfbdHfFB9Qu/PRle8AVDWIy3Br0AVvbAk/vvZKq1yDA1IHT59V0okX1xUcSNkIpNg5Jd08oDfskmfj13DYeZ2DHakSWLHyG+yeEIRNYubsgaUWgOrd/ul/LO/DNtbI/h4OczkRreYiKnNu2vx9A+5YF9zvQgGhc0Iwo40mofJx6I4hjQBIDOxurPgnv7T+c8aAkWCG6wYxyhqrMCImHfmBhprPBYahWC6BkR2qtGgZloFYiXJqcwGCXjtPmQB3hz6B9y6XRZz6OGPyBgUZJpuRtaa6J0Vc52KvsvMQXc1/AGWMZgx/gkX44qNeqzr/M8aIpPIrD7cQ1iqznX4K31QOknXtEkFrVwaOHqAHXTNHiEQ+yC/44vnFXd9fvs3vpVR58F4Li79pwwP/bNmJ9y3jI00b5AAHMKDeyKq2xPUn9HfoUc0mnuzj5s06WfR 34MwGh7G RcwfR5xCJLDxGBdgacjVcdvwN+SJ74mFXnYentjLnz8xGIZ4FLfeelmb2Gg6oE8fxm8nXRWchXscRjRDzGXC/dt4iICR5Gs2Nw5k75IFiISVHjSmwe7WBSXPB73+x4jxe95WpiAv66vhYdcPLYN5hM7xRxHmFQ3iqtDa4Cj4tQQtUpBJve1f+t8XrrasXmh0jvIa8MO7J3rpdT4B3xPAxRFc0NILGvS2O5NItzVkfI1FT8ru3IFbylZBeU1kSO5ViHHUeNWwzjM5FGr0pOVSJiR5TquRY4CysGXkCR1Bv9IoZ6tiWoZGu7YhUUWSl00lBdTZ6Ewgd1Tanz6CT9oSpofnDt0tRM9xHYL+M0V5ptRUORGCyp60VcNGnZQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003468, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 3/17/25 4:40 AM, Brendan Jackman wrote: > > I don't understand having both asi_[un]lock() _and_ > asi_{start,enter}_critical_region(). The only reason we need the > critical section concept is for the purposes of the NMI glue code you > mentioned in part 1, and that setup must happen before the switch into > the restricted address space. > > Also, I don't think we want part 5 inside the asi_lock()->asi_unlock() > region. That seems like the region betwen part 5 and 6, we are in the > unrestricted address space, but the NMI entry code is still set up to > return to the restricted address space on exception return. I think > that would actually be harmless, but it doesn't achieve anything. > > The more I talk about it, the more convinced I am that the proper API > should only have two elements, one that says "I'm about to run > untrusted code" and one that says "I've finished running untrusted > code". But... > >> 1. you can do empty calls to keep the interface balanced and easy to use >> >> 2. once you can remove asi_exit(), you should be able to replace all in-tree >> users in one atomic change so that they're all switched to the new, >> simplified interface > > Then what about if we did this: > > /* > * Begin a region where ASI restricted address spaces _may_ be used. > * > * Preemption must be off throughout this region. > */ > static inline void asi_start(void) > { > /* > * Cannot currently context switch in the restricted adddress > * space. > */ > lockdep_assert_preemption_disabled(); I assume that this limitation is just for the initial version in this RFC, right? But even in that case, I think this should be in asi_start_critical() below, not asi_start(), since IIRC the KVM run loop does contain preemptible code as well. And we would need an explicit asi_exit() in the context switch code like we had in an earlier RFC. > > /* > * (Actually, this doesn't do anything besides assert, it's > * just to help the API make sense). > */ > } > > /* > * End a region begun by asi_start(). After this, the CPU cannot be in > * the restricted address space until the next asi_start(). > */ > static inline void asi_end(void) > { > /* Leave the restricted address space if we're in it. */ > ... > } > > /* > * About to run untrusted code, begin a region that _must_ run in the > * restricted address space. > */ > void asi_start_critical(void); > > /* End a region begun by asi_start_critical(). */ > void asi_end_critical(void); > > ioctl(KVM_RUN) { > enter_from_user_mode() > asi_start() > while !need_userspace_handling() > asi_start_critical(); > vmenter(); > asi_end_critical(); > } > asi_end() > exit_to_user_mode() > } > > Then the API is balanced, and we have a clear migration path towards > the two-element API, i.e. we need to just remove asi_start() and > asi_end(). It also better captures the point about the temporary > simplification: basically the reason why the API is currently > overcomplicated is: if totally arbitrary parts of the kernel can find > themselves in the restricted address space, we have more work to do. > (It's totally possible, but we don't wanna block initial submission on > that work). The simplification is about demarcating what code is and > isn't affected by ASI, so having this "region" kinda helps with that. > Although, because NMIs can also be affected it's a bit of a fuzzy > demarcation... Not just NMIs, but other IRQs can also be in the restricted address space even in this initial version. But that is of course still significantly less in scope than the general case, so the demarcation of process-context code via asi_start()/asi_end() does indeed seem useful. Thanks, Junaid