Hi again,
On Tue, Nov 22, 2022 at 11:35:06AM +0000, Pedro Falcato wrote:
> We should probably also test for stupidly broken rdrand implementations
> like the notorious Zen 3 which always return 0xFFFFFFFF (per xkcd 221 ;)).
On this topic, if you did want to improve this part of that DXE, the
kernel's test for this is super dumb and basic but I think basically
gets the job done for the most pathological scenarios.
>From arch/x86/kernel/cpu/rdrand.c:
void x86_init_rdrand(struct cpuinfo_x86 *c)
{
enum { SAMPLES = 8, MIN_CHANGE = 5 };
unsigned long sample, prev;
bool failure = false;
size_t i, changed;
if (!cpu_has(c, X86_FEATURE_RDRAND))
return;
for (changed = 0, i = 0; i < SAMPLES; ++i) {
if (!rdrand_long(&sample)) {
failure = true;
break;
}
changed += i && sample != prev;
prev = sample;
}
if (changed < MIN_CHANGE)
failure = true;
if (failure) {
clear_cpu_cap(c, X86_FEATURE_RDRAND);
clear_cpu_cap(c, X86_FEATURE_RDSEED);
pr_emerg("RDRAND is not reliable on this platform; disabling.\n");
}
}
Feel free to lift that into the DXE if you want. That should probably be
a different patch to this series, though, as I mentioned in my last
email. The CPUID check that you mentioned, however, seems like an
important prerequisite to this series.
Jason
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96559): https://edk2.groups.io/g/devel/message/96559
Mute This Topic: https://groups.io/mt/94935843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
