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 01AA1C7115B for ; Fri, 20 Jun 2025 16:03:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7035A6B008A; Fri, 20 Jun 2025 12:03:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DBA36B008C; Fri, 20 Jun 2025 12:03:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6186E6B0092; Fri, 20 Jun 2025 12:03:48 -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 4D1E26B008A for ; Fri, 20 Jun 2025 12:03:48 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D9F1FC0DDE for ; Fri, 20 Jun 2025 16:03:47 +0000 (UTC) X-FDA: 83576249694.15.29CF300 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id DB8CE12000B for ; Fri, 20 Jun 2025 16:03:45 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oul+Os6R; spf=none (imf29.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750435426; 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=NSB4A1BN+oe8vo2+YMkOtMxoCw9tNHrThUhqnK3l+LM=; b=LhyVgsNGqEcLldU5tY10i6YBswQaf1h+Xzhzy+KRMbanVhzHOhj7ayx2th2Lzqw+cN1ifP lFrgxtjo258jlewAubxNNoRfog/QkXW4bnWzkeEekZ+/9/0iwI2D/N8HtaUC0NImTxFuXq gskAKwbeaPFY7Nnlp+NGMRZx6PnT7gE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750435426; a=rsa-sha256; cv=none; b=Osk441fiOYewuOzYOwv209zYjtg9G19ndtM3UNRVyhL+72574M/bo+d2iZ/H6hvMxGa4B8 pvQ7drryy4fqP62+LEcpQdgsKlStmnyFvysw5tLGn98WQ5y4vnGt7GVVvc/ndowm99ee7L stX+gZsY2eaNpNWBkinXlSklOtM3ioA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oul+Os6R; spf=none (imf29.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=rdunlap@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description; bh=NSB4A1BN+oe8vo2+YMkOtMxoCw9tNHrThUhqnK3l+LM=; b=oul+Os6RDpifkRz0yqsu6U/NTb +MnDf6Z3FjzrS9577VAuSwTL3/JJ6AacGXPkkHJAABXhvoPk9uWSw/UgVn42a1y6Ic4LOIlnB02IE aNXG9dfdiyQCZDlCy/KQjBaf1tjG9kpiYhJzaepD9HxeItlz3bvMp61cXcc/DdwRXE1R28kFSZEFu yd8LjCeBCwVQp68r5cuJoQE3CQloAX6vQuhgWZlzwijzXmzasWiEwBiRhalxYaKZSOEp3iCNDXfbt vipLI+60L7CYwMkMU06GTIhV/+S4a6q8QAdbRmZR/W9pMU5RSRDSWi8vmy+uRvnzv5xq8OSnTlxo1 OqSBoqPQ==; Received: from [50.53.25.54] (helo=[192.168.254.17]) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uSeCd-0000000D1ab-2WJI; Fri, 20 Jun 2025 16:02:55 +0000 Message-ID: <25600557-9cd5-406c-9acf-abc163afde2d@infradead.org> Date: Fri, 20 Jun 2025 09:02:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits To: "Kirill A. Shutemov" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , 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 Cc: Jonathan Corbet , Sohil Mehta , 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 References: <20250620135325.3300848-1-kirill.shutemov@linux.intel.com> <20250620135325.3300848-2-kirill.shutemov@linux.intel.com> Content-Language: en-US From: Randy Dunlap In-Reply-To: <20250620135325.3300848-2-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Stat-Signature: cpenkfs71hgcu5kf4p4kig6p61n48btn X-Rspam-User: X-Rspamd-Queue-Id: DB8CE12000B X-HE-Tag: 1750435425-19438 X-HE-Meta: U2FsdGVkX18CDbROjUcoAiUwin4S/nhtqzoxP3ukfraN15gJCBP0wWsFzsblea5lRn5nfJ0uAV94lBQdRl8gVt2P6qidoofotkvN80XgJCNvUkkzT++a5cj+wDyRs2vz7kEfk4aWmMm1WKjMRDT1hS7GV3bD48WS3iWbWfE0FS92AuMNrkg+4fdW1YDIjHDNGWHYhUObWm86MzJBoXelINcilRpoPAy3fyoogUO0EungylvtczO3pPDu08+sxLgOewrMNBAGuaZ5XyXheAnvPFIa068Fzrm+W6fAHfEaEnJqp5XldbQTKHo1iHQgqAepomrTuLuO4tuj1Qp+E7iXUXXAnKvOTw+8kHb9lhfMNhIEMeXr7p00L82HT9mDLdO+lhq2I4Qh4j4jbl7Q+F9zYYQpcWadmPeIn0A7HGw6dMRZgH8y11MLzUGJanT5sOjFr9agOYBw4mhAr5SAzOomtl17AywLsJMyqYWTjLpq+c7aqbOizuEV1ii/ODSFn2VlyBjOxhQhdDrbE/Jgz6mv19k9ApFepbHIqs/5x8qzVjlnLVFLV4MSLi5kG+ISyEjJed0jqiCzgvTTjTvd7DidbaASXob9z0GL6OpRFq9wzowCoZKYXZrmge5PGUCvryZ5VmqHKRDbg5RR0qg4cRAF/P4tW1dxBuf09L933EweVJ0osbh6VvjM+IblX+8eAztIm7DhjIrZfHDr2exqHRk2gFiq4b+okHRF+WCd5XaC6Iw2oSAxOUWUpazygFKjuMIEcmDxrfdEHcc3TBxv08hSeDN28uWeH0z7sCltbr2qX0KZfCynAORTDadVaQUrp7P0+WZ6wNThS+ZXpUQK3tWaOx1CEips+sm5m8LWuyMmSqCZxMiejp+6/u9d9/t2RucWZG5rebCl0HhrqLy9ukZuMXBoWwg10yH7lcCaGSMDdkZ0nwk1cFk+YM4D4RWe3zG6vBCoNhq1Z/YfbjGyYeA kcWkyeBj G1XV+e+J3vNu5bw4gk9Zxikt3iBaK4C/hwEeuWnanGC6W4DcW9DKS1JAim+Ny4LVAfKArBX1dVSIOuFgPDtEibzX9Avgl2D+hot5CuqD0wDomut3T3CYNPBMKTA2cWEpwzLyhPZJ5l2zh9srIB2Khte0x13Jo3JmAvgKiZwH8z486lhxjxaAdHxduGL5hJIi8p7iJl97L7tmLKtt9pf5tqCFIMFTubeyG9jsvLDT74z+h1kbJubsqCIUT90Xpn18tDAIhF2smlRJcC/fXNWLC4YydJpIj7dqqsWxEdCOsR7O3Xya4ZAkXPyh1dPlHMimty3as98QNWz35KtQC3rlV2ALJZpGbznZV58MSSAT8OKRBG025ppy4hPJ7xqKoX9DYdTx9z0GThiWy6fTSRai9Q9y4jA== 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: Hi-- On 6/20/25 6:53 AM, Kirill A. Shutemov wrote: > From: Sohil Mehta > > Linear Address Space Separation (LASS) is a security feature that > intends to prevent malicious virtual address space accesses across > user/kernel mode. > > Such mode based access protection already exists today with paging and > features such as SMEP and SMAP. However, to enforce these protections, > the processor must traverse the paging structures in memory. Malicious > software can use timing information resulting from this traversal to > determine details about the paging structures, and these details may > also be used to determine the layout of the kernel memory. > > The LASS mechanism provides the same mode-based protections as paging > but without traversing the paging structures. Because the protections > enforced by LASS are applied before paging, software will not be able to > derive paging-based timing information from the various caching > structures such as the TLBs, mid-level caches, page walker, data caches, > etc. > > LASS enforcement relies on the typical kernel implementation to divide > the 64-bit virtual address space into two halves: > Addr[63]=0 -> User address space > Addr[63]=1 -> Kernel address space > > Any data access or code execution across address spaces typically > results in a #GP fault. > > The LASS enforcement for kernel data access is dependent on CR4.SMAP > being set. The enforcement can be disabled by toggling the RFLAGS.AC bit > similar to SMAP. > > Define the CPU feature bits to enumerate this feature and include > feature dependencies to reflect the same. > > Co-developed-by: Yian Chen > Signed-off-by: Yian Chen > Signed-off-by: Sohil Mehta > Signed-off-by: Alexander Shishkin > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/Kconfig.cpufeatures | 4 ++++ > arch/x86/include/asm/cpufeatures.h | 1 + > arch/x86/include/asm/smap.h | 22 +++++++++++++++++++-- > arch/x86/include/uapi/asm/processor-flags.h | 2 ++ > arch/x86/kernel/cpu/cpuid-deps.c | 1 + > tools/arch/x86/include/asm/cpufeatures.h | 1 + > 6 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures > index 250c10627ab3..9574c198fc08 100644 > --- a/arch/x86/Kconfig.cpufeatures > +++ b/arch/x86/Kconfig.cpufeatures > @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID > def_bool y > depends on !X86_64 > > +config X86_DISABLED_FEATURE_LASS > + def_bool y > + depends on !X86_64 Please explain why this is !X86_64. Thanks. > + > config X86_DISABLED_FEATURE_PKU > def_bool y > depends on !X86_INTEL_MEMORY_PROTECTION_KEYS -- ~Randy