[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb5f75e3-0882-4baa-be32-f363a8e411d8@citrix.com>
Date: Fri, 14 Feb 2025 14:01:40 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Xin Li <xin@...or.com>, linux-kernel@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
brgerst@...il.com, ebiederm@...ssion.com
Subject: Re: [PATCH v4 1/1] x86/ia32: Leave NULL selector values 0~3 as is
On 14/02/2025 6:56 am, Xin Li wrote:
> On 12/12/2024 10:44 AM, Xin Li wrote:
>> On 11/26/2024 10:45 AM, Xin Li (Intel) wrote:
>>> The first GDT descriptor is reserved as 'NULL descriptor'. As bits 0
>>> and 1 of a segment selector, i.e., the RPL bits, are NOT used to index
>>> GDT, selector values 0~3 all point to the NULL descriptor, thus values
>>> 0, 1, 2 and 3 are all valid NULL selector values.
>>>
>>> When a NULL selector value is to be loaded into a segment register,
>>> reload_segments() sets its RPL bits. Later IRET zeros ES, FS, GS, and
>>> DS segment registers if any of them is found to have any nonzero NULL
>>> selector value. The two operations offset each other to actually
>>> effect
>>> a nop.
>>>
>>> Besides, zeroing of RPL in NULL selector values is an information leak
>>> in pre-FRED systems as userspace can spot any interrupt/exception by
>>> loading a nonzero NULL selector, and waiting for it to become zero.
>>> But there is nothing software can do to prevent it before FRED.
>>>
>>> ERETU, the only legit instruction to return to userspace from kernel
>>> under FRED, by design does NOT zero any segment register to avoid this
>>> problem behavior.
>>>
>>> As such, leave NULL selector values 0~3 as is.
>>
>> Hi Andrew,
>>
>> Do you have any more comments?
>
> Hi Andrew,
>
> Are you okay to give a review-by to this patch?
Apologies.
Reviewed-by: Andrew Cooper <andrew.cooper3@...rix.com>
Powered by blists - more mailing lists