Messages in this thread | | | Subject | Re: [PATCH V2 01/41] x86/entry: Fix swapgs fence | From | Lai Jiangshan <> | Date | Mon, 27 Sep 2021 09:10:49 +0800 |
| |
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
| |