linux-kernel - RE: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB6083AE2EF85FB5D2FE39D4F0FC79A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 23 Jun 2025 16:25:23 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Mehta, Sohil"
	<sohil.mehta@...el.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Dave Hansen <dave.hansen@...ux.intel.com>
CC: Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...nel.org>, "Pawan
 Gupta" <pawan.kumar.gupta@...ux.intel.com>, Daniel Sneddon
	<daniel.sneddon@...ux.intel.com>, "Huang, Kai" <kai.huang@...el.com>,
	Sandipan Das <sandipan.das@....com>, Breno Leitao <leitao@...ian.org>,
	"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, Alexei Starovoitov
	<ast@...nel.org>, Hou Tao <houtao1@...wei.com>, Juergen Gross
	<jgross@...e.com>, Vegard Nossum <vegard.nossum@...cle.com>, Kees Cook
	<kees@...nel.org>, Eric Biggers <ebiggers@...gle.com>, Jason Gunthorpe
	<jgg@...pe.ca>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>, "Andrew
 Morton" <akpm@...ux-foundation.org>, Luis Chamberlain <mcgrof@...nel.org>,
	Yuntao Wang <ytcoode@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>,
	Christophe Leroy <christophe.leroy@...roup.eu>, Tejun Heo <tj@...nel.org>,
	Changbin Du <changbin.du@...wei.com>, Huang Shijie
	<shijie@...amperecomputing.com>, Geert Uytterhoeven
	<geert+renesas@...der.be>, Namhyung Kim <namhyung@...nel.org>, "Arnaldo
 Carvalho de Melo" <acme@...hat.com>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-efi@...r.kernel.org"
	<linux-efi@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Yian
 Chen" <yian.chen@...el.com>, Andy Lutomirski <luto@...nel.org>, "Thomas
 Gleixner" <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "Borislav
 Petkov" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin"
	<hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Ard Biesheuvel
	<ardb@...nel.org>, "Paul E. McKenney" <paulmck@...nel.org>, Josh Poimboeuf
	<jpoimboe@...nel.org>, Xiongwei Song <xiongwei.song@...driver.com>, "Li,
 Xin3" <xin3.li@...el.com>, "Mike Rapoport (IBM)" <rppt@...nel.org>, "Brijesh
 Singh" <brijesh.singh@....com>, Michael Roth <michael.roth@....com>, "Alexey
 Kardashevskiy" <aik@....com>, Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>
Subject: RE: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits

> > functions. But, the difference in usage between both of them seems very
> > subtle. Could this be easily misused?
>
> Logically there are two completely different things:
>
>       1. Touching userspace
>       2. 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. But the problem obviously occurs when you want
> to touch kernel mappings in the lower half of the address space.

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 normal
kernel upper-half space?

-Tony