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 E09F1C7115B for ; Mon, 23 Jun 2025 23:37:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F6AB6B00CB; Mon, 23 Jun 2025 19:37:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A7EA6B00CC; Mon, 23 Jun 2025 19:37:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6482A6B00CD; Mon, 23 Jun 2025 19:37:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 51B1E6B00CB for ; Mon, 23 Jun 2025 19:37:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 21E24122C0D for ; Mon, 23 Jun 2025 23:37:35 +0000 (UTC) X-FDA: 83588279670.27.B0AC656 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf21.hostedemail.com (Postfix) with ESMTP id 087101C000E for ; Mon, 23 Jun 2025 23:37:32 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=jyILhge1; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf21.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750721853; a=rsa-sha256; cv=none; b=XxjbqwKT4auuaOs1YF+rjBaRkwB9c0czSczD480+0HLWOIZAPuVzjHpFPzudPPMuxYfkW8 qNt0I/oQASo238yGTzvaMFfdmGzN7I6GVHh1Tjy3T+4er59mrH8s7dg2HMG3h0Klcuo2sH SRteADag7dzttVX3SgOCfKUBhNa7FqE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=jyILhge1; dmarc=pass (policy=none) header.from=zytor.com; spf=pass (imf21.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750721853; 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=b0SnNTpTmp8KAx7qFKJDLHDogIjzK3DQTJWcnHQWcHw=; b=wP4y4H65s6oDnl2DR7w+h6C+cAyipVsfb2jarj/ql8qOSmbkYOKA4REV8xT/m4Z6yYh3od ubeqyckABpOl+5YgEB7cgxaWxDKKXoGZ2wWkrtKhLi1vF3NnDqY+CwvG45E9EqDW7QYXWr eOXgG35thSsMcCDWq9L0KfYX6Bk92+Q= 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 55NNaXe21125411 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 23 Jun 2025 16:36:34 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 55NNaXe21125411 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025062101; t=1750721797; bh=b0SnNTpTmp8KAx7qFKJDLHDogIjzK3DQTJWcnHQWcHw=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=jyILhge1PoHKMdmYcXFHg1mzoZJxnqCkIDylkzKB+ztz7NhHsWT3ZILfet5+kWdTr YCOO6t2eA63gasI5gjhWLxorZE/MVgh8GTB3qwoHoMGJ3CUcdt0FJBUvPXuJ9GYXGO FCfNB9UAChC8/1oDUYhxVCD2lkM/Gc6AaQ52PpyZd0xvIdN1wUqNInxnncT2Io4wNi GEJJTnm09CgtWNLpxlEghDmGkmK985effkl8N7Tqu1uk0vRokAwqLb4Z0YtptrLUqw 69LXd2R92o9+ilfzSYsXEHX17qO9FxCiLIWxLFNslsiMA4ni6zVIegpkMp/E6csVhi EL5RF1EpjMuZQ== Date: Mon, 23 Jun 2025 16:36:32 -0700 From: "H. Peter Anvin" To: "Luck, Tony" , "Hansen, Dave" , "Mehta, Sohil" , "Kirill A. Shutemov" , Dave Hansen CC: Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , "Huang, Kai" , Sandipan Das , Breno Leitao , "Edgecombe, Rick P" , 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 , "Li, Xin3" , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , 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: References: <20250620135325.3300848-1-kirill.shutemov@linux.intel.com> <20250620135325.3300848-2-kirill.shutemov@linux.intel.com> <248e272c-79ec-4c11-a3a8-dff1de2147c0@intel.com> <8f0913d7-9e77-41e0-91e2-17ca2454b296@intel.com> Message-ID: <299ED4FB-6949-4E7E-82D4-94E2E9F0A0B5@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: tgba5738psybrxnpq496bxnc9sann561 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 087101C000E X-HE-Tag: 1750721852-451375 X-HE-Meta: U2FsdGVkX1+Ps4TYM3S+DdwKY2LjSM0UUMJcMs8seekcvliivz/tBrzobbZBs4Dcdaijl6DH4oyepeeWKFghe8jUbjKOeuQZVvlAhi6l4bWD9ZbxxxyujpZUZIphcqWkRgk4LBNOPxyvF87wTRPVmh//bQVd/fKf/DFZIVCGU9RZxzsGDNhEz64MhdVW+RFsWPEjITVwCLCpWSOL1n1buFaXJZopZJC5pRuNXE3la99trwQAZsjvCsz49qoF8AQqMmUIJ44VrIf2yYcosukSuUywA7T2dyD0VBmN936qKgYh5BObrIdDclu3c5NhqHiuKxOdctsFe+uG2/WxtMTiJ6Qd0akpTBP8AND/timZQhffCvgo8gPmwwPu6Wi+V0PvL07FBr2LSM2c7Xl7w2+nfF7Xq88wtbWMg6N1EzlmpM1S9usech7lQPNlG/QS8l7mFEQRdH771Y29RYP6rGl3I6ABu+K6wAyyQzsNC/nJRWwnJWUyPjjSScAU2qzU17K03DmooRsVTsaxEgYYLAIVzjzMinqaBriWedsg8hXdbbu8gcBQCVFcswqe3JWUOcRT90uYc6cBKEF9p5TukfrQzVtJNvX3vroUl2zQb1mGu3KOQ3iAFLh5QEzEky8s1s71+wQuJmSfqjEwo4E8WkuSnuQFp+XUgVg0bqhd5ZE1YuuIQ7lXVrkjc/50r8gDOUbNIc9qHIWA4Wnwlt0LUC/6WVHbDg2t3h9SiwvydT/IBTX2UwmU3jDEQEwOONDiQdDkE/cduJP09DRWSvzwdjFQofZ4BUo0iody/oAVyLpvTLe5fZguv71YOLvP51rxLvRBPy0cL/4JjisEUDTlow+LYWPpRWIq+TCPw7JfrKQ2E6004WB1VlJnVrLMyzf3fGEWiP+RSwarzvfy7egh3fOWkIHWkWC15aODU4ZruwSRB/2YqSogDQAwmFFxq4qcCrGPVSSTEHfBMAjzbvAjF66 UMiJwiND M5zPF9br6YYCAM5Nb9TPR9jdEN250/yQjsHW/OoA0F0wKjGcnG4bLJiRZdiS2fEg/u5mKK6CB63baP83ckwvE40+EVdSE+vMznrGAOPjv0dvTqiTyqKkNjzrlrDK3wIaMSdJNv4adaer9DJ7SS1PKLcsJ8UULcJjvH8bMjKKnv9/HstgmBfiwIqtNY0PrEfR8sYQN1RpGFCqh5gnfpZkhUO5t00sgW6GuUprnh98iXWNTERiNmqn2hAq+kJbfactZXlMk6O7dJtEa2StQBgI5yOpOC96HYg28pprleMgURToSiM+njkLkgYFos+JbEIqn4doKPk+AX4xVC5P++CQSLFG+N7GBxz6nfexWG/wxjkpNUyQW0eUK5pjXQOU6g9I4e7KlqdVg7WFtMbQ13f0r42LVRJLM42nSzQ+hOfUW1TUrvVNNjOxXwZ9VEA== 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 23, 2025 4:13:34 PM PDT, "Luck, Tony" wro= te: >> >> Logically there are two completely different things: >> >> >> >> 1=2E Touching userspace >> >> 2=2E Touching the lower half of the address space >> >> >> >> If it's only userspace in the lower half of the address space, then >> >> there's no controversy=2E But the problem obviously occurs when you = want >> >> to touch kernel mappings in the lower half of the address space=2E >> > >> > Why does the kernel create the mappings to poke kernel text >> > for ALTERNATIVE patching in the lower half of the address space? >> > >> > Instead of special "we really to want to access the lower addresses" >> > code, wouldn't it be easier to map the "poke" virtual addresses in no= rmal >> > kernel upper-half space? >> >> The upper half of the address space is shared kernel space, right? Ever= y >> PGD has identical contents in the upper half=2E So if we create a mappi= ng >> there,everybody get access to it=2E Every mm can access it=2E Every >> *process* can access it=2E It still has kernel permissions of course, b= ut >> it's still a place that everybody can get at=2E >> >> The lower half is *ONLY* accessible to the local mm=2E In this case, on= ly >> the text poking mm=2E It's a natural, safe, place to create a mapping t= hat >> you want to be private and not be exploited=2E >> >> So, doing it in the upper half is risky=2E >> >> If we *wanted*, we could have a non-shared PGD entry in the top half of >> the address space=2E But we'd need to reserve its address space and all >> that jazz=2E I'm not sure it's any better than just disabling LASS >> enforcement for a moment=2E > >Maybe it=E2=80=99s a thing to put on the list for "when x86 drops support= for 32-bit"=2E > >Reserving a PGD entry in the kernel half of the address space for >local CPU use would be practical then=2E Perhaps there might be other >uses too=2E > >-Tony > Are we actually doing patching on more than one CPU at a time?