Today's hardware vulnerability: register file data sampling

[Posted March 12, 2024 by corbet]

The mainline kernel has just received a set of commits addressing the "register file data sampling" hardware vulnerability.

RFDS may allow a malicious actor to infer data values previously used in floating point registers, vector registers, or integer registers. RFDS does not provide the ability to choose which data is inferred

Only Atom cores are affected, but those cores can be found inside a number of processors. See this documentation commit for more information.

Today's hardware vulnerability: register file data sampling

Posted Mar 12, 2024 21:35 UTC (Tue) by developer122 (guest, #152928) [Link] (6 responses)

Would be nice if this documentation specified the minimum version or date that mirocode covering this vulnerability was released. It's hard to tell if this only requires the previous microcode modifying the vehavior of VERW, or if new microcode is required for this specific vulnerability is required which adds new registers to the list of those cleared by VERW.

Today's hardware vulnerability: register file data sampling

Posted Mar 12, 2024 22:29 UTC (Tue) by hmh (subscriber, #3838) [Link] (5 responses)

Maybe this helps:

https://www.intel.com/content/www/us/en/developer/topic-t...

Today's hardware vulnerability: register file data sampling

Posted Mar 12, 2024 23:00 UTC (Tue) by Heretic_Blacksheep (guest, #169992) [Link] (4 responses)

The better link is to Intel's original disclosure which has the technical details:

https://www.intel.com/content/www/us/en/developer/article...

I wouldn't assume previous unsupported generations of Atom processors aren't vulnerable because they're not listed. Intel specifically says in the fine print for the consolidated table:

"Refer to the 2022-2024 tab of the consolidated Affected Processors table: Register File Data Sampling column. Processors which have reached their End Of Servicing Lifetime are not listed in the consolidated table. Intel does not plan to evaluate whether any such processors are affected. Refer to the Support page for more information."

They may or may not be vulnerable. Intel isn't going to bother to check. It's left as an exercise to those who own and may still use those processors to check if RFDS (and any future hardware vulns) affect them and what to do about it.

That said, any of the in-order Atom CPUs probably won't be affected by hardware vulns that require speculative out-of-order execution. But if I'm reading the disclosure correctly, this isn't one of those vulnerabilities. Instead, it's a stale data not being cleared after processing vulnerability that can potentially leak sensitive data from places that shouldn't be leaking like the SGX domain or privileged kernel data using the AES-NI instructions. Spectre branch misprediction exploitation doesn't appear to be required here.

Today's hardware vulnerability: register file data sampling

Posted Mar 13, 2024 2:47 UTC (Wed) by willy (subscriber, #9762) [Link] (1 responses)

Did the earlier Atoms support SGX?

Today's hardware vulnerability: register file data sampling

Posted Mar 13, 2024 16:42 UTC (Wed) by Sesse (subscriber, #53779) [Link]

I searched a bit, and was unable to find any. The only thing SGX on desktop would make sense for was really UHD-BR, in case you had an Atom HTPC or something (I don't think they allowed UHD-BR software players that didn't protect the keys using something similar strong?), but it doesn't seem like that was ever supported. So it was only 6th–10th generation (Skylake and up to some point).

It's hard to find information about this now, though.

Today's hardware vulnerability: register file data sampling

Posted Mar 14, 2024 7:25 UTC (Thu) by anton (subscriber, #25547) [Link] (1 responses)

Bonnell (the in-order microarchitecture of the first Atom generation) is unlikely to be affected, because 1) it's completely different from the OoO microarchitectures used in later generations and, in particular, 2) it does not use register renaming, so there are no stale physical registers; all physical registers are architectural and directly readable.

The Silvermont and Airmont microarchitectures are between Bonnell and the listed Goldmont. Are there no supported products with these microarchitectures? My impression is that "Atom" cores are used longer in products than "Core" cores, and they might well be still supported.

Today's hardware vulnerability: register file data sampling

Posted Mar 14, 2024 10:33 UTC (Thu) by anton (subscriber, #25547) [Link]

Looking around a bit, at least the Silvermont-based Atom E3805 is still in the marketing status "launched" (rather than "discontinued"), so I would expect that Intel has checked Silvermont and that they think that Silvermont is not affected.

Concerning Airmont, I have not looked around until I found a CPU with Airmont that is still being considered in service, but Airmont is mostly a shrink of Silvermont, so it is unlikely to be affected if Silvermont is not; or in other words, it is more likely that they introduced this bug between Airmont and Goldmont than between Silvermont and Airmont.

Today's hardware vulnerability: register file data sampling

Posted Mar 12, 2024 22:19 UTC (Tue) by flussence (guest, #85566) [Link]

Looks like it's only the newer, superscalar, Celeron-rebrand Atoms that are affected. Owners of old netbooks get to keep their spotless hwvuln scorecard.

Today's hardware vulnerability: register file data sampling

Posted Mar 13, 2024 9:51 UTC (Wed) by ianmcc (subscriber, #88379) [Link] (1 responses)

Otherwise known as E-cores. As far as I can tell, most Alder Lake CPU's, except for a handful of i3 and i5's. Even within a processor number, it is hard to tell. eg the i5-12600 and i5-12600T don't contain e-cores, but the K, KF, H, HE, HX, HL variants do.

Today's hardware vulnerability: register file data sampling

Posted Mar 13, 2024 16:12 UTC (Wed) by k3ninho (subscriber, #50375) [Link]

It's worth highlighting that desktop 12/13/14 gen Intel Core processors are listed as affected because their Efficiency Cores --where they have them -- are derived from Atom.

K3n.

Does mitigated RFDS still leak kernel address layout information?

Posted Mar 15, 2024 13:56 UTC (Fri) by hmh (subscriber, #3838) [Link]

Since you cannot erase the architectural registers (duh), RFDS will always "leak" the contents of the kernel's stack pointer and instruction pointer right before return-to-userspace, for example.

So, anything that comes after the augmented VERW instruction is potentially leaked to the next context that runs (can be userspace, or a VM, etc). I believe there is an exception for instructions that switch away from SGX and SMM, which were also modified to clear the register file (or so I believe from a cursory reading of the Intel documentation).

Is there any relevant security impact from this? It looks like it might let one derive the approximate location of the syscall return stack and routine... how much does this impact ASLR ?

Obviously this can also be mitigated at "high cost" anywhere P-cores are available, by restricting all kernel code to run only on P-cores... at which point it might make more sense to just disable E-cores (and SMT, or it would be just security theater -- at least until we can ensure the kernel always context switches the entire core when entering or leaving kernel mode, or a VM).