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 69897C77B7C for ; Wed, 25 Jun 2025 18:52:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F13596B00D0; Wed, 25 Jun 2025 14:52:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC4576B00D1; Wed, 25 Jun 2025 14:52:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB31D6B00D2; Wed, 25 Jun 2025 14:52:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C72E66B00D0 for ; Wed, 25 Jun 2025 14:52:25 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 45FBDC06EB for ; Wed, 25 Jun 2025 18:52:25 +0000 (UTC) X-FDA: 83594818650.12.FC1AD9F Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf29.hostedemail.com (Postfix) with ESMTP id 63DE6120008 for ; Wed, 25 Jun 2025 18:52:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=T4uM1rib; spf=pass (imf29.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750877543; 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=N2YGqiZBGlO6E2pCvNxokF1iVnO9tprfKl6nqK15f7Q=; b=BTWO9tUDXsQleY06zfu05AqhbZWBPdJS8iQHIbWuOp4WkM8UC/DFg9G0JdQ3PJXUDD+pE9 8IR5iedHQ9CR+NiKtU5iPvwXjWfYHPQgSyys1iDv1TE015BpsUrdky8FcHvpZhXF4k8Kuf mHbObDgB29a3rqxWvr4Vm98c6rMruVk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750877543; a=rsa-sha256; cv=none; b=p/lLDwc8UV1UwBEmT4vM9fB+hiHeiZEwSljzerxyJ/eTu9N7I2ErYtfZD6wBGzYQ3UPGAD YZPSfU+tw4pDMnuIgNPfztNmz8sNp9QhppNaRwXXtcEErVq9v3XUSjRRmUUKdI5/AuBICr tA5+Bqfl6joo5cdH7cOPlV4j9KdHIHY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=T4uM1rib; spf=pass (imf29.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com Received: from [127.0.0.1] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 55PIpReE1893008 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Jun 2025 11:51:28 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 55PIpReE1893008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025062101; t=1750877492; bh=N2YGqiZBGlO6E2pCvNxokF1iVnO9tprfKl6nqK15f7Q=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=T4uM1ribSNJKs3WHN1pHdyHhSope6PhIW4wyzfSNMx2tpP1w2IBhSFlFMiaHsho/m 7Wz/UJGtehR+fUj4tSpmUubhuu+k47y9Yz+imDe03hW32zObTCMViWML+TQybmWkF4 7sTE5spXJx1bKzdDxKLjkBVvZOfzIgax3hg98CCfNFroUV56fnJQ12QTDpfipSYmq6 XBrmJ4G1G1naZF09+cdJDMJI+ZWRR01dL64c4gcEy6p5RulFiQJJGe92XnAUpZ4mSB QsTa1c5PNASclR2hntJQ2dT9nJ+AT7KZa2JgOVoicw0rP7V3jfWNyw0yWfmnhmGHGA KEAYnAkOGVr0Q== Date: Wed, 25 Jun 2025 11:51:28 -0700 From: "H. Peter Anvin" To: Sohil Mehta , "Kirill A. Shutemov" , Dave Hansen CC: Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, Yian Chen , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Subject: Re: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits User-Agent: K-9 Mail for Android In-Reply-To: <248e272c-79ec-4c11-a3a8-dff1de2147c0@intel.com> References: <20250620135325.3300848-1-kirill.shutemov@linux.intel.com> <20250620135325.3300848-2-kirill.shutemov@linux.intel.com> <248e272c-79ec-4c11-a3a8-dff1de2147c0@intel.com> Message-ID: <91ACE1D6-851A-413E-9F1F-F015A36FE49C@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 63DE6120008 X-Stat-Signature: opktiqofxcss3a8bifrg9frwihh6aefp X-Rspam-User: X-HE-Tag: 1750877543-174173 X-HE-Meta: U2FsdGVkX1+zPfy+XaelkkOGZLgfFI5uOW7yHbrhtV1yD9E74zjGYDXA9SDUAcFRUm5KFWNjkN+xnt8DYt/1NPGtXxTgyWzoewKyW2zKso4uDdOkUyW+8L+EWhWpizBXy9aG4eqA+8KlhPPUwkv70nPEbMUjBvlsjzCd+FtjcFEm5gWkOTqU2VCZKKMTybfmPn4vK9Ofbjz9pNnntvM9KIkYyCgify4044JIT8WWb97EYBtacF7JnwDmnHFJAkfe/tRFMrSMZttY6TuDDfzaHgsci7oDry0nCJ+cX1qtpGfq5i9kw4082EBKzN4FGSA6XT/NWLCCOijqD1z91Gq/okMu/GWJ6pklvLsL2PBwwlC2iOYKIivjWZfZnfyGvZn1KtDFJ2YFNRp36wm1LWc17fYgOL/7g0qgI9vtTNuLwwtyqvak9AhlX1lCKTIXEjgPAXopa6NUlkPLyCMUQNdaBxSZ6HjsI3KSv2j5NTpnt1OehgGUcGwG+ikW7+9qyAVqmsmEF373OMP/O+FDWJ8Jrr3Hz5Dt87+RpTS5XnHkt3LkVMsc26iIu/oc1WNbCOaMr9UAqsLjJrNDC1X+hOMnalqHozfdhFP9affG9v6buckPfgqxJMeNN663hbUoys/7F0Y4qRNZTQsIfoHl8l+VysHRPrlY3PBc1O06404QmafaGTQ40cYR+h2h7UX9uYSGoJ4Sl9W6YxULisiVRPvSxhAFEn7QZXHk3/Z4GU8BrttLJPk3JPm0grm5Zi9rPw5YCy+qQPt2U3IF2XeYhz2EPipBXOs1C9268zkS9YnmRxJmCRbUSFqweJI46ImmOm2jvHU9/7znVpB+vvixlSR/m7XF2+VUwr6OtlpcxiOoV9wrJ4cfMhodk730g4sOrGrqqfblQoNdyb8xsreIEj8N5XmgPif9Pa6vNPq8sGYyZNly3HUHPEnRDfyqbQXwGEw4QaabrtqyK8pahcHaJxu XKeMb62K T0093GJZ1B5AA8+RM5Khv0okiG+nYXalpB62nI3dCQq/zQ2avqJGCmSLMux7e4Lg9u+tRvARqxZGd+YrTnQ48DRDbisjFbQ03ZbWi2NWi/qwdRXnAyLELbb0htJo6cT8gCRVNYsYRoCONKbJQFQJ3c96iWJ8DZHiSeXMl/2BXRIzSPtEqKqS3wx8HCWPwIKJHPS+jHJzQ12cA2KLykenpxSug9v3MUAWiwAWeHAFUc7/DYIGbEFW7idQ5f0YBvHmkg2KunzxRaf5rR27PVcT28j1QKfiWf/zfiJeM5SXYbRe39zReNstfTyGsxfcGQ1wO99HHDJZ+9qI2pjIuCW34Bx2IjSHcstId5Y1a 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 June 20, 2025 11:14:56 AM PDT, Sohil Mehta w= rote: >On 6/20/2025 6:53 AM, Kirill A=2E Shutemov wrote: >> =20 >> +/* >> + * The CLAC/STAC instructions toggle enforcement of X86_FEATURE_SMAP= =2E >> + * >> + * X86_FEATURE_LASS requires flipping the AC flag when accessing the l= ower half >> + * of the virtual address space, regardless of the _PAGE_BIT_USER bit = in the >> + * page tables=2E lass_clac/stac() should be used for these cases=2E >> + * > >Is this supposed to be "regardless" or only when the _PAGE_BIT_USER bit >it set? The way the sentence is worded it would seem that the kernel >could always use lass_clac()/stac() since the value in _PAGE_BIT_USER >doesn't matter=2E > >Please correct me if I am wrong, but here is my understanding: > >X86_FEATURE_SMAP and X86_FEATURE_LASS both complain when the kernel >tries to access the lower half of the virtual addresses=2E > >SMAP flags an issue if _PAGE_BIT_USER is not set=2E LASS would #GP in bot= h >cases with or without the _PAGE_BIT_USER being set=2E > >However, in terms of usage, we want to use LASS specific stac()/clac() >only when _PAGE_BIT_USER is set=2E Since this won't be flagged by SMAP=2E > >@Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle >functions=2E But, the difference in usage between both of them seems very >subtle=2E Could this be easily misused? > >For example, there is no failure that would happen if someone >incorrectly uses the SMAP specific clac()/stac() calls instead of the >LASS ones=2E > >> + * Note: a barrier is implicit in alternative()=2E >> + */ >> + >> static __always_inline void clac(void) >> { >> - /* Note: a barrier is implicit in alternative() */ >> alternative("", "clac", X86_FEATURE_SMAP); >> } >> =20 >> static __always_inline void stac(void) >> { >> - /* Note: a barrier is implicit in alternative() */ >> alternative("", "stac", X86_FEATURE_SMAP); >> } >> =20 >> +static __always_inline void lass_clac(void) >> +{ >> + alternative("", "clac", X86_FEATURE_LASS); >> +} >> + >> +static __always_inline void lass_stac(void) >> +{ >> + alternative("", "stac", X86_FEATURE_LASS); >> +} >> + "Regardless" is correct=2E LASS only considers which hemisphere the virtua= l address is located in, because it is explicitly designed to prevent walki= ng the page tables in the "wrong" hemisphere and therefore speculative acce= sses that happen to form pointers into user space addresses will not cause = TLB or cache fills that might be possible to probe=2E The obvious exception is when the kernel is intentionally performing acces= ses on behalf of user space, which is exactly what SMAP tells the hardware = already=2E