> On Aug 20, 2020, at 02:15, Borislav Petkov <[email protected]> wrote:
>
> From: Borislav Petkov <[email protected]>
>
> The FSGSBASE macro to swap current GSBASE with the kernel GSBASE
> probably had a speculation-stopping MSR write at some point but not
> anymore.
No, the macro has not any MSR write ever before.
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 26fc9b42fadc..3931d47cdd83 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -839,11 +839,9 @@ SYM_CODE_START_LOCAL(paranoid_entry)
> * Read the current GSBASE and store it in %rbx unconditionally,
> * retrieve and set the current CPUs kernel GSBASE. The stored value
> * has to be restored in paranoid_exit unconditionally.
> - *
> - * The MSR write ensures that no subsequent load is based on a
> - * mispredicted GSBASE. No extra FENCE required.
Thomas looks to add this text when he picked v7 [1].
FWIW, we added our text from v8, after reviewed the speculation impact
on this series:
This unconditional write of GS base ensures no subsequent load
based on a mispredicted GS base.
I think somehow the “MSR write” made confusion. Our conclusion was the
same as Thomas' that no FENCE is needed here.
Thanks,
Chang
[1]
https://lore.kernel.org/lkml/[email protected]/t/#m45f380a23231b87498b40b708f0401147f3b0278
> */
> SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx
> + FENCE_SWAPGS_KERNEL_ENTRY
> ret
>
> .Lparanoid_entry_checkgs:
> --
> 2.21.0
>
