Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs) from at
least Goldmont onwards have a vulnerability called "Register file data sampling".
Apparently Intel has discovered this on their own, so the
only thing we have about this is a rather thin description <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html>
that does not explain what is happening. But apparently there is some
way to extract the data from free physical registers.
Supposedly the vulnerability does not allow the attacker "to choose
which data is inferred using these methods", which I find hard to
believe; that would require non-determinism in the register allocation implementation, or in the mechanism that allows extracting this
information. In any case, even if you do not know whether the
register contains the desired secret, the attacker gets a good
candidate list by getting a few hundred of such register contents and
then working with those few hundred instead of having to brute-force
with 2^64 or 2^128 possible values.
As a mitigation mechanism, they have tacked microcode onto the VERW instruction that apparently clears enough state to avoid revealing any
stale register contants from before the VERW instruction. So one
should use VERW when exiting secret-handling code.
- anton
On Thu, 14 Mar 2024 09:58:24 GMT
[email protected] (Anton Ertl) wrote:
Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs) from at
least Goldmont onwards have a vulnerability called "Register file data
sampling".
I think, it's worse.
Airmont is affected.
As a mitigation mechanism, they have tacked microcode onto the VERW
instruction that apparently clears enough state to avoid revealing any
stale register contants from before the VERW instruction. So one
should use VERW when exiting secret-handling code.
According to my understanding, 'one' in this case is the OS that does
context switch. Doing VERW on return from majority of crypto
routine looks both less important and less useful.
Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs) from at
least Goldmont onwards have a vulnerability called "Register file data sampling". Apparently Intel has discovered this on their own, so the
only thing we have about this is a rather thin description <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html>
that does not explain what is happening. But apparently there is some
way to extract the data from free physical registers.
Supposedly the vulnerability does not allow the attacker "to choose
which data is inferred using these methods", which I find hard to
believe; that would require non-determinism in the register allocation implementation, or in the mechanism that allows extracting this
information. In any case, even if you do not know whether the
register contains the desired secret, the attacker gets a good
candidate list by getting a few hundred of such register contents and
then working with those few hundred instead of having to brute-force
with 2^64 or 2^128 possible values.
As a mitigation mechanism, they have tacked microcode onto the VERW instruction that apparently clears enough state to avoid revealing any
stale register contants from before the VERW instruction. So one
should use VERW when exiting secret-handling code.
- anton
Michael S <[email protected]> writes:
On Thu, 14 Mar 2024 09:58:24 GMT
[email protected] (Anton Ertl) wrote:
Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs)
from at least Goldmont onwards have a vulnerability called
"Register file data sampling".
I think, it's worse.
Airmont is affected.
Citation needed.
As a mitigation mechanism, they have tacked microcode onto the VERW
instruction that apparently clears enough state to avoid revealing
any stale register contants from before the VERW instruction. So
one should use VERW when exiting secret-handling code.
According to my understanding, 'one' in this case is the OS that does >context switch. Doing VERW on return from majority of crypto
routine looks both less important and less useful.
Why do you think so? It seems very important and useful to me. You
don't want your passwords or secret keys lying around in registers
from where an attacker (say, some JavaScript code) might extract them.
- anton
Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs) from at
least Goldmont onwards have a vulnerability called "Register file data >sampling".
On Thu, 14 Mar 2024 16:58:29 GMT
[email protected] (Anton Ertl) wrote:
Michael S <[email protected]> writes:
On Thu, 14 Mar 2024 09:58:24 GMT
[email protected] (Anton Ertl) wrote:
Intel's E-Cores (aka Atom by some, including Intel people; I
personnally use "Atom" only for (in-order) Bonnell-based CPUs)
from at least Goldmont onwards have a vulnerability called
"Register file data sampling".
I think, it's worse.
Airmont is affected.
Citation needed.
My mistake. I looked at it yesterday night and confused Apollo Lake >(Goldmont-based) with Braswell (Airmont).
According to my understanding, 'one' in this case is the OS that does
context switch. Doing VERW on return from majority of crypto
routine looks both less important and less useful.
Why do you think so? It seems very important and useful to me. You
don't want your passwords or secret keys lying around in registers
from where an attacker (say, some JavaScript code) might extract them.
- anton
First, there is no indication that attack can be launched from
JavaScript.
Second, even when rogue program tries, say, to log on with bad password
and then to learn something from reminder left in registers by
comparison of the hashes, it's still not a simple library call. There
is still at least one switch of trust context, managed by OS, before
attacker gets control back.
However my impression is that most dangerous attack scenario is
that attacker examines stale registers immediately after woken up after >preemption
Of course, in absence of independent report it's all just guesses.
We don't even know the most basic thing - whether RFDS is architectural >channel, like AMD's Zenbleed or timing sub-channel like Intel's
Downfall.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 11:26:32 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,994 |