Re: [PATCH v2 for-4.21 0/2] x86/AMD: deal with RDSEED issues

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.10.2025 14:15, Roger Pau Monné wrote:
> On Fri, Oct 31, 2025 at 01:34:55PM +0100, Jan Beulich wrote:
>> On 31.10.2025 13:14, Roger Pau Monné wrote:
>>> On Fri, Oct 31, 2025 at 12:47:51PM +0100, Jan Beulich wrote:
>>>> On 31.10.2025 11:54, Roger Pau Monné wrote:
>>>>> On Fri, Oct 31, 2025 at 11:29:44AM +0100, Jan Beulich wrote:
>>>>>> On 31.10.2025 11:22, Roger Pau Monné wrote:
>>>>>>> On Tue, Oct 28, 2025 at 04:32:17PM +0100, Jan Beulich wrote:
>>>>>>>> Both patches also want 'x86/CPU: extend is_forced_cpu_cap()'s "reach"' 
>>>>>>>> in
>>>>>>>> place.
>>>>>>>>
>>>>>>>> 1: disable RDSEED on Fam17 model 47 stepping 0
>>>>>>>> 2: disable RDSEED on most of Zen5
>>>>>>>
>>>>>>> For both patches: don't we need to set the feature in the max policy
>>>>>>> to allow for incoming migrations of guests that have already seen the
>>>>>>> feature?
>>>>>>
>>>>>> No, such guests should not run on affected hosts (unless overrides are 
>>>>>> in place),
>>>>>> or else they'd face sudden malfunction of RDSEED. If an override was in 
>>>>>> place on
>>>>>> the source host, an override will also need to be put in place on the 
>>>>>> destination
>>>>>> one.
>>>>>
>>>>> But they may be malfunctioning before already, if started on a
>>>>> vulnerable hosts without this fix and having seen RDSEED?
>>>>
>>>> Yes. But there could also be ones coming from good hosts. Imo ...
>>>>
>>>>> IMO after this fix is applied you should do pool leveling, at which
>>>>> point RDSEED shouldn't be advertised anymore.  Having the feature in
>>>>> the max policy allows to evacuate running guests while updating the
>>>>> pool.  Otherwise those existing guests would be stuck to run on
>>>>> non-updated hosts.
>>>>
>>>> ... we need to err on the side of caution.
>>>
>>> While I understand your concerns, this would cause failures in the
>>> upgrade and migration model used by both XCP-ng and XenServer at
>>> least, as it could prevent eviction of running VMs to updated hosts.
>>>
>>> At a minimum we would need an option to allow the feature to be set on
>>> the max policy.
>>
>> That's where the 3rd patch comes into play. "cpuid=rdseed" is the respective
>> override. Just that it doesn't work correctly without that further patch.
> 
> Won't using "cpuid=rdseed" in the Xen command line result in RDSEED
> getting exposed in the default policy also, which we want to avoid?
> 
> Or am I getting confused on where "cpuid=rdseed" should be used?

No, there's no way here to get max but not default.

>>>  Overall I think safety of migration (in this specific
>>> regard) should be enforced by the toolstack (or orchestration layer),
>>> rather than the hypervisor itself.  The hypervisor can reject
>>> incompatible policies, but should leave the rest of the decisions to
>>> higher layers as it doesn't have enough knowledge.
>>
>> But without rendering guests vulnerable behind the admin's back.
> 
> I think that's part of the logic that should be implemented by the
> orchestration layer, simply because it has all the data to make an
> informed decision.  IMO it won't be behind the admin's back, or else
> it's a bug in the higher layer toolstack.

I fear I simply don't see aspects like this to be exposed to a toolstack.
We didn't for RDRAND.

> Not putting rdseed in the max policy completely blocks the upgrade
> path, even when a toolstack is possibly making the right informed
> decisions.
> 
> I guess I need to see that 3rd patch.

https://lists.xen.org/archives/html/xen-devel/2025-08/msg00113.html

Jan