lkml.org 
[lkml]   [2021]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V2 01/41] x86/entry: Fix swapgs fence
From
Date


On 2021/9/27 04:43, Thomas Gleixner wrote:
> Lai,
>
> On Sun, Sep 26 2021 at 23:07, Lai Jiangshan wrote:
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -898,17 +898,12 @@ SYM_CODE_START_LOCAL(paranoid_entry)
>> rdmsr
>> testl %edx, %edx
>> jns .Lparanoid_entry_swapgs
>> + FENCE_SWAPGS_KERNEL_ENTRY
>
> Good catch.
>
>> ret
>>
>> .Lparanoid_entry_swapgs:
>> swapgs
>> -
>> - /*
>> - * The above SAVE_AND_SWITCH_TO_KERNEL_CR3 macro doesn't do an
>> - * unconditional CR3 write, even in the PTI case. So do an lfence
>> - * to prevent GS speculation, regardless of whether PTI is enabled.
>> - */
>> - FENCE_SWAPGS_KERNEL_ENTRY
>> + FENCE_SWAPGS_USER_ENTRY
>
> This change is wrong.
>
> In the paranoid entry path even if user GS base is set then the entry
> does not necessarily come from user space so there is no guarantee that
> there was a CR3 write on PTI enabled systems before the SWAPGS.
>
> FENCE_SWAPGS_USER_ENTRY does not emit a LFENCE when PTI is enabled, so
> both the comment and FENCE_SWAPGS_KERNEL_ENTRY which emits LFENCE on
> affected CPUs unconditionaly are correct. Though the comment could do
> with some polishing to make this entirely clear.


I didn't notice FENCE_SWAPGS_USER_ENTRY depends on PTI.

I will add FENCE_SWAPGS_KERNEL_ENTRY only on the kernel path.

Thanks
Lai

\
 
 \ /
  Last update: 2021-09-27 03:11    [W:0.083 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site