Let the hardware domain know about the hardware it is running on. This
allows a linux Dom0 to know that it has the appropriate microcode via
FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
changes from:
"Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state
unknown"
to:
"Mitigation: Clear CPU buffers; SMT Host state unknown"
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---
Should calculate_host_policy()'s arch_caps mask also be updated? They
are not identical today, but I'm don't know this code to understand why
they differ.
xen/arch/x86/msr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index c2c0025e3a..f1c36d423f 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -163,7 +163,9 @@ int init_domain_msr_policy(struct domain *d)
mp->arch_caps.raw = val &
(ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA |
- ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_TAA_NO);
+ ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_TAA_NO |
+ ARCH_CAPS_SBDR_SSDP_NO | ARCH_CAPS_FBSDP_NO | ARCH_CAPS_PSDP_NO |
+ ARCH_CAPS_FB_CLEAR);
}
d->arch.msr = mp;
--
2.36.1
On 18.07.2022 16:05, Jason Andryuk wrote: > Let the hardware domain know about the hardware it is running on. This > allows a linux Dom0 to know that it has the appropriate microcode via > FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data > changes from: > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > unknown" > to: > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > --- > Should calculate_host_policy()'s arch_caps mask also be updated? They > are not identical today, but I'm don't know this code to understand why > they differ. I think this wants updating too, yes. I'm afraid I have to leave it to Andrew to provide the reasons for the differences between the two. I would further suggest to also consider adding RRSBA and BHI_NO, even if then the title would want adjusting. And finally I'd like to ask to add a proper Fixes: tag (or more), as it looks like the updating here was simply forgotten when the bits were introduced. Ideally we'd have a way for the compiler to remind us of updates being needed (or at least be considered) here. Jan
On Mon, Jul 18, 2022 at 10:18 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 18.07.2022 16:05, Jason Andryuk wrote: > > Let the hardware domain know about the hardware it is running on. This > > allows a linux Dom0 to know that it has the appropriate microcode via > > FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data > > changes from: > > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > > unknown" > > to: > > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > > --- > > Should calculate_host_policy()'s arch_caps mask also be updated? They > > are not identical today, but I'm don't know this code to understand why > > they differ. > > I think this wants updating too, yes. I'm afraid I have to leave it to > Andrew to provide the reasons for the differences between the two. > > I would further suggest to also consider adding RRSBA and BHI_NO, even > if then the title would want adjusting. And finally I'd like to ask to > add a proper Fixes: tag (or more), as it looks like the updating here > was simply forgotten when the bits were introduced. Ideally we'd have > a way for the compiler to remind us of updates being needed (or at > least be considered) here. That all sounds good. Thanks, Jason
On 18/07/2022 15:34, Jason Andryuk wrote: > On Mon, Jul 18, 2022 at 10:18 AM Jan Beulich <jbeulich@suse.com> wrote: >> On 18.07.2022 16:05, Jason Andryuk wrote: >>> Let the hardware domain know about the hardware it is running on. This >>> allows a linux Dom0 to know that it has the appropriate microcode via >>> FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data >>> changes from: >>> "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state >>> unknown" >>> to: >>> "Mitigation: Clear CPU buffers; SMT Host state unknown" >>> >>> Signed-off-by: Jason Andryuk <jandryuk@gmail.com> >>> --- >>> Should calculate_host_policy()'s arch_caps mask also be updated? They >>> are not identical today, but I'm don't know this code to understand why >>> they differ. >> I think this wants updating too, yes. I'm afraid I have to leave it to >> Andrew to provide the reasons for the differences between the two. >> >> I would further suggest to also consider adding RRSBA and BHI_NO, even >> if then the title would want adjusting. And finally I'd like to ask to >> add a proper Fixes: tag (or more), as it looks like the updating here >> was simply forgotten when the bits were introduced. Ideally we'd have >> a way for the compiler to remind us of updates being needed (or at >> least be considered) here. > That all sounds good. This is all one giant hack because of the fact we don't virtualise MSR_ARCH_CAPS properly for guests yet. Furthermore, Linux's sysfs files are largely nonsense in a PV guest. "SMT=unknown" is a good example, but others need help too. The calculate_host_policy() list does want updating. That's my fault for forgetting; it's the first MSR "feature leaf" and none of this is calculated automatically. The raw and host values are exactly as per CPUID. raw = real CPU values, host = subset that Xen understands. In reality, there's a lot of hardware where model checks should cause us to synthesize bits in the host policy which are missing in raw, but doing that nicely still depends on untangling microcode loading from xmalloc() so we can sort things out much earlier. I agree with Jan that dom0 should see RRSBA and BHI_NO. The former should be enumerated from ADL/SPR whereas I have no idea when BHI_NO might land. ~Andrew
© 2016 - 2024 Red Hat, Inc.