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 EC844C021BE for ; Thu, 27 Feb 2025 12:08:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3276F280003; Thu, 27 Feb 2025 07:08:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AEE9280002; Thu, 27 Feb 2025 07:08:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 127A4280003; Thu, 27 Feb 2025 07:08:10 -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 EEC46280002 for ; Thu, 27 Feb 2025 07:08:09 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AC54CB6790 for ; Thu, 27 Feb 2025 12:08:09 +0000 (UTC) X-FDA: 83165601498.17.08DF1F9 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf24.hostedemail.com (Postfix) with ESMTP id 0CF24180053 for ; Thu, 27 Feb 2025 12:08:06 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=BMe+FVpY; spf=pass (imf24.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740658088; 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=klXDwLNu+GdgxiSQ4cKCu+o7Hgj9jWo4+xGGDdoiKyM=; b=i4CBb6kE+vw/bOp/exxB5a3cD503BSgCiB2ARxDtUtDOcYbAedPS4U5/VmxGh4r+EAm0EP S9L4qXwIZXFPGOtAd6RtZCMCCNaSho+eks7HoCRmOVOhYw1EY8gPl2XEqv2NBo0qGXe89I gqgZbHpKVbh77DgbSPGx9dOc5qwNyVU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=BMe+FVpY; spf=pass (imf24.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740658088; a=rsa-sha256; cv=none; b=rzmLS5r6ngIoK/7J/xzrEvgFB2ZP/UD4oQqJtkpWCunrvNG/vaUGv7XK295wdT1jC+SiPX AEUL3FtubuUgFBwu7wxSFqVGF/B+8/PUv7jIPxihRarDJfiFpelb+M8aMp6wgDjZVpENcc oZEonv+w30RPlyoMdM1HZslfkpez880= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 77DAC40E0212; Thu, 27 Feb 2025 12:08:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R18feXAmOzU1; Thu, 27 Feb 2025 12:07:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1740658078; bh=klXDwLNu+GdgxiSQ4cKCu+o7Hgj9jWo4+xGGDdoiKyM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BMe+FVpYcnybJXXM2DdS37JwfSoPjAjvLDkEei7ZnqXysLs4iK+doGH7m/kT0gYh7 ++DAAp3QJBrwYKZDWMkcrgrTUol6djyrM3PAJLTG5gwHcjuWEVB8zNoukan/C/PQ11 VBeOyvhKkj6uHDj32a7Vl0dKvIogDTdExZn6ec3gXiNFsTi+RwX2Vi4pQDzZVNTgHZ ZxQKdTlmVprEPa0V7BJX6GypLd04/lkwSOyDPqwnLOi4ISZjn0WbRawbQ+HbKLji+v 2nr/ZmneryOruZtGuC9hKOSlT8Qmj0ks+9xX+oUwgVHadfc6UNYe9EDSWRKyFsmqcQ fH5+662Bb9j7+crgFmGFms2EFfEwKBW416LJ3uC/q8CeBjMKIWr+A4nt6CzMP9lOXn Z02/yORitAPE040Sg3gv+PjB2rD2WmrOLlcsTWfgfRltYkWm3z7o52Hn5LPPVQ4JVo in/A7jJlP3/Z1XOb8F5WC/dnYg1y0mm5oNrg7k3EtHqcOn4Yfs2XAscnEr0T+ky2O1 Nap2xfrlYXyJvYDw5LNMmUSVqYjSMSWbxCSUtNERR+0ekVMQKOKCsJ6Q+8F8HrrIqr 7ubOOnDQNwweaU76vvfKs8TK4hKox8lItZKO9Nh3aofHkBlHoJzNjbCoK3ke/kT4xj A0pA8X13r5RWpUZJZYjU738s= Received: from zn.tnic (pd95303ce.dip0.t-ipconnect.de [217.83.3.206]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 3CE2240E01AE; Thu, 27 Feb 2025 12:06:13 +0000 (UTC) Date: Thu, 27 Feb 2025 13:06:07 +0100 From: Borislav Petkov To: Brendan Jackman Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Richard Henderson , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Guo Ren , Brian Cain , Huacai Chen , WANG Xuerui , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Dinh Nguyen , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , "David S. Miller" , Andreas Larsson , Richard Weinberger , Anton Ivanov , Johannes Berg , Chris Zankel , Max Filippov , Arnd Bergmann , Andrew Morton , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Uladzislau Rezki , Christoph Hellwig , Masami Hiramatsu , Mathieu Desnoyers , Mike Rapoport , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Dennis Zhou , Tejun Heo , Christoph Lameter , Sean Christopherson , Paolo Bonzini , Ard Biesheuvel , Josh Poimboeuf , Pawan Gupta , 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, Ofir Weisse , Junaid Shahid Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API Message-ID: <20250227120607.GPZ8BVL2762we1j3uE@fat_crate.local> References: <20250110-asi-rfc-v2-v2-0-8419288bc805@google.com> <20250110-asi-rfc-v2-v2-3-8419288bc805@google.com> <20250219105503.GKZ7W4h6QW1CNj48U9@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0CF24180053 X-Stat-Signature: k1j9y66xc4y3hjd6ggef8hmon1u34qgs X-HE-Tag: 1740658086-372066 X-HE-Meta: U2FsdGVkX1/Aiv1P6be2z90qEpvELs4ivKAKI/yxwk8nVExiup1OJwagL8nmjlcEIVKhbJA3fzv3dHs2/sz5pXM/KykbwB3mfu3np34xVg4qXaEdLB3iNDdiyaUzaQn61ZoBm1Il1/wD8u2jIw1Vzj7DyDqOJTE9yuAgd6gD05y6eImTHKNSs/HH8akRNB9IGvw0UQ5bBEUqZzl5iiqML1eDAzf4Mc/SHMHdnEWJSS/aTCTIxGk5aI45THm9TkBz2PjOywN3uucYztc2cREnRXtXYz3UU+FKVrCgy/fPMjqbIC3tJdSUfXojYzxmNrRC60sEtnxP1FlQyp7UovSADZR9bbHgkcPhUvA/dZyyjNc/4dr42WkFHjpTN8Bx8q6ao43b+637SI/AqHo5yUuWqTp5c595KVtytAn7VQ8Gnd8hxUoL2mrB51gPylrEyrDaV8qw5p1mytwjxGxxuFpSJflOr7QrRXD8Xswz1BLu5i3kDqPVCnLiyAt63feDwwrLN4HaxJ/nBaQQ6DHxJoYIUNESFLzsZPCQB4qFXXBnOg/f5B8VJISNKjHxaYO8f+oRLrAPj8MbKkM4TuHnxGVwVMvWVmcn1ToAndNL/6vwtGnBmydQ3H1MT5dqmEgc21+TXCnMRt2MiAMFg0YDXNWoXM3fEZCFT85dxbtWnTmWIUPmdrB0EjVTF6vD72sNUVpmlXB3bGK3TA4TyPb8LK+/n2W3OdqZbb3DBWBmsCneUpoNKtNUqFXVpMm4qsQ0QBBHLQbktOFHog/4/IJ6oDWwlMhpJILwjMkIibVySUsrpgoc3UoCmGtxa2zSvHPj/QuRm48ZCW0LCKHUBH/VrXIU44TI1DXAs6XXZR2jn1ied1PdaBj7tbMswf1Tx8gwsebYPz2ZKanf7OHvqRxrFrLg3OFKNKNtAR8UZz1wBpd01GrmDMVUDZA5lsUx3cmYXxl1b8c+B3ZiRqqmronKi1U ir9d9POe LhsdPmY61FbT35RQQKrQEeZk9okmtr/x2S2Zua9o9tVFaRW74np4zVap5JTIvnYgAddOeyFsOKKU7VtFLXEJJ3hWnl8EHVhPobi91l3WClcIIhNkmI6aImK1bEta5rHONTDuMt6e3ae+2Q+tUReV1rrv+TwfCrRBF/jia7D/lZyOVAyOfFXCaPAYqlNL7rc2c3YMRjn3pmmZnbKG4aVJMW8VQjxbyxkBNXmlMq4qmUQLCsyxtniOh5bD5GKg1A5XMXm2z8h29GXMBfE2Kg9nXaXrbHK7UuVjhvFvFsTqJRnjL014= 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: List-Subscribe: List-Unsubscribe: On Wed, Feb 19, 2025 at 02:53:03PM +0100, Brendan Jackman wrote: > Argh, sorry, GMail switched back to HTML mode somehow. Maybe I have to > get a proper mail client after all. Yap, wouldn't be such a bad idea. And yes, it ain't easy - we have a whole doc about it: Documentation/process/email-clients.rst > OK, sounds like I need to rewrite this explanation! It's only been > read before by people who already knew how this thing worked so this > might take a few attempts to make it clear. > > Maybe the best way to make it clear is to explain this with reference > to KVM. At a super high level, That looks like: > > ioctl(KVM_RUN) { > enter_from_user_mode() > while !need_userspace_handling() { > asi_enter(); // part 1 > vmenter(); // part 2 > asi_relax(); // part 3 > } > asi _exit(); // part 4b > exit_to_user_mode() > } > > So part 4a is just referring to continuation of the loop. > > This explanation was written when that was the only user of this API > so it was probably clearer, now we have userspace it seems a bit odd. > > With my pseudocode above, does it make more sense? If so I'll try to > think of a better way to explain it. Well, it is still confusing. I would expect to see: ioctl(KVM_RUN) { enter_from_user_mode() while !need_userspace_handling() { asi_enter(); // part 1 vmenter(); // part 2 asi_exit(); // part 3 } asi_switch(); // part 4b exit_to_user_mode() } Because then it is ballanced: you enter the restricted address space, do stuff and then you exit it without switching address space. But then you need to switch address space so you have to do asi_exit or asi_switch or wnatnot. And that's still unbalanced. So from *only* looking at the usage, it'd be a lot more balanced if all calls were paired: ioctl(KVM_RUN) { enter_from_user_mode() asi_switch_to(); <-------+ while !need_userspace_handling() { | asi_enter(); // part 1 <---+ | vmenter(); // part 2 | | asi_exit(); // part 3 <---+ | } | asi_switch_back(); // part 4b <-------+ exit_to_user_mode() } (look at me doing ascii paintint :-P) Naming is awful but it should illustrate what I mean: asi_switch_to asi_enter asi_exit asi_switch_back Does that make more sense? > asi_enter() is actually balanced with asi_relax(). The comment says > "if we are in it" because technically if you call this asi_relax() > outside of the critical section, it's a nop. But, there's no reason to > do that, so we could definitely change the comment and WARN if that > happens. See above. > > > > > > +#define ASI_TAINT_OTHER_MM_CONTROL ((asi_taints_t)BIT(6)) > > > +#define ASI_NUM_TAINTS 6 > > > +static_assert(BITS_PER_BYTE * sizeof(asi_taints_t) >= ASI_NUM_TAINTS); > > > > Why is this a typedef at all to make the code more unreadable than it needs to > > be? Why not a simple unsigned int or char or whatever you need? > > > My thinking was just that it's nicer to see asi_taints_t and know that > it means "it holds taint flags and it's big enough" instead of having > to remember the space needed for these flags. But yeah I'm fine with > making it a raw integer type. You're thinking of some of those rules here perhaps? https://kernel.org/doc/html/latest/process/coding-style.html#typedefs Probably but then you're using casts (asi_taints_t) to put in integers in it. Does it matter then? Might as well use a plain int and avoid the casts, no? Unless there's a real good reason to have a special type and it is really really good this way...? > Well it needs to be disambiguated from the field below (currently > protect_data) but it could be control_to_flush (and data_to_flush). > > The downside of that is that having one say "prevent" and one say > "protect" is quite meaningful. prevent_control is describing things we > need to do to protect the system from this domain, protect_data is > about protecting the domain from the system. However, while that > difference is meaningful it might not actually be helpful for the > reader of the code so I'm not wed to it. > > Also worth noting that we could just combine these fields. At present > they should have disjoint bits set. But, they're used in separate > contexts and have separate (although conceptually very similar) > meanings, so I think that would reduce clarity. Ok, I guess it'll tell us what is better once we stare at that code more. :) > Ack, I've set up a local thingy to spellcheck all my commits so > hopefully you should encounter less of that noise in future. Yeah, I use the default vim spellchecker and it simply works. > For the pronouns stuff I will do my best but you might still spot > violations in older text, sorry about that. No worries. > What this field is describing is: when we run the untrusted code, what > happens? I don't mean "what does the kernel do" but what physically > happens on the CPU from an exploit point of view. > > For example setting ASI_TAINT_USER_DATA in this field means "when we > run the untrusted code (i.e. userspace), userspace data gets left > behind in sidechannels". > > "Should be set" in the comment means "this field should be set to > record that a thing has happened" not "this field being set is a > requirement for some API" or something. So I don't think "required" is > right but this is hard to name. > > That commentary should also be expanded I think, since "should be set" > is pretty ambiguous. And maybe if we called it "to_set" it would be > more obvious that "set" is a verb? I'm very open to suggestions. I think the explanations you give here should be condensed into comments over those things. They're really helpful. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette