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
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thu, 14 Mar 2024 09:58:24 GMT
anton@mips.complang.tuwien.ac.at (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. There is a big chance that Silvermont is affected
too.
In practice, I'd guess that effect on Airmont/Silvermont is less severe,
because Future Register Files are smaller.

> 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

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.

I suppose, Intel feels really lucky that none of affected processors
supports SMT.

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". 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.

See how much NOT-HAVING a FP register file does for security-----You no longer
need a flag to decide to [re]load or not. and thus using it or not takes
exactly the same amount of time.

In addition to having HW reload all the files when touched (or earlier)!

With nothing deferred, there is no timing window to measure !!!

> 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 <already5chosen@yahoo.com> writes:
>On Thu, 14 Mar 2024 09:58:24 GMT
>anton@mips.complang.tuwien.ac.at (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
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thu, 14 Mar 2024 16:58:29 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Thu, 14 Mar 2024 09:58:24 GMT
> >anton@mips.complang.tuwien.ac.at (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).

> >> 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

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, probobly intentionally running at very low thread priority.

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.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>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".

Actually, looking at

<https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-0>

Meteor Lake with its Crestmont E-Core is listed as "Not Affected". My
impression was that Meteor Lake uses microarchitectures very similar
to Golden/Raptor Cove and Gracemont, so I find that surprising.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Thu, 14 Mar 2024 16:58:29 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> >On Thu, 14 Mar 2024 09:58:24 GMT
>> >anton@mips.complang.tuwien.ac.at (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).

I actually don't find any Silvermont or Airmont based CPU on
<https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-0>
so maybe Intel does not check whether they might be vulnerable, even
though, e.g., the Silvermont-based Atom E3805 is in the marketing
status "launched", not "discontinued" as many other Silvermont-based
CPUs
<https://ark.intel.com/content/www/us/en/ark/products/84311/intel-atom-processor-e3805-1m-cache-1-33-ghz.html>

>> >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.

And there is no indication that it cannot.

>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.

I don't see that every use of some secret key in a browser must be followed
by some context switch before returning control to JavaScript code.

>However my impression is that most dangerous attack scenario is
>that attacker examines stale registers immediately after woken up after
>preemption

That is covered by invoking VERW on context switch.

>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.

Exactly.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>