Re: [PATCH V2 01/41] x86/entry: Fix swapgs fence

[Lai Jiangshan]

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