Hi Pawan, hi Daniel
Thanks for the patch.
I tried similar patch on Icelake server:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 57 bits virtual
CPU(s): 64
On-line CPU(s) list: 0-63
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 106
Model name: Intel(R) Xeon(R) Gold 6346 CPU @ 3.1
0GHz
Stepping: 6
CPU MHz: 3100.000
CPU max MHz: 3600,0000
CPU min MHz: 800,0000
BogoMIPS: 6200.00
Virtualization: VT-x
L1d cache: 1,5 MiB
L1i cache: 1 MiB
L2 cache: 40 MiB
L3 cache: 72 MiB
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26
,28,30,32,34,36,38,40,42,44,46,48,50
,52,54,56,58,60,62
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27
,29,31,33,35,37,39,41,43,45,47,49,51
,53,55,57,59,61,63
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT v
ulnerable
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass
disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers
and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB cond
itional, RSB filling, PBRSB-eIBRS SW
sequence
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 97ad229d8ba3..48709b77689f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1155,7 +1155,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
NULL, "sbdr-ssdp-no", "fbsdp-no", "psdp-no",
NULL, "fb-clear", NULL, NULL,
NULL, NULL, NULL, NULL,
- "pbrsb-no", NULL, NULL, NULL,
+ "pbrsb-no", NULL, "gds-no", NULL,
NULL, NULL, NULL, NULL,
},
.msr = {
--
2.34.1
For the change Pawan provided, I tested on Icelake server, it works as expected.
Somehow I'm not cc for the patch, but please consider it tested
Reported-by: Jack Wang <jinpu.w...@ionos.com>
Tested-by: Jack Wang <jinpu.w...@ionos.com>
Thx!
Jinpu Wang
while if I patches QEMU below:
On Fri, Aug 11, 2023 at 3:12 PM Jinpu Wang <jinpu.w...@ionos.com> wrote:
>
> Hi folks on the list:
>
> I'm testing the latest Downfall cpu vulnerability mitigation. what I
> notice is when both host and guest are using patched kernel +
> microcode eg kernel 5.15.125 + intel-microcode 20230808 on affected
> server eg Icelake server.
>
> The mitigation status inside guest is:
>
> Vulnerabilities:
> Gather data sampling: Unknown: Dependent on hyp
> ervisor status
> -----------------------------------> this one.
> Itlb multihit: Not affected
> L1tf: Not affected
> Mds: Not affected
> Meltdown: Not affected
> Mmio stale data: Vulnerable: Clear CPU buf
> fers attempted, no microc
> ode; SMT Host state unkno
> wn
> Retbleed: Not affected
> Spec rstack overflow: Not affected
> Spec store bypass: Mitigation; Speculative S
> tore Bypass disabled via
> prctl and seccomp
> Spectre v1: Mitigation; usercopy/swap
> gs barriers and __user po
> inter sanitization
> Spectre v2: Mitigation; Enhanced IBRS
> , IBPB conditional, RSB f
> illing, PBRSB-eIBRS SW se
> quence
> Srbds: Not affected
> Tsx async abort: Not affected
>
> According to kernel commit below
> commit 81ac7e5d741742d650b4ed6186c4826c1a0631a7
> Author: Daniel Sneddon <daniel.sned...@linux.intel.com>
> Date: Wed Jul 12 19:43:14 2023 -0700
>
> KVM: Add GDS_NO support to KVM
>
> Gather Data Sampling (GDS) is a transient execution attack using
> gather instructions from the AVX2 and AVX512 extensions. This attack
> allows malicious code to infer data that was previously stored in
> vector registers. Systems that are not vulnerable to GDS will set the
> GDS_NO bit of the IA32_ARCH_CAPABILITIES MSR. This is useful for VM
> guests that may think they are on vulnerable systems that are, in
> fact, not affected. Guests that are running on affected hosts where
> the mitigation is enabled are protected as if they were running
> on an unaffected system.
>
> On all hosts that are not affected or that are mitigated, set the
> GDS_NO bit.
>
> Signed-off-by: Daniel Sneddon <daniel.sned...@linux.intel.com>
> Signed-off-by: Dave Hansen <dave.han...@linux.intel.com>
> Acked-by: Josh Poimboeuf <jpoim...@kernel.org>
>
> KVM also has the support of GDS_NO, but seems qemu side doesn't pass
> the info to guest, that's why it is unknown. IMO qemu should pass
> GDS_NO if the host is already patched.
>
> Is Intel or anyone already working on the qemu patch? I know it's not
> a must, but good to do.
>
> Thx!
> Jinpu Wang @ IONOS Cloud
