[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e82b48b9-5566-4bf2-9b9e-ee529d59e9b5@intel.com>
Date: Tue, 7 Oct 2025 13:49:12 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "tglx@...utronix.de"
<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
<bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "corbet@....net" <corbet@....net>, "ardb@...nel.org" <ardb@...nel.org>,
"david.laight.linux@...il.com" <david.laight.linux@...il.com>,
"luto@...nel.org" <luto@...nel.org>, "jpoimboe@...nel.org"
<jpoimboe@...nel.org>, "andrew.cooper3@...rix.com"
<andrew.cooper3@...rix.com>, "Luck, Tony" <tony.luck@...el.com>,
"alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
"kas@...nel.org" <kas@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
"rdunlap@...radead.org" <rdunlap@...radead.org>, "dwmw@...zon.co.uk"
<dwmw@...zon.co.uk>, "vegard.nossum@...cle.com" <vegard.nossum@...cle.com>,
"xin@...or.com" <xin@...or.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "kees@...nel.org" <kees@...nel.org>,
"hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org"
<peterz@...radead.org>, "linux-efi@...r.kernel.org"
<linux-efi@...r.kernel.org>, "geert@...ux-m68k.org" <geert@...ux-m68k.org>
Subject: Re: [PATCH v10 01/15] x86/cpu: Enumerate the LASS feature bits
On 10/7/2025 11:19 AM, Edgecombe, Rick P wrote:
>> LASS provides the same mode-based protections as paging but without
>> traversing the paging structures. Because the protections are enforced
>> pre-paging, an attacker will not be able to derive paging-based timing
>
> Nit: pre-page walk maybe? Otherwise it could sound like before paging is enabled
> during boot.
>
How about: ... protections are enforced prior to page walks, an ...
>>
>> +config X86_DISABLED_FEATURE_LASS
>> + def_bool y
>> + depends on X86_32
>> +
>
> All the other ones in the file are !X86_64. Why do this one X86_32?
>
The double negation (DISABLED and !X86_64) was harder to follow when
this was initially posted.
https://lore.kernel.org/lkml/73796800-819b-4433-b0ef-db852336d7a4@zytor.com/
https://lore.kernel.org/lkml/756e93a2-7e42-4323-ae21-a5437e71148e@infradead.org/
I don't have a strong preference. I guess the inconsistency makes it
confusing as well. Will change it back to !X86_64 unless Xin objects.
Powered by blists - more mailing lists