x86: Drop cross-vendor support

[PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

Posted by Alejandro Vallejo 3 days, 14 hours ago

While in principle it's possible to have a vendor virtualising another,
this is fairly tricky in practice and comes with the world's supply of
security issues.

Reject any CPU policy with vendors not matching the host's.

Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
---
 CHANGELOG.md         | 4 ++++
 xen/lib/x86/policy.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 18f3d10f20..eae2f961c7 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
      prior to the version 1.0 release, and there has been no development since
      before then in Xen.
+   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs
+     from the host so that security mitigations stay consistent. Cross-vendor
+     setups have been unreliable and not practical since 2017 with the advent of
+     speculation security.
 
  - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
    anything useful outside of x86.
diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
index f033d22785..4c0c5386ea 100644
--- a/xen/lib/x86/policy.c
+++ b/xen/lib/x86/policy.c
@@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
 #define FAIL_MSR(m) \
     do { e.msr = (m); goto out; } while ( 0 )
 
-    if ( guest->basic.max_leaf > host->basic.max_leaf )
+    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
+         (guest->x86_vendor     != host->x86_vendor) )
         FAIL_CPUID(0, NA);
 
     if ( guest->feat.max_subleaf > host->feat.max_subleaf )
-- 
2.43.0

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

Posted by Andrew Cooper 2 days, 15 hours ago

On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 18f3d10f20..eae2f961c7 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>     - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>       prior to the version 1.0 release, and there has been no development since
>       before then in Xen.
> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs
> +     from the host so that security mitigations stay consistent. Cross-vendor
> +     setups have been unreliable and not practical since 2017 with the advent of
> +     speculation security.

This is going to want expanding upon, but there's a subtle change in
patch 4 needing addressing first.

> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785..4c0c5386ea 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>  #define FAIL_MSR(m) \
>      do { e.msr = (m); goto out; } while ( 0 )
>  
> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
> +         (guest->x86_vendor     != host->x86_vendor) )
>          FAIL_CPUID(0, NA);

    if ( guest->x86_vendor     != host->x86_vendor ||
         guest->basic.max_leaf >  host->basic.max_leaf )

please.  This function is going to get much much longer when we're done
with it, and I'd like to try and keep the checks in the right cognitive
order.

~Andrew

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

Posted by Teddy Astie 3 days, 14 hours ago

Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
> While in principle it's possible to have a vendor virtualising another,
> this is fairly tricky in practice and comes with the world's supply of
> security issues.
> 
> Reject any CPU policy with vendors not matching the host's.
> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
>   CHANGELOG.md         | 4 ++++
>   xen/lib/x86/policy.c | 3 ++-
>   2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 18f3d10f20..eae2f961c7 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>        prior to the version 1.0 release, and there has been no development since
>        before then in Xen.
> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs> +     from the host so that security mitigations stay consistent. 
Cross-vendor
> +     setups have been unreliable and not practical since 2017 with the advent of
> +     speculation security.
>   

I don't really like the wording, it sounds like guest will suddenly stop 
to work for some reason. AFAIK, in the Xen Project only suspend/resume 
logic is going to be affected, and we probably want to reflect on that 
instead.

>    - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
>      anything useful outside of x86.
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785..4c0c5386ea 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>   #define FAIL_MSR(m) \
>       do { e.msr = (m); goto out; } while ( 0 )
>   
> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
> +         (guest->x86_vendor     != host->x86_vendor) )
>           FAIL_CPUID(0, NA);
>   
>       if ( guest->feat.max_subleaf > host->feat.max_subleaf )



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's

Posted by Alejandro Vallejo 2 days, 20 hours ago

On Thu Jan 22, 2026 at 6:13 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
>> While in principle it's possible to have a vendor virtualising another,
>> this is fairly tricky in practice and comes with the world's supply of
>> security issues.
>> 
>> Reject any CPU policy with vendors not matching the host's.
>> > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>>   CHANGELOG.md         | 4 ++++
>>   xen/lib/x86/policy.c | 3 ++-
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>> index 18f3d10f20..eae2f961c7 100644
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>>      - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014
>>        prior to the version 1.0 release, and there has been no development since
>>        before then in Xen.
>> +   - Cross-vendor support.  Refuse to start domains whose CPU vendor differs> +     from the host so that security mitigations stay consistent. 
> Cross-vendor

???

>> +     setups have been unreliable and not practical since 2017 with the advent of
>> +     speculation security.
>>   
>
> I don't really like the wording, it sounds like guest will suddenly stop 
> to work for some reason. AFAIK, in the Xen Project only suspend/resume 
> logic is going to be affected, and we probably want to reflect on that 
> instead.

You also won't be able to start a cross vendor VM, which you can do by
manually picking the CPUID leaves in xl.cfg. Though you're right that for the
overwhelming majority of affected users this would manifest as not being able to
restore a saved VM (or not being able to live-migrate, which is effectively the
same thing for this purpose). It's unlikely anyone abuses xl the way I
described.

I'll reword it differently to note the overwhelmingly most affected workflow.

>
>>    - Removed xenpm tool on non-x86 platforms as it doesn't actually provide
>>      anything useful outside of x86.
>> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
>> index f033d22785..4c0c5386ea 100644
>> --- a/xen/lib/x86/policy.c
>> +++ b/xen/lib/x86/policy.c
>> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host,
>>   #define FAIL_MSR(m) \
>>       do { e.msr = (m); goto out; } while ( 0 )
>>   
>> -    if ( guest->basic.max_leaf > host->basic.max_leaf )
>> +    if ( (guest->basic.max_leaf >  host->basic.max_leaf) ||
>> +         (guest->x86_vendor     != host->x86_vendor) )
>>           FAIL_CPUID(0, NA);
>>   
>>       if ( guest->feat.max_subleaf > host->feat.max_subleaf )
>
>
>
> --
> Teddy Astie | Vates XCP-ng Developer
>
> XCP-ng & Xen Orchestra - Vates solutions
>
> web: https://vates.tech