linux-kernel - Re: [PATCH] x86/entry/64: Add an LFENCE after SAVE_AND_SET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6236F23E-B26A-4141-AD2E-9403CFF726D3@intel.com>
Date:   Thu, 20 Aug 2020 18:04:50 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/entry/64: Add an LFENCE after SAVE_AND_SET_GSBASE


> On Aug 20, 2020, at 02:15, Borislav Petkov <bp@...en8.de> wrote:
> 
> From: Borislav Petkov <bp@...e.de>
> 
> 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/1557309753-24073-5-git-send-email-chang.seok.bae@intel.com/t/#m45f380a23231b87498b40b708f0401147f3b0278

> 	 */
> 	SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx
> +	FENCE_SWAPGS_KERNEL_ENTRY
> 	ret
> 
> .Lparanoid_entry_checkgs:
> -- 
> 2.21.0
>