https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

So, is there a way to fix this while maintaining the feature's
performance advantage?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld wrote:

> https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

> So, is there a way to fix this while maintaining the feature's
> performance advantage?

They COULD start by not putting prefetched data into the cache
until after the predicting instruction retires. {{I have a note
from about 20 months ago where this feature was publicized and
the note indicates a potential side-channel.}}

An alternative is to notice that [*]cryption instructions are
being processed and turn DMP off during those intervals of time.
{Or both}.

Principle:: an Architecturally visible unit of data can only become
visible after the causing instruction retires. A high precision timer
makes cache line [dis]placement visible; so either take away the HPT
or don't alter cache visible state too early.

And we are off to the races, again.....

On Sun, 24 Mar 2024 10:40:18 -0700, Stephen Fuld wrote:

> So, is there a way to fix this while maintaining the feature's
> performance advantage?

Even if it’s fixed, how does that help existing users with broken
machines?

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

It's Groundhog Day, all over again!

> So, is there a way to fix this while maintaining the feature's
> performance advantage?

From what is written in the article, nothing is currently known.

For new silicon, people could finally implement Mitch's suggestion
of not committing speculative state before the instruction retires.
(It would be interesting to see how much area and power this
would cost with the hundreds of instructions in flight with
modern micro-architectures).

For existing silicon - run crypto on efficiency cores, or just
make sure not to run untrusted code on your machine :-(

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

That's a pretty bad article, but at least one can read it without
JavaScript, unlike the web page of the vulnerability
<https://gofetch.fail/>.

Classically hardware prefetchers have based their predictions on the
addresses of earlier accesses. If they base their predictions only on
architectural accesses and (by coding the cryptographic code
appropriately) don't have information about the secrets in the
addresses, the prefetcher cannot reveal these secrets through a side
channel. Cryptographic code has been written that way for quite a
while.

These prefetchers are not so great on pointer-chasing code (unless the
data happens to be allocated at regular distances), so apparently
Apple engineers, and according to this article also Intel engineers
added a prefetcher that prefetches based on the contents of data that
it fetches. To anyone who knows how a cache side-channel works, it is
crystal-clear that this makes it possible to reveal the *contents* of
accessed memory through a cache side channel. Even if only
architectural accesses are used for that prediction, the possibility
is still there, because cryptographic code has to access the secrets.

This should be clear to anyone who understands Spectre and actually
anyone who understands classical (architectural) side-channel attacks;
but it should have been on the minds of the hardware designers very
much since Spectre has been discovered.

The contribution of the GoFetch researchers is that they demonstrate
that this is not just a theoretical possibility.

If Intel added this vulnerability in Raptor Lake (as the article
states), they have to take the full blame. On the positive side, the
GoFetch researchers have not found a way to exploit Raptor Lake's
data-dependent prefetcher. Yet. But I would not bet on there not
being a way to exploit this.

Apple's designers at least have the excuse that at the time when they
laid the groundwork for the M1, Spectre was not known, and when it
became known, it was too late to eliminate this prefetcher from the
design (but not too late to disable it through a chicken bit).

>So, is there a way to fix this while maintaining the feature's
>performance advantage?

What is the performance advantage? People who have tried to use
software prefetching have often been disappointed by the results. I
expect that a data-dependent prefetcher will usually not be
beneficial, either. There will be a few cases where it may help, but
the average performance advantage will be small.

On the GoFetch web page the researchers suggest using the chicken bit
in the cryptographic library. I would not be surprised if there was a
combination of speculation and data-dependent prefetching, or of
address-dependent prefetching and data-dependent prefetching that
allows all code (not just cryptographic code) to perform
data-dependent prefetches based on the secret data that only crypto
code accesses architecturally. But whether that's the case depends on
the hardware design; plus, if speculative accesses from other codes to
this data are possible, the data can usually be revealed through a
speculative load even in the absence of a data-dependent prefetcher
(but there may be software mitigations for that scenario that the
data-dependent prefetcher would circumvent).

The web page also mentions "input blinding". I wonder how that can be
made to work reliably. If the attacker has access to all the loaded
data (through GoFetch) and knows how the blinded data is processed,
the attacker can do everything that the crypto code can do,
e.g. create a session key. Of course, if the attacker has to
reconstruct the key from several pieces of data, the attack becomes
more difficult, but relying on it being too difficult has not been a
recipe for success in the past (e.g., before Bernstein's cache timing
attack on AES it was thought to be too difficult to exploint).

So what other solutions might there be? The results of the
data-dependent prefetches could be loaded into a special cache so that
they don't evict entries of other caches. If a load architecturally
accesses this data, it is transferred to the regular cache. That
special cache should be fully associative, to avoid revealing bits of
the addresse of other accesses (i.e., data) through the accessed set.
That leaves the possibility of revealing something by evicting
something from this special cache just based on capacity, but I don't
see how that could be exploited.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>For existing silicon - run crypto on efficiency cores

Not the recent vulnerability that affects Intel's efficiency cores.
Also, if the prefetcher works with data in a shared cache (I don't
know whether the data-dependent prefetchers do that), it may not
matter on which core the code runs.

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

On Mon, 25 Mar 2024 06:37:31 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> > https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/
> >
>
> It's Groundhog Day, all over again!
>
> > So, is there a way to fix this while maintaining the feature's
> > performance advantage?
>
> From what is written in the article, nothing is currently known.
>
> For new silicon, people could finally implement Mitch's suggestion
> of not committing speculative state before the instruction retires.
> (It would be interesting to see how much area and power this
> would cost with the hundreds of instructions in flight with
> modern micro-architectures).
>
> For existing silicon - run crypto on efficiency cores, or just
> make sure not to run untrusted code on your machine :-(

I would trust your second solution better than the first one.

On Sun, 24 Mar 2024 10:40:18 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

>So, is there a way to fix this while maintaining the feature's
>performance advantage?

While the article was pessimistic about fixing it by a microcode fix
that could be downloaded, the description didn't suggest to me that it
would be hard to correct it in future designs. Maybe my memory is
faulty.

John Savard

On Mon, 25 Mar 2024 07:26:35 -0600
John Savard <quadibloc@servername.invalid> wrote:

> On Sun, 24 Mar 2024 10:40:18 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
> >https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/
> >
>
> >So, is there a way to fix this while maintaining the feature's
> >performance advantage?
>
> While the article was pessimistic about fixing it by a microcode fix
> that could be downloaded, the description didn't suggest to me that it
> would be hard to correct it in future designs. Maybe my memory is
> faulty.
>
> John Savard

The description suggests that it wouldn't be hard to correct by
introduction of new mode bit that can be turned on and off by cryto
libraries.
That is not going to help existing binaries.

Now, personally I don't believe that for single-user platform like Mac
the threat is even remotely real and that any fix is needed. And I am
not even an Apple fanboy, more like a mild hater.

> Principle:: an Architecturally visible unit of data can only become
> visible after the causing instruction retires. A high precision timer
> makes cache line [dis]placement visible; so either take away the HPT
> or don't alter cache visible state too early.

And parallelism (e.g. multicores) can be used to emulate HPT, so "take
away the HPT" is not really an option.

Stefan

>> So, is there a way to fix this while maintaining the feature's
>> performance advantage?
> Even if it’s fixed, how does that help existing users with broken
> machines?

Of course, the current computing world loves it even more if it pushes
users to buy new machines.

This said, until now manufacturers don't seem to consider side-channel
attacks as something worth spending much effort to avoid, so I'd expect
future machines to be just as vulnerable :-(

Stefan

On 3/24/2024 2:47 PM, Lawrence D'Oliveiro wrote:
> On Sun, 24 Mar 2024 10:40:18 -0700, Stephen Fuld wrote:
>
>> So, is there a way to fix this while maintaining the feature's
>> performance advantage?
>
> Even if it’s fixed, how does that help existing users with broken
> machines?

The article gives several suggestions, but they all come at a
performance cost, and require some, presumably small, changes to crypto
code.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Thomas Koenig <tkoenig@netcologne.de> writes:
>Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/
>
>It's Groundhog Day, all over again!
>
>> So, is there a way to fix this while maintaining the feature's
>> performance advantage?
>
>From what is written in the article, nothing is currently known.
>
>For new silicon, people could finally implement Mitch's suggestion
>of not committing speculative state before the instruction retires.

To be fair, that's been suggested for quite a few years by
various semiconductor designers. The difficulties lie in
efficient implementation thereof.

>(It would be interesting to see how much area and power this
>would cost with the hundreds of instructions in flight with
>modern micro-architectures).

Yes.

>
>For existing silicon - run crypto on efficiency cores, or just
>make sure not to run untrusted code on your machine :-(

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Thomas Koenig <tkoenig@netcologne.de> writes:
>>For existing silicon - run crypto on efficiency cores
>
>Not the recent vulnerability that affects Intel's efficiency cores.
>Also, if the prefetcher works with data in a shared cache (I don't
>know whether the data-dependent prefetchers do that), it may not
>matter on which core the code runs.

Run it in non-cacheable memory. Slow but safe.

On Mon, 25 Mar 2024 09:50:28 -0700, Stephen Fuld wrote:

> On 3/24/2024 2:47 PM, Lawrence D'Oliveiro wrote:
>
>> Even if it’s fixed, how does that help existing users with broken
>> machines?
>
> The article gives several suggestions, but they all come at a
> performance cost ...

The basic problem is that building all this complex, bug-prone
functionality into monolithic, nonupgradeable hardware is not really a
good idea.

Lawrence D'Oliveiro wrote:

> On Mon, 25 Mar 2024 09:50:28 -0700, Stephen Fuld wrote:

>> On 3/24/2024 2:47 PM, Lawrence D'Oliveiro wrote:
>>
>>> Even if it’s fixed, how does that help existing users with broken
>>> machines?
>>
>> The article gives several suggestions, but they all come at a
>> performance cost ...

> The basic problem is that building all this complex, bug-prone
> functionality into monolithic, nonupgradeable hardware is not really a
> good idea.

Would you like to inform us of how it can be done otherwise ?

On Mon, 25 Mar 2024 21:22:35 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Mon, 25 Mar 2024 09:50:28 -0700, Stephen Fuld wrote:
>
> > On 3/24/2024 2:47 PM, Lawrence D'Oliveiro wrote:
> >
> >> Even if it’s fixed, how does that help existing users with broken
> >> machines?
> >
> > The article gives several suggestions, but they all come at a
> > performance cost ...
>
> The basic problem is that building all this complex, bug-prone
> functionality into monolithic, nonupgradeable hardware is not really
> a good idea.

May be, not a good idea. But the best.

On Mon, 25 Mar 2024 22:17:55 +0000, MitchAlsup1 wrote:

> Lawrence D'Oliveiro wrote:
>
>> The basic problem is that building all this complex, bug-prone
>> functionality into monolithic, nonupgradeable hardware is not really a
>> good idea.
>
> Would you like to inform us of how it can be done otherwise ?

Upgradeable firmware/software, of course.

On Mon, 25 Mar 2024 15:53:06 +0200, Michael S wrote:

> Now, personally I don't believe that for single-user platform like Mac
> the threat is even remotely real and that any fix is needed.

It could be exploited via, for example, some future web browser or other
app vulnerability.

Remember Schneier’s dictum: attacks only ever get worse, they never get
better.

On Mon, 25 Mar 2024 17:07:16 GMT, Scott Lurndal wrote:

> Run it in non-cacheable memory. Slow but safe.

But 99% of the performance speedups of the last 20-30 years have involved
caching of some kind.

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Also, if the prefetcher works with data in a shared cache (I don't
>>know whether the data-dependent prefetchers do that), it may not
>>matter on which core the code runs.
>
>Run it in non-cacheable memory. Slow but safe.

To eliminate this particular vulnerability, it's sufficient to disable
the data-dependent prefetcher.

I wonder where these ideas are coming from that call for the worst
possible fix for a vulnerability?

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 25 Mar 2024 17:07:16 GMT, Scott Lurndal wrote:
>
>> Run it in non-cacheable memory. Slow but safe.
>
>But 99% of the performance speedups of the last 20-30 years have involved
>caching of some kind.

So what? Running the crypto algorithms (when not offloaded to
on-chip accelerators) using non-cacheable memory as a workaround
until the hardware issues are ameliorated doesn't imply that
all other code needs to run non-cachable.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Also, if the prefetcher works with data in a shared cache (I don't
>>>know whether the data-dependent prefetchers do that), it may not
>>>matter on which core the code runs.
>>
>>Run it in non-cacheable memory. Slow but safe.
>
>To eliminate this particular vulnerability, it's sufficient to disable
>the data-dependent prefetcher.

That assumes that chicken bit(s) are available to do that.

On Mon, 25 Mar 2024 07:25:34 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
> >https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/
> >
>
> That's a pretty bad article, but at least one can read it without
> JavaScript, unlike the web page of the vulnerability
> <https://gofetch.fail/>.
>

In case you missed it, the web page contains link to pdf:
https://gofetch.fail/files/gofetch.pdf

scott@slp53.sl.home (Scott Lurndal) writes:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Mon, 25 Mar 2024 17:07:16 GMT, Scott Lurndal wrote:
>>
>>> Run it in non-cacheable memory. Slow but safe.
....
>Running the crypto algorithms (when not offloaded to
>on-chip accelerators) using non-cacheable memory as a workaround
>until the hardware issues are ameliorated doesn't imply that
>all other code needs to run non-cachable.

Then your crypto code is slow and unsafe. The attacker will use the
rest of the application to extract the crypto keys, whether through
the cache side-channel of Spectre, or a prefetcher-based side channel.

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