| Message ID | 20241203001629.132594-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | libs/guest: Fix migration compatibility with a security-patched Xen 4.13 | expand |
On 03.12.2024 01:16, Andrew Cooper wrote: > xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM > where no CPUID data was provided in the stream. > > It guesses the various max-leaf limits, based on what was true at the time of > writing, but this was not correctly adapted when speculative security issues > forced the advertisement of new feature bits. Of note are: > > * LFENCE-DISPATCH, in leaf 0x80000021.eax > * BHI-CTRL, in leaf 0x7[2].edx > > In both cases, a VM booted on a security-patched Xen 4.13, and then migrated > on to any newer version of Xen on the same or compatible hardware would have > these features stripped back because Xen is still editing the cpu-policy for > sanity behind the back of the toolstack. > > For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to > restore the guests MSR_SPEC_CTRL setting: > > (XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed > (XEN) HVM7 restore: failed to load entry 20/0 rc -6 > > Fixes: e9b4fe263649 ("x86/cpuid: support LFENCE always serialising CPUID bit") > Fixes: f3709b15fc86 ("x86/cpuid: Infrastructure for cpuid word 7:2.edx") > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c index 4453178100ad..263a9d4787b6 100644 --- a/tools/libs/guest/xg_cpuid_x86.c +++ b/tools/libs/guest/xg_cpuid_x86.c @@ -640,7 +640,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, * * This restore path is used for incoming VMs with no CPUID data * i.e. originated on Xen 4.13 or earlier. We must invent a policy - * compatible with what Xen 4.13 would have done on the same hardware. + * compatible with what a security-patched Xen 4.13 would have done on + * the same hardware. * * Specifically: * - Clamp max leaves. @@ -657,8 +658,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, } p->policy.basic.max_leaf = min(p->policy.basic.max_leaf, 0xdu); - p->policy.feat.max_subleaf = 0; - p->policy.extd.max_leaf = min(p->policy.extd.max_leaf, 0x8000001c); + p->policy.feat.max_subleaf = min(p->policy.feat.max_subleaf, 0x2u); + p->policy.extd.max_leaf = min(p->policy.extd.max_leaf, 0x80000021); } if ( featureset )
xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM where no CPUID data was provided in the stream. It guesses the various max-leaf limits, based on what was true at the time of writing, but this was not correctly adapted when speculative security issues forced the advertisement of new feature bits. Of note are: * LFENCE-DISPATCH, in leaf 0x80000021.eax * BHI-CTRL, in leaf 0x7[2].edx In both cases, a VM booted on a security-patched Xen 4.13, and then migrated on to any newer version of Xen on the same or compatible hardware would have these features stripped back because Xen is still editing the cpu-policy for sanity behind the back of the toolstack. For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to restore the guests MSR_SPEC_CTRL setting: (XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed (XEN) HVM7 restore: failed to load entry 20/0 rc -6 Fixes: e9b4fe263649 ("x86/cpuid: support LFENCE always serialising CPUID bit") Fixes: f3709b15fc86 ("x86/cpuid: Infrastructure for cpuid word 7:2.edx") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> Every option here is terrible. This is the least terrible one I could come up with. XenServer, still the only caller to provide featureset into xc_cpuid_apply_policy() could in principle reverse engineer these two numbers from the non-zero-ness of the passed-in feature words. However, such an approach more complicated, equally as fragile, and not reusable with the current plans to re-integrate the shrinking logic. i.e. this is the least invasive option. --- tools/libs/guest/xg_cpuid_x86.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) base-commit: 126b0a6e537ce1d486a29e35cfeec1f222a74d11