MDSv2 8

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add basic bug infrastructure for
MDS

MDS is micro architectural data sampling, which is a side channel attack on internal buffers in Intel CPUs. They all have the same mitigations for single thread, so we lump them all together as a single MDS issue.

This patch adds the basic infrastructure to detect if the current CPU is affected by MDS, and if yes set the right BUG bits.

We also provide a command line option "mds_disable" to disable any workarounds.

Signed-off-by Andi Kleen <[email protected]>

---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 arch/x86/include/asm/cpufeatures.h              |  2 ++
 arch/x86/include/asm/msr-index.h                |  1 +
 arch/x86/kernel/cpu/bugs.c                      | 10 ++++++++++
 arch/x86/kernel/cpu/common.c                    | 14 ++++++++++++++
 5 files changed, 30 insertions(+)

Documentation/admin-guide/kernel-parameters.txt +0 -0

index aefd358a5ca3..48891572e825 100644

Documentation/admin-guide/kernel-parameters.txt +2 -0

+			Disable workarounds for Micro-architectural Data Sampling.
+
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.

arch/x86/include/asm/cpufeatures.h +2 -0

index 28c4a502b419..93fab3a1e046 100644
@@ -342,6 +342,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */
 #define X86_FEATURE_AVX512_4VNNIW	(18*32+ 2) /* AVX-512 Neural Network Instructions */
 #define X86_FEATURE_AVX512_4FMAPS	(18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
+#define X86_FEATURE_MB_CLEAR		(18*32+10) /* Flush state on VERW */
 #define X86_FEATURE_PCONFIG		(18*32+18) /* Intel PCONFIG */
 #define X86_FEATURE_SPEC_CTRL		(18*32+26) /* "" Speculation Control (IBRS + IBPB) */
 #define X86_FEATURE_INTEL_STIBP		(18*32+27) /* "" Single Thread Indirect Branch Predictors */

@@ -379,5 +380,6 @@
 #define X86_BUG_SPECTRE_V2		X86_BUG(16) /* CPU is affected by Spectre variant 2 attack with indirect branches */
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
+#define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
 
 #endif /* _ASM_X86_CPUFEATURES_H */

arch/x86/include/asm/msr-index.h +0 -0

index c8f73efb4ece..303064a9a0a9 100644

arch/x86/include/asm/msr-index.h +0 -0

 #define MSR_IA32_FLUSH_CMD		0x0000010b
 #define L1D_FLUSH			(1 << 0)   /*

arch/x86/kernel/cpu/bugs.c +10 -0

index 500278f5308e..5cac243849d8 100644
@@ -35,6 +35,7 @@
 static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);
 static void __init l1tf_select_mitigation(void);
+static void __init mds_select_mitigation(void);
 
 /* The base value of the SPEC_CTRL MSR that always has to be preserved. */
 u64 x86_spec_ctrl_base;

@@ -99,6 +100,8 @@ void __init check_bugs(void)
 
 	l1tf_select_mitigation();
 
+	mds_select_mitigation();
+
 #ifdef CONFIG_X86_32
 	/*
 	 * Check whether we are able to run this kernel safely on SMP.

@@ -1041,6 +1044,13 @@ early_param("l1tf", l1tf_cmdline);
 
 #undef pr_fmt
 
+static void mds_select_mitigation(void)
+{
+	if (cmdline_find_option_bool(boot_command_line, "mds_disable") ||
+	    !boot_cpu_has_bug(X86_BUG_MDS))
+		setup_clear_cpu_cap(X86_FEATURE_MB_CLEAR);
+}
+
 #ifdef CONFIG_SYSFS
 
 #define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"

arch/x86/kernel/cpu/common.c +14 -0

index ffb181f959d2..bebeb67015fc 100644
@@ -998,6 +998,14 @@ static const __initconst struct x86_cpu_id cpu_no_l1tf[] = {
 	{}
 };
 
+static const __initconst struct x86_cpu_id cpu_no_mds[] = {
+	/* in addition to cpu_no_speculation */
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT	},
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_X	},
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_PLUS	},
+	{}
+};
+
 static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
 	u64 ia32_cap = 0;

@@ -1019,6 +1027,12 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+	    !x86_match_cpu(cpu_no_mds)) &&
+	    !(ia32_cap & ARCH_CAP_MDS_NO) &&
+	    !(ia32_cap & ARCH_CAP_RDCL_NO))
+		setup_force_cpu_bug(X86_BUG_MDS);
+
 	if (x86_match_cpu(cpu_no_meltdown))
 		return;
 

Signature · 1 line

2.17.2

Quoted 12 lines · speck for Andi Kleen

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add basic bug infrastructure for
MDS

MDS is micro architectural data sampling, which is a side channel attack on internal buffers in Intel CPUs. They all have the same mitigations for single thread, so we lump them all together as a single MDS issue.

This patch adds the basic infrastructure to detect if the current CPU is affected by MDS, and if yes set the right BUG bits.

Quoted 2 lines

We also provide a command line option "mds_disable" to disable any workarounds.

Would it be worth referencing a not-yet-posted Intel doc, or at least point to the kernel.org bugzilla where we dump all the CPU related issues?

arch/x86/include/asm/msr-index.h line 80

Quoted 4 lines

arch/x86/include/asm/msr-index.h +1 -0

 						    * attack, so no Speculative Store Bypass
 						    * control required.
 						    */
+#define ARCH_CAP_MDS_NO			(1 << 5)   /* No Microarchitectural data sampling */

Should this say anything about RDCL?

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add basic bug infrastructure for
MDS

MDS is micro architectural data sampling, which is a side channel attack on internal buffers in Intel CPUs. They all have the same mitigations for single thread, so we lump them all together as a single MDS issue.

This patch adds the basic infrastructure to detect if the current CPU is affected by MDS, and if yes set the right BUG bits.

We also provide a command line option "mds_disable" to disable any workarounds.

Signed-off-by Andi Kleen <[email protected]>

---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 arch/x86/include/asm/cpufeatures.h              |  2 ++
 arch/x86/include/asm/msr-index.h                |  1 +
 arch/x86/kernel/cpu/bugs.c                      | 10 ++++++++++
 arch/x86/kernel/cpu/common.c                    | 14 ++++++++++++++
 5 files changed, 30 insertions(+)

Documentation/admin-guide/kernel-parameters.txt +3 -0

index aefd358a5ca3..48891572e825 100644
@@ -2341,6 +2341,9 @@
 			Format: <first>,<last>
 			Specifies range of consoles to be captured by the MDA.
 
+	mds_disable	[X86]
+			Disable workarounds for Micro-architectural Data Sampling.
+
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.

arch/x86/include/asm/cpufeatures.h +2 -0

index 28c4a502b419..93fab3a1e046 100644
@@ -342,6 +342,7 @@
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */
 #define X86_FEATURE_AVX512_4VNNIW	(18*32+ 2) /* AVX-512 Neural Network Instructions */
 #define X86_FEATURE_AVX512_4FMAPS	(18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
+#define X86_FEATURE_MB_CLEAR		(18*32+10) /* Flush state on VERW */
 #define X86_FEATURE_PCONFIG		(18*32+18) /* Intel PCONFIG */
 #define X86_FEATURE_SPEC_CTRL		(18*32+26) /* "" Speculation Control (IBRS + IBPB) */
 #define X86_FEATURE_INTEL_STIBP		(18*32+27) /* "" Single Thread Indirect Branch Predictors */

@@ -379,5 +380,6 @@
 #define X86_BUG_SPECTRE_V2		X86_BUG(16) /* CPU is affected by Spectre variant 2 attack with indirect branches */
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
+#define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
 
 #endif /* _ASM_X86_CPUFEATURES_H */

arch/x86/include/asm/msr-index.h +1 -0

index c8f73efb4ece..303064a9a0a9 100644
@@ -77,6 +77,7 @@
 						    * attack, so no Speculative Store Bypass
 						    * control required.
 						    */
+#define ARCH_CAP_MDS_NO			(1 << 5)   /* No Microarchitectural data sampling */
 
 #define MSR_IA32_FLUSH_CMD		0x0000010b
 #define L1D_FLUSH			(1 << 0)   /*

arch/x86/kernel/cpu/bugs.c +10 -0

index 500278f5308e..5cac243849d8 100644
@@ -35,6 +35,7 @@
 static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);
 static void __init l1tf_select_mitigation(void);
+static void __init mds_select_mitigation(void);
 
 /* The base value of the SPEC_CTRL MSR that always has to be preserved. */
 u64 x86_spec_ctrl_base;

@@ -99,6 +100,8 @@ void __init check_bugs(void)
 
 	l1tf_select_mitigation();
 
+	mds_select_mitigation();
+
 #ifdef CONFIG_X86_32
 	/*
 	 * Check whether we are able to run this kernel safely on SMP.

@@ -1041,6 +1044,13 @@ early_param("l1tf", l1tf_cmdline);
 
 #undef pr_fmt
 
+static void mds_select_mitigation(void)
+{
+	if (cmdline_find_option_bool(boot_command_line, "mds_disable") ||
+	    !boot_cpu_has_bug(X86_BUG_MDS))
+		setup_clear_cpu_cap(X86_FEATURE_MB_CLEAR);
+}
+
 #ifdef CONFIG_SYSFS
 
 #define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"

arch/x86/kernel/cpu/common.c +14 -0

index ffb181f959d2..bebeb67015fc 100644
@@ -998,6 +998,14 @@ static const __initconst struct x86_cpu_id cpu_no_l1tf[] = {
 	{}
 };
 
+static const __initconst struct x86_cpu_id cpu_no_mds[] = {
+	/* in addition to cpu_no_speculation */
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT	},
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_X	},
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_ATOM_GOLDMONT_PLUS	},
+	{}
+};
+
 static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
 	u64 ia32_cap = 0;

@@ -1019,6 +1027,12 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+	    !x86_match_cpu(cpu_no_mds)) &&
+	    !(ia32_cap & ARCH_CAP_MDS_NO) &&
+	    !(ia32_cap & ARCH_CAP_RDCL_NO))
+		setup_force_cpu_bug(X86_BUG_MDS);
+
 	if (x86_match_cpu(cpu_no_meltdown))
 		return;
 

Signature · 1 line

2.17.2

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Clear CPU buffers on kernel exit
for 64bit

Quoted 3 lines · speck for Andi Kleen

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Clear CPU buffers on kernel exit
for 64bit

[ ... snip ... ]

arch/x86/include/asm/nospec-branch.h line 158

Quoted 6 lines

+.macro EXIT_MDS

arch/x86/include/asm/nospec-branch.h +5 -0

+	/* Clear CPU buffers that could leak. Instruction must be in memory form. */
+	ALTERNATIVE_2 "", __stringify(push $__USER_DS ; verw (% _ASM_SP ) ; add $8, % _ASM_SP ),\
+		X86_FEATURE_MB_CLEAR, \
+		"call do_clear_cpu", \
+		X86_BUG_MDS_CLEAR_CPU

The software clearing sequence is introduced later in the series, so this seems not to be bisectable.

Quoted 3 lines · speck for Andi Kleen

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Clear CPU buffers on kernel exit for 64bit

[ ... snip ... ]

arch/x86/include/asm/nospec-branch.h line 158

Quoted 6 lines

+.macro EXIT_MDS

arch/x86/include/asm/nospec-branch.h +5 -0

+	/* Clear CPU buffers that could leak. Instruction must be in memory form. */
+	ALTERNATIVE_2 "", __stringify(push $__USER_DS ; verw (% _ASM_SP ) ; add $8, % _ASM_SP ),\
+		X86_FEATURE_MB_CLEAR, \
+		"call do_clear_cpu", \
+		X86_BUG_MDS_CLEAR_CPU

The software clearing sequence is introduced later in the series, so this seems not to be bisectable.

Thanks,

--
Jiri Kosina
SUSE Labs

- altinstructions are probably not what we want at all for any of these mitigations.

If you have a patched kernel but old microcode and then do a late load of the microcode, you have already thrown away the alternatives by that point and you'll show as being mitigated but in fact have nops all over the place. A static branch would solve this.

- altinstructions are probably not what we want at all for any of these mitigations.

If you have a patched kernel but old microcode and then do a late load of the microcode, you have already thrown away the alternatives by that point and you'll show as being mitigated but in fact have nops all over the place.

If you have a patched kernel but old microcode and then do a late load of the microcode,

Quoted 2 lines · speck for Kanth Ghatraju

If you have a patched kernel but old microcode and then do a late load of the microcode,

And to extend what the others said: late microcode loading is a can of worms which we shouldnt've opened back then. Especially since it requires a complicated dance on the OS part to quiesce the cores to even work without locking up the core or whatever crazy can happen.

So microcode update should be handled just like updating your kernel - you need to reboot the machine.

Signature · 5 lines

Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

Quoted 8 lines · speck for Borislav Petkov

Quoted 2 lines · speck for Kanth Ghatraju

If you have a patched kernel but old microcode and then do a late load of the microcode,

And to extend what the others said: late microcode loading is a can of worms which we shouldnt've opened back then. Especially since it requires a complicated dance on the OS part to quiesce the cores to even work without locking up the core or whatever crazy can happen.

We (Oracle, UEK kernel) has this can of worms happily (well, we did have to get rid of some bugs) working.

We can start that conversation upstream, but Thomas and Boris -are you guys very much against this idea with the upstream kernel or would you be up for taking a sip from this can?

We can start that conversation upstream, but Thomas and Boris -are you guys very much against this idea with the upstream kernel or would you be up for taking a sip from this can?

Quoted 3 lines · speck for Konrad Rzeszutek Wilk

We can start that conversation upstream, but Thomas and Boris -are you guys very much against this idea with the upstream kernel or would you be up for taking a sip from this can?

Well, I'm willing to hear your arguments for why you absolutely must load microcode during runtime, without rebooting and cannot bundle a microcode upgrade with a kernel upgrade and do a normal reboot during scheduled system downtime.

That is easy - "cloud" - you know $X billion market where everybody decides that 99.99999% is needed which means you can only reboot for 1 second.

Quoted 2 lines · speck for Konrad Rzeszutek Wilk

That is easy - "cloud" - you know $X billion market where everybody decides that 99.99999% is needed which means you can only reboot for 1 second.

And clowd doesn't reboot machines to update kernels?

And clowd gets guarantees from CPU vendor that live microcode upgrade works fine every time even while the core executes instructions and with any microcode revision being upgraded to?

No - not if they can possibly avoid it.

Within the constraints of "quiesce the system with stop_machine()", yes.

I've got some customers to have said in no uncertain terms that they want to reboot to get mitigations for these forthcoming issues.  Said customers are large enough that Intel is currently engaged, and have tentatively said that it is fine to load ucode in parallel on every core during stop machine, rather than serially.

I'm expecting Intel to propose this change in Linux as well as Xen.

I personally think everyone should reboot and call it done,

but at the end of the day, I'm beholden to my customers, and they really really do want late load microcode to work.

So you have a non-inline function that

- has a test to return early

- does a *single* instruction

- the instruction gets nop'ed out if it's not valid

all of which just *screams* "that's wrong" to me. Why isn't it inline and a static branch?

The actual asm sequence also seems bad to me.

Why isn't that just using

        int val = __KERNEL_DS;

with the asm just doing

        "verw %[kernelds]" ..  [kernelds] "m" (val)

instead, letting gcc do the stack setup part.

Maybe none of this matters simply because it's in the idle case, but the exact same issues happen for the kernel exit case.

And no, we're not doing that insane kernel exit software case by default. Not without a whole lot of examples of horrid badness.

The data that system calls touch is basically already user data. Sure, there may be kernel pointers etc there, but we've already accepted those leaking locally for all the usual reasons that we have no control over.

So the whole "let's add crazy long sequences to every kernel exit" is not going to happen. Not without a lot more explanations.

I don't think it's worth it because going into idle isn't really that performance sensitive. Also if the side effect is there its overhead really swamps any call overhead.

need a static branch, unless you want to toggle it at runtime?

        "verw %[kernelds]" ..  [kernelds] "m" (val)

Quoted 2 lines

instead, letting gcc do the stack setup part.

It has to be the memory form, only that has the necessary side effect in the microcode.

overhead
doesn't seem to be that bad.

I think the encryption key case could easily have a "let's scrub cpu state" thing.

Quoted 2 lines · Linus Torvalds

I think the encryption key case could easily have a "let's scrub cpu state" thing.

In fact, maybe we could have something like a TIF_SCRUBME thread flag, which we react to on return to user space, and on context switch.

That way anybody who thinks they are really working with sensitive information could just set the flag. We could set it automatically in kzfree() and memzero_explicit().

Using a TIF_xyz flag would seem to be very natural. Sure, there's a window between the "handle TIF_xyz" flags and the actual return to user space, but nothing in that window should touch anything remotely sensitive. It's mainly just restoring user state.

Linus

Re-sending, because apparently the previous email was so well encrypted that Andi couldn't even read it.

Oh well. I was so happy to get my s/mime setup fixed up and finally talking to the speck list automatically and properly, but I was apparently celebrating too early, so this downgrades to the earlier (somewhat broken) setup.

I suspect Thomas could write a book about his frustrations by now.

Linus

Quoted 16 lines · Linus Torvalds

Quoted 2 lines · Linus Torvalds

I think the encryption key case could easily have a "let's scrub cpu state" thing.

In fact, maybe we could have something like a TIF_SCRUBME thread flag, which we react to on return to user space, and on context switch.

That way anybody who thinks they are really working with sensitive information could just set the flag. We could set it automatically in kzfree() and memzero_explicit().

Using a TIF_xyz flag would seem to be very natural. Sure, there's a window between the "handle TIF_xyz" flags and the actual return to user space, but nothing in that window should touch anything remotely sensitive. It's mainly just restoring user state.

Quoted 3 lines

In fact, maybe we could have something like a TIF_SCRUBME thread flag, which we react to on return to user space, and on context switch.

We'll have to disable interrupts in that window, but that should be ok.

[ Let's see if this comes through legibly ]

Quoted 6 lines · speck for Andi Kleen

Quoted 3 lines

In fact, maybe we could have something like a TIF_SCRUBME thread flag, which we react to on return to user space, and on context switch.

We'll have to disable interrupts in that window, but that should be ok.

I don't think we even need to disable interrupts.

If an interrupt comes in while we're scrubbing, either that interrupt will touch sensitive data (and set TIF_SCRUBME) or it won't.

If it *does* set TIF_SCRUBME, we'll just re-do the scrub, and if it *doesn't* touch sensitive data, we'll return to the scrubbing having touched even more cachelines so any old sensitive data should be fine.

Yeah, yeah, it might affect some cache replacement logic that the SW scrubbing code might depend on in theory, but that's pretty damn theoretical. Good luck to anybody trying to attack that.

Linus

Ok, re-sending again.

It looks like speck doesn't have my other cert, so when I send with the cert I want to use it ends up never being decrypted (and then re-encrypted with the speck cert) by the mailing list.

Quoted 3 lines

If it *does* set TIF_SCRUBME, we'll just re-do the scrub, and if it *doesn't* touch sensitive data, we'll return to the scrubbing having touched even more cachelines so any old sensitive data should be fine.

Ok, re-sending again.

It looks like speck doesn't have my other cert, so when I send with the cert I want to use it ends up never being decrypted (and then re-encrypted with the speck cert) by the mailing list.

Okay.

We'll have to disable interrupts in that window, but that should be ok.

I guess it could be also set in some skb_* functions to catch the network cases.

Or maybe setting when calling into unaudited code in interrupts/timers?

And the flag would allow a "paranoid" mode which sets it unconditionally.

Quoted 10 lines · speck for Andi Kleen

Okay.

We'll have to disable interrupts in that window, but that should be ok.

I guess it could be also set in some skb_* functions to catch the network cases.

Or maybe setting when calling into unaudited code in interrupts/timers?

Quoted 2 lines

And the flag would allow a "paranoid" mode which sets it unconditionally.

That sounds a lot like kvm_get_cpu_l1tf_flush_l1d and kvm_clear_cpu_l1tf_flush_l1d. Maybe we can just add another bit in irq_cpustat_t's kvm_cpu_l1tf_flush_l1d, which would be cleared on return to userspace before doing the verw stuff.

However there is one problem: if the guest is using the software sequence and the sequence gets interrupted by an exit,

So I'm at the Intel partner meeting right now, and the official statement seems to be that the software sequence really shouldn't be used. Nobody seems to want that to be used for anything but something really odd case.

This is actually fairly ok, because if the verw *really* doesn't do anything, it also isn't very expensive (ie on the order of just 40 cycles instead of 400 cycles). So I'd actually be inclined to say "let's do that for the *initial* patches and back-ports" just to give any vmware users the protection.

Longer term (ie after a few months), the proper sequence ends up taking X86_FEATURE_MB_CLEAR into account, so this is basically just an artificial "it takes a while for that feature to show up in a vmware cluster even after the fixes have been applied" issue.

Note that vmware *really* really doesn't want that software sequence in any case. Not only does it not work reliably in virtualization anyway, it's likely that vmware cpu's *have* gotten the microcode updates, they just don't show the cpuid bits. So the software version is basically slower and less effective. Just don't do it.

I don't think it has been worked out yet, but the reason I added the software sequences is that some CPUs may not be able to do the VERW in microcode updates.

Quoted 5 lines

This is actually fairly ok, because if the verw *really* doesn't do anything, it also isn't very expensive (ie on the order of just 40 cycles instead of 400 cycles). So I'd actually be inclined to say "let's do that for the *initial* patches and back-ports" just to give any vmware users the protection.

I think that's fine

40 cycles will be hard to measure even in the most extreme syscall micro benchmarks, and is unlikely to impact anything real.

It's encryption keys etc. too. But yes.

I think the encryption key case could easily have a "let's scrub cpu state" thing.
It already does other strange things, like memset_safe() or whatever it is that forces a memset even if the compiler decides it's dead.

FWIW from our tests so far the performance loss from the kernel exit overhead
doesn't seem to be that bad.

I haven't seen any numbers, and whilei can believe it's true for the verw case if there is hw acceleration, I doubt the SW case isn't noticeable. Plus we've already seen that people have been way too eager to apply patches just because there is alleged security implications, without doing any kind of risk vs cost analysis.

The data that system calls touch is basically already user data. Sure, there may be kernel pointers etc there, but we've already accepted those leaking locally for all the usual reasons that we have no control over.

So the whole "let's add crazy long sequences to every kernel exit" is not going to happen. Not without a lot more explanations.

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add sysfs reporting

Report mds mitigation state in sysfs vulnerabilities.

Signed-off-by Andi Kleen <[email protected]>

---
 .../ABI/testing/sysfs-devices-system-cpu         |  1 +
 arch/x86/kernel/cpu/bugs.c                       | 16 ++++++++++++++++
 drivers/base/cpu.c                               |  8 ++++++++
 3 files changed, 25 insertions(+)

Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0

index 73318225a368..02b7bb711214 100644
@@ -477,6 +477,7 @@ What:		/sys/devices/system/cpu/vulnerabilities
 		/sys/devices/system/cpu/vulnerabilities/spectre_v2
 		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
 		/sys/devices/system/cpu/vulnerabilities/l1tf
+		/sys/devices/system/cpu/vulnerabilities/mds
 Date:		January 2018
 Contact:	Linux kernel mailing list <[email protected]>
 Description:	Information about CPU vulnerabilities

arch/x86/kernel/cpu/bugs.c +0 -0

index 8200b41b8db9..accab3279068 100644

arch/x86/kernel/cpu/bugs.c +9 -0

+		}
+		return sprintf(buf, "Vulnerable\n");
+
 	default:
 		break;
 	}

@@ -1206,4 +1216,10 @@ ssize_t cpu_show_l1tf(struct device *dev, struct device_attribute *attr, char *b
 {
 	return cpu_show_common(dev, attr, buf, X86_BUG_L1TF);
 }
+
+ssize_t cpu_show_mds(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	return cpu_show_common(dev, attr, buf, X86_BUG_MDS);
+}
+
 #endif

drivers/base/cpu.c +8 -0

index eb9443d5bae1..2fd6ca1021c2 100644
@@ -546,11 +546,18 @@ ssize_t __weak cpu_show_l1tf(struct device *dev,
 	return sprintf(buf, "Not affected\n");
 }
 
+ssize_t __weak cpu_show_mds(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	return sprintf(buf, "Not affected\n");
+}
+
 static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
 static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
 static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
 static DEVICE_ATTR(spec_store_bypass, 0444, cpu_show_spec_store_bypass, NULL);
 static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL);
+static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL);
 
 static struct attribute *cpu_root_vulnerabilities_attrs[] = {
 	&dev_attr_meltdown.attr,

@@ -558,6 +565,7 @@ static struct attribute *cpu_root_vulnerabilities_attrs[] = {
 	&dev_attr_spectre_v2.attr,
 	&dev_attr_spec_store_bypass.attr,
 	&dev_attr_l1tf.attr,
+	&dev_attr_mds.attr,
 	NULL
 };
 

Signature · 1 line

2.17.2

Quoted 33 lines · speck for Andi Kleen

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add sysfs reporting

Report mds mitigation state in sysfs vulnerabilities.

Signed-off-by Andi Kleen <[email protected]>

---
 .../ABI/testing/sysfs-devices-system-cpu         |  1 +
 arch/x86/kernel/cpu/bugs.c                       | 16 ++++++++++++++++
 drivers/base/cpu.c                               |  8 ++++++++
 3 files changed, 25 insertions(+)

Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0

index 73318225a368..02b7bb711214 100644
@@ -477,6 +477,7 @@ What:		/sys/devices/system/cpu/vulnerabilities
 		/sys/devices/system/cpu/vulnerabilities/spectre_v2
 		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
 		/sys/devices/system/cpu/vulnerabilities/l1tf
+		/sys/devices/system/cpu/vulnerabilities/mds
 Date:		January 2018
 Contact:	Linux kernel mailing list <[email protected]>
 Description:	Information about CPU vulnerabilities

arch/x86/kernel/cpu/bugs.c +1 -0

index 8200b41b8db9..accab3279068 100644
@@ -1175,6 +1175,16 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr
 		if (boot_cpu_has(X86_FEATURE_L1TF_PTEINV))
 			return l1tf_show_state(buf);
 		break;
+

arch/x86/kernel/cpu/bugs.c static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr · line 1183

Quoted 5 lines

arch/x86/kernel/cpu/bugs.c +5 -0

+	case X86_BUG_MDS:
+		/* Assumes Hypervisor exposed HT state to us if in guest */
+		if (boot_cpu_has(X86_FEATURE_MB_CLEAR)) {
+			if (cpu_smt_control != CPU_SMT_ENABLED)
+				return sprintf(buf, "Mitigation: MB_CLEAR\n");

I am not sure if a normal system admin would understand what MB_CLEAR means. Is there a way to make this more ..grokked?

arch/x86/kernel/cpu/bugs.c static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr · line 1184

Quoted 1 line

arch/x86/kernel/cpu/bugs.c +1 -0

+			return sprintf(buf, "Mitigation: MB_CLEAR, HT vulnerable\n");

Also you could use "%s", cpu_smt_control != CPU_SMT_ENABLED : "", "SMT vulnerable...")?

Quoted 34 lines · speck for Konrad Rzeszutek Wilk

Quoted 33 lines · speck for Andi Kleen

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add sysfs reporting

Report mds mitigation state in sysfs vulnerabilities.

Signed-off-by Andi Kleen <[email protected]>

---
 .../ABI/testing/sysfs-devices-system-cpu         |  1 +
 arch/x86/kernel/cpu/bugs.c                       | 16 ++++++++++++++++
 drivers/base/cpu.c                               |  8 ++++++++
 3 files changed, 25 insertions(+)

Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0

index 73318225a368..02b7bb711214 100644
@@ -477,6 +477,7 @@ What:		/sys/devices/system/cpu/vulnerabilities
 		/sys/devices/system/cpu/vulnerabilities/spectre_v2
 		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
 		/sys/devices/system/cpu/vulnerabilities/l1tf
+		/sys/devices/system/cpu/vulnerabilities/mds
 Date:		January 2018
 Contact:	Linux kernel mailing list <[email protected]>
 Description:	Information about CPU vulnerabilities

arch/x86/kernel/cpu/bugs.c +1 -0

index 8200b41b8db9..accab3279068 100644
@@ -1175,6 +1175,16 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr
 		if (boot_cpu_has(X86_FEATURE_L1TF_PTEINV))
 			return l1tf_show_state(buf);
 		break;
+

Quoted 8 lines

arch/x86/kernel/cpu/bugs.c static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr · line 1183

Quoted 5 lines

arch/x86/kernel/cpu/bugs.c +5 -0

+	case X86_BUG_MDS:
+		/* Assumes Hypervisor exposed HT state to us if in guest */
+		if (boot_cpu_has(X86_FEATURE_MB_CLEAR)) {
+			if (cpu_smt_control != CPU_SMT_ENABLED)
+				return sprintf(buf, "Mitigation: MB_CLEAR\n");

I am not sure if a normal system admin would understand what MB_CLEAR means. Is there a way to make this more ..grokked?

You mean they are somehow unable to use Google?

xdiff --git a/arch/x86/lib/clear_cpu.S b/arch/x86/lib/clear_cpu.S new file mode 100644
index 000000000000..5af33baf5427

arch/x86/lib/clear_cpu.S new file +31 -0

@@ -0,0 +1,107 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <linux/linkage.h>
+#include <asm/alternative-asm.h>
+#include <asm/cpufeatures.h>
+
+/*
+ * Clear internal CPU buffers on kernel boundaries.
+ *
+ * These sequences are somewhat fragile, please don't add
+ * or change instructions in the middle of the areas marked with
+ * start/end.
+ *
+ * Interrupts and NMIs we deal with by reclearing. We clear parts
+ * of the kernel stack, which has other advantages too.
+ *
+ * Save all registers to make it easier to use for callers.
+ *
+ * This sequence is for Nehalem-IvyBridge. For Haswell we jump
+ * to hsw_clear_buf.
+ *
+ * These functions need to be called on a full stack, as they may
+ * use upto 1.5k of stack. They should be also called with
+ * interrupts disabled. NMIs etc. are handled by letting every
+ * NMI do its own clear sequence.
+ */
+ENTRY(ivb_clear_cpu)
+GLOBAL(do_clear_cpu)
+	/*
+	 * obj[tf]ool complains about unreachable code here,
+	 * which appears to be spurious?!?

arch/x86/lib/clear_cpu.S new file +23 -0

+1:	movntdq %xmm0, (%__ASM_REG(di))
+	add  $16, %__ASM_REG(di)
+	decl %ecx
+	jnz  1b
+	mfence
+	/* Clear sequence end */
+	add  $672, %_ASM_SP
+	movdqu (%_ASM_SP), %xmm0
+	movdqu 1*16(%_ASM_SP), %xmm1
+	mov  %__ASM_REG(si),%_ASM_SP
+	pop %__ASM_REG(cx)
+	pop %__ASM_REG(di)
+	pop %__ASM_REG(si)
+	ret
+END(ivb_clear_cpu)
+
+/*
+ * Version for Haswell/Broadwell.
+ */
+ENTRY(hsw_clear_cpu)
+	push %__ASM_REG(si)
+	push %__ASM_REG(di)
+	push %__ASM_REG(cx)

arch/x86/lib/clear_cpu.S new file +20 -0

+	movl $40,%ecx
+1:	movntdq %xmm0, (%__ASM_REG(di))
+	add  $16, %__ASM_REG(di)
+	decl %ecx
+	jnz  1b
+	mfence
+	mov  %__ASM_REG(si), %__ASM_REG(di)
+	mov $1536, %ecx
+	rep movsb
+	lfence
+	/* Clear sequence end */
+	add $1536,%_ASM_SP
+	movdqa (%_ASM_SP), %xmm0
+	mov %__ASM_REG(ax),%_ASM_SP
+	pop %__ASM_REG(ax)
+	pop %__ASM_REG(cx)
+	pop %__ASM_REG(di)
+	pop %__ASM_REG(si)
+	ret
+END(hsw_clear_cpu)

Quoted 37 lines · speck for Andi Kleen

xdiff --git a/arch/x86/lib/clear_cpu.S b/arch/x86/lib/clear_cpu.S new file mode 100644
index 000000000000..5af33baf5427

arch/x86/lib/clear_cpu.S new file +31 -0

@@ -0,0 +1,107 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <linux/linkage.h>
+#include <asm/alternative-asm.h>
+#include <asm/cpufeatures.h>
+
+/*
+ * Clear internal CPU buffers on kernel boundaries.
+ *
+ * These sequences are somewhat fragile, please don't add
+ * or change instructions in the middle of the areas marked with
+ * start/end.
+ *
+ * Interrupts and NMIs we deal with by reclearing. We clear parts
+ * of the kernel stack, which has other advantages too.
+ *
+ * Save all registers to make it easier to use for callers.
+ *
+ * This sequence is for Nehalem-IvyBridge. For Haswell we jump
+ * to hsw_clear_buf.
+ *
+ * These functions need to be called on a full stack, as they may
+ * use upto 1.5k of stack. They should be also called with
+ * interrupts disabled. NMIs etc. are handled by letting every
+ * NMI do its own clear sequence.
+ */
+ENTRY(ivb_clear_cpu)
+GLOBAL(do_clear_cpu)
+	/*
+	 * obj[tf]ool complains about unreachable code here,
+	 * which appears to be spurious?!?

arch/x86/lib/clear_cpu.S line 41

Quoted 10 lines

arch/x86/lib/clear_cpu.S new file +10 -0

+	 */
+	ALTERNATIVE "", "jmp hsw_clear_cpu", X86_BUG_MDS_CLEAR_CPU_HSWange
+	push %__ASM_REG(si)
+	push %__ASM_REG(di)
+	push %__ASM_REG(cx)
+	mov %_ASM_SP, %__ASM_REG(si)
+	sub  $2*16, %_ASM_SP
+	and  $-16,%_ASM_SP
+	movdqa %xmm0, (%_ASM_SP)
+	movdqa %xmm1, 1*16(%_ASM_SP)

You don't need to preserve %xmm1 here.  It is unmodified by the sequence, because the orpd pulls zero out of its memory operand. Similarly...

arch/x86/lib/clear_cpu.S line 45

Quoted 4 lines

arch/x86/lib/clear_cpu.S new file +4 -0

+	sub  $672, %_ASM_SP
+	xorpd %xmm0,%xmm0
+	movdqa %xmm0, (%_ASM_SP)
+	movdqa %xmm0, 16(%_ASM_SP)

... this store doesn't appear to do anything useful, as that stack slot isn't read again, and...

arch/x86/lib/clear_cpu.S line 54

Quoted 9 lines

arch/x86/lib/clear_cpu.S new file +9 -0

+	mov %_ASM_SP, %__ASM_REG(di)
+	/* Clear sequence start */
+	movdqu %xmm0,(%__ASM_REG(di))
+	lfence
+	orpd (%__ASM_REG(di)), %xmm0
+	orpd (%__ASM_REG(di)), %xmm1
+	mfence
+	movl $40, %ecx
+	add  $32, %__ASM_REG(di)

... I know this was in the recommended sequence, but bytes 16-31 aren't used at all, and it feels fishy.

Either this wants to be $16, or the second orpd wants a displacement of 16 (and we do need to retain the second zeroing write) so all 32 bytes are used.

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Add software sequences for older
CPUs.

On older CPUs before Broadwell clearing the CPU buffer with VERW is not available, so we implement software sequences. These can then be automatically patched in as needed.

Support mitigation for Nehalem upto Broadwell. Broadwell strictly doesn't need it because it should have the microcode update for VERW, which is preferred.

We add command line options to force the two different sequences, mainly for regression testing and if someone wants to test on pre Nehalem CPUs.

Note to backporters: this patch requires eager FPU support.

Note there is no Xeon Phi support so far.

Signed-off-by Andi Kleen <[email protected]>

---
 .../admin-guide/kernel-parameters.txt         |  10 ++
 arch/x86/include/asm/cpufeatures.h            |   2 +
 arch/x86/kernel/cpu/bugs.c                    |  59 +++++++++-
 arch/x86/lib/Makefile                         |   1 +
 arch/x86/lib/clear_cpu.S                      | 107 ++++++++++++++++++
 5 files changed, 176 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/lib/clear_cpu.S

Documentation/admin-guide/kernel-parameters.txt +0 -0

index 48891572e825..16e10f92f8dd 100644

Documentation/admin-guide/kernel-parameters.txt +1 -0

+
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.

arch/x86/include/asm/cpufeatures.h +0 -0

index 93fab3a1e046..110759334c88 100644

arch/x86/include/asm/cpufeatures.h +0 -0

 #endif /* _ASM_X86_CPUFEATURES_H */

arch/x86/kernel/cpu/bugs.c +37 -1

index accab3279068..91619f7d90be 100644
@@ -31,6 +31,8 @@
 #include <asm/intel-family.h>
 #include <asm/e820/api.h>
 #include <asm/hypervisor.h>
+#include <asm/hypervisor.h>
+#include <asm/cpu_device_id.h>
 
 static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);

@@ -1044,11 +1046,55 @@ early_param("l1tf", l1tf_cmdline);
 
 #undef pr_fmt
 
+static const __initconst struct x86_cpu_id cpu_mds_clear_cpu[] = {
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_NEHALEM	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_NEHALEM_G	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_NEHALEM_EP	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_NEHALEM_EX	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_WESTMERE	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_WESTMERE_EP	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_WESTMERE_EX	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_SANDYBRIDGE	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_SANDYBRIDGE_X },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_IVYBRIDGE	 },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_IVYBRIDGE_X	 },
+	{}
+};
+
+static const __initconst struct x86_cpu_id cpu_mds_clear_cpu_hsw[] = {
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_HASWELL_CORE	    },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_HASWELL_X	    },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_HASWELL_ULT	    },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_HASWELL_GT3E	    },
+
+	/* Have MB_CLEAR with microcode update, but list just in case: */
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_BROADWELL_CORE   },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_BROADWELL_GT3E   },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_BROADWELL_X	    },
+	{ X86_VENDOR_INTEL,	6,	INTEL_FAM6_BROADWELL_XEON_D },
+	{}
+};
+
 static void mds_select_mitigation(void)
 {
 	if (cmdline_find_option_bool(boot_command_line, "mds_disable") ||
-	    !boot_cpu_has_bug(X86_BUG_MDS))
+	    !boot_cpu_has_bug(X86_BUG_MDS)) {
 		setup_clear_cpu_cap(X86_FEATURE_MB_CLEAR);
+		setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU_HSW);
+		setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU);
+		return;
+	}
+

Documentation/admin-guide/kernel-parameters.txt line 2350

Quoted 4 lines

Documentation/admin-guide/kernel-parameters.txt +4 -0

+	mds=swclear	[X86]
+			Force using software sequence for clearing data that
+			could be exploited by Micro-architectural Data Sampling.
+			Normally automatically enabled when needed.

s/Normally//?

Documentation/admin-guide/kernel-parameters.txt line 2355

Quoted 5 lines

Documentation/admin-guide/kernel-parameters.txt +5 -0

+
+	mds=swclearhsw	[X86]
+			Use Haswell/Broadwell specific sequence for clearing
+			data that could be exploited by Micro-architectural Data
+			Sampling. Normally automatically enabled when needed.

s/Normally//?

Quoted 8 lines

Documentation/admin-guide/kernel-parameters.txt +1 -0

+
 	mem=nn[KMG]	[KNL,BOOT] Force usage of a specific amount of memory
 			Amount of memory to be used when the kernel is not able
 			to see the whole system memory or for test.

arch/x86/include/asm/cpufeatures.h +0 -0

index 93fab3a1e046..110759334c88 100644

arch/x86/include/asm/cpufeatures.h line 385

Quoted 6 lines

arch/x86/include/asm/cpufeatures.h +2 -0

@@ -381,5 +381,7 @@
 #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
 #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
 #define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
+#define X86_BUG_MDS_CLEAR_CPU		X86_BUG(20) /* CPU needs call to clear_cpu on kernel exit/idle for MDS */
+#define X86_BUG_MDS_CLEAR_CPU_HSW	X86_BUG(21) /* CPU needs Haswell version of clear cpu */

Why do we want to expose these instead of just having 'MDS' be exposed as bug?

Quoted 13 lines

arch/x86/include/asm/cpufeatures.h +1 -1

 	if (cmdline_find_option_bool(boot_command_line, "mds_disable") ||
-	    !boot_cpu_has_bug(X86_BUG_MDS))
+	    !boot_cpu_has_bug(X86_BUG_MDS)) {

arch/x86/include/asm/cpufeatures.h +9 -0

 		setup_clear_cpu_cap(X86_FEATURE_MB_CLEAR);
+		setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU_HSW);
+		setup_clear_cpu_cap(X86_BUG_MDS_CLEAR_CPU);
+		return;
+	}
+
+	if ((!boot_cpu_has(X86_FEATURE_MB_CLEAR) &&
+		x86_match_cpu(cpu_mds_clear_cpu)) ||
+		cmdline_find_option_bool(boot_command_line, "mds=swclear"))
+		setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU);

arch/x86/include/asm/cpufeatures.h

Quoted 6 lines

arch/x86/include/asm/cpufeatures.h +6 -0

+	if ((!boot_cpu_has(X86_FEATURE_MB_CLEAR) &&
+		x86_match_cpu(cpu_mds_clear_cpu_hsw)) ||
+		cmdline_find_option_bool(boot_command_line, "mds=swclearhsw")) {
+		setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU);
+		setup_force_cpu_cap(X86_BUG_MDS_CLEAR_CPU_HSW);
+	}

This all seems scream using loops and array to probe the 'swclear','swclearhsw,'off', etc?

From: Andi Kleen <[email protected]>
Subject: x86/speculation/mds: Force MDS_EXIT on paranoid exit
for sw sequence

When we use a software sequence for clearing CPU buffers an NMI or similar interrupt could interrupt the clearing sequence. In this case make sure we really flush by always doing the extra clearing on paranoid interrupt exit.

This is only needed for the software sequence because VERW is an instruction that cannot be interrupted.

Quoted 1 line · speck for Andi Kleen

From: Andi Kleen <[email protected]>

Interrupting the middle of the software sequence is only one half of the problem.

The other half is when an NMI/#MC/etc hits on the return to guest path after executing VERW, at which point you've just refilled all the buffers between trying to clear them, and returning to userspace.

Quoted 5 lines · speck for Andrew Cooper

Quoted 1 line · speck for Andi Kleen

From: Andi Kleen <[email protected]>

Interrupting the middle of the software sequence is only one half of the problem.

Quoted 3 lines

The other half is when an NMI/#MC/etc hits on the return to guest path after executing VERW, at which point you've just refilled all the buffers between trying to clear them, and returning to userspace.

NMI would seem to be the only exploitable option (since user might user perf to arrange an NMI in this window ... user can't force #MC or SMI on command).

Would NMI fill the microarchitectural buffers with secrets?

Quoted 8 lines · speck for Andrew Cooper

Quoted 1 line · speck for Andi Kleen

From: Andi Kleen <[email protected]>

Interrupting the middle of the software sequence is only one half of the problem.

The other half is when an NMI/#MC/etc hits on the return to guest path after executing VERW, at which point you've just refilled all the buffers between trying to clear them, and returning to userspace.

NMI would seem to be the only exploitable option (since user might user perf to arrange an NMI in this window ... user can't force #MC or SMI on command).

Would NMI fill the microarchitectural buffers with secrets?