On Thu, Aug 20, 2020 at 06:04:50PM +0000, Bae, Chang Seok wrote: > I think somehow the “MSR write” made confusion. Our conclusion was the > same as Thomas' that no FENCE is needed here.
Ok, here's v2 with a corrected comment: --- From: Borislav Petkov <[email protected]> Add the proper explanation why an LFENCE is not needed in the FSGSBASE case. Fixes: c82965f9e530 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit") Signed-off-by: Borislav Petkov <[email protected]> --- arch/x86/entry/entry_64.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 26fc9b42fadc..5c5d234d968d 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -840,8 +840,9 @@ SYM_CODE_START_LOCAL(paranoid_entry) * 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. + * The unconditional write to GS base below ensures that no subsequent + * loads based on a mispredicted GS base can happen, therefore no LFENCE + * is needed here. */ SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx ret -- 2.21.0 Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
