On 24.07.2025 14:56, Jan Beulich wrote:
> This particular variant has an error that causes RDSEED to always return
> 0xffffffff, while RDRAND works correctly.
>
> Inspired by Linux commit 5b937a1ed64ebeba8876e398110a5790ad77407c
> ("x86/rdrand: Disable RDSEED on AMD Cyan Skillfish").
>
> Like for RDRAND, permit a command line override to be used to keep
> RDSEED enabled.
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> ---
> Considering how it is described, I didn't think probing RDSEED (like we
> do for RDRAND) would be necessary.
>
> Am I going too far in also updating cpuidmask_defaults here, or is us
> not doing so for the RDRAND disabling actually an oversight?
>
> Using warning_add() may not be quite appropriate, as we don't really
> mean the admin to possibly override this with "cpuid=rdseed" (that's
> only a last resort, in case the issue is yet more limited in scope). But
> mere printk() would feel like hiding the information in the middle of
> lots of other output.
And, other than presumably intended judging from the RDRAND logic, passing
"cpuid=no-rdseed" doesn't prevent the warning. That's - aiui - because the
clearing of forced-cleared features happens only afterwards. Apparently we
would need yet another predicate is_cleared_cpu_cap(). Or have
is_forced_cpu_cap() check both forced_caps[] and cleared_caps[]. (As per
present uses doing the latter would be okay, but I'm not sure whether
checking both in the same predicate would be a good idea going forward.)
Jan
