[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y1z6vmfi.ffs@tglx>
Date: Thu, 12 May 2022 16:46:09 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"H . J . Lu" <hjl.tools@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 09/10] x86/mm: Add userspace API to enable Linear
Address Masking
On Wed, May 11 2022 at 09:26, Peter Zijlstra wrote:
> On Wed, May 11, 2022 at 05:27:50AM +0300, Kirill A. Shutemov wrote:
>> @@ -1013,8 +1017,23 @@ static long thread_feature_prctl(struct task_struct *task, int option,
>>
>> /* Handle ARCH_THREAD_FEATURE_ENABLE */
>>
>> + if (features & (X86_THREAD_LAM_U48 | X86_THREAD_LAM_U57)) {
>> + long ret;
>> +
>> + /* LAM is only available in long mode */
>> + if (in_32bit_syscall())
>> + return -EINVAL;
>
> So what happens if userspace sets up a 32bit code entry in the LDT and
> does the LAM thing as a 64bit syscamm but then goes run 32bit code?
AFAICS, nothing happens. The only requirements are CR4.PAE = 1,
IA32_EFER.LME = 1. Those are unaffected from user space running 32bit
code, no?
32bit code can't use 64bit pointers so it can't have metadata bits
set. But x32 can and is excluded by the above too.
So the whole muck must be conditional on CONFIG_X86_64=y and does not
need any other restrictions IMO.
Thanks,
tglx
Powered by blists - more mailing lists