.... also on Apple Silicon. Just saw this on comp.risks...

https://ileakage.com/

"We present iLeakage, a transient execution side channel targeting
the Safari web browser present on Macs, iPads and iPhones. iLeakage
shows that the Spectre attack is still relevant and exploitable,
even after nearly 6 years of effort to mitigate it since its
discovery. We show how an attacker can induce Safari to render an
arbitrary webpage, subsequently recovering sensitive information
present within it using speculative execution. In particular,
we demonstrate how Safari allows a malicious webpage to recover
secrets from popular high-value targets, such as Gmail inbox
content. Finally, we demonstrate the recovery of passwords, in
case these are autofilled by credential managers."

They also link to a paper describing their exploit.

What this illustrates is that the fundamental flaw µArchitects are
not allowed to make is that of "flying blind"--that is make a prediction
and believe that prediction until made aware of its incorrectness. Spectré
illustrated that any "flying blind" opens up a covert channel and if one
can touch some µArchitectural state while "flying blind" you can exploit
this to extract data you should have been prevented from seeing.

Apple wanted performance, high performance requires lots of predictors,
predictors mean you are effectively flying blind--and the circle of
bad µArchitecture continues.

Neither the 1-wide not the 6-wide My 66000 µArchitectures are sensitive
to these kinds of attacks, and I don't think I have lost a single Iota
of performance getting there. ...

mitchalsup@aol.com (MitchAlsup) writes:
>What this illustrates is that the fundamental flaw �Architects are
>not allowed to make is that of "flying blind"--that is make a prediction
>and believe that prediction until made aware of its incorrectness. Spectr�
>illustrated that any "flying blind" opens up a covert channel and if one
>can touch some �Architectural state while "flying blind" you can exploit
>this to extract data you should have been prevented from seeing.
>
>Apple wanted performance, high performance requires lots of predictors,
>predictors mean you are effectively flying blind--and the circle of
>bad �Architecture continues.

As we (in particular, including you) have worked out soon after
Spectre was revealed to the public, you can fix (not mitigate) Spectre
by not exposing speculative microarchitectural changes to other
threads or cores, and throwing them away when the speculation turns
out to be incorrect. We know that this can be done because it is just
the same thing that has been done for architectural changes since
1995. We also need to make sure that resources are not speculatively
occupied in a way that can be perceived by other threads or cores.

>Neither the 1-wide not the 6-wide My 66000 �Architectures are sensitive
>to these kinds of attacks, and I don't think I have lost a single Iota
>of performance getting there. ...

As you note yourself: "high performance requires [...] predictors".
So if you use prediction, do you make it Spectre-proof? And if you
don't use prediction, how do you get performance?

While it's possible to get performance for throughput code (like
matrix multiply) without prediction, for other code (e.g., most
SpecInt stuff, or our LaTeX benchmark) you lose a lot of performance
if you don't have speculation.

E.g., Ultimate Speculative Load Hardening (which eliminates most, but
not all speculation) is reported as having a slowdown by a factor of
2.5 on SPECint programs (pretty little variation between them).

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

Anton Ertl wrote:

> mitchalsup@aol.com (MitchAlsup) writes:
>>What this illustrates is that the fundamental flaw �Architects are
>>not allowed to make is that of "flying blind"--that is make a prediction
>>and believe that prediction until made aware of its incorrectness. Spectr�
>>illustrated that any "flying blind" opens up a covert channel and if one
>>can touch some �Architectural state while "flying blind" you can exploit
>>this to extract data you should have been prevented from seeing.
>>
>>Apple wanted performance, high performance requires lots of predictors,
>>predictors mean you are effectively flying blind--and the circle of
>>bad �Architecture continues.

> As we (in particular, including you) have worked out soon after
> Spectre was revealed to the public, you can fix (not mitigate) Spectre
> by not exposing speculative microarchitectural changes to other
> threads or cores, and throwing them away when the speculation turns
> out to be incorrect. We know that this can be done because it is just
> the same thing that has been done for architectural changes since
> 1995. We also need to make sure that resources are not speculatively
> occupied in a way that can be perceived by other threads or cores.

>>Neither the 1-wide not the 6-wide My 66000 �Architectures are sensitive
>>to these kinds of attacks, and I don't think I have lost a single Iota
>>of performance getting there. ...

> As you note yourself: "high performance requires [...] predictors".
> So if you use prediction, do you make it Spectre-proof? And if you
> don't use prediction, how do you get performance?

> While it's possible to get performance for throughput code (like
> matrix multiply) without prediction, for other code (e.g., most
> SpecInt stuff, or our LaTeX benchmark) you lose a lot of performance
> if you don't have speculation.
<
It is not that the 6-wide does not have speculation (predictors), but
that µArchitecture state is not updated until the causing instruction
retires. This requires speculation buffers for the predictors which is
accessible to the fetch-insert part of the pipeline, but if one backs
up (for any reason) the buffered speculations younger than the recovery
point are not used and are certainly no0t written into the long-term
predictor store. ST-to-LD forwarding is simply defined to be such a
predictor.
<
> E.g., Ultimate Speculative Load Hardening (which eliminates most, but
> not all speculation) is reported as having a slowdown by a factor of
> 2.5 on SPECint programs (pretty little variation between them).
<
Yes, that is why you don't do it that way.
<
The only time My 66000 takes a stall on this stuff is when the predictor
runs out of speculation state. Memory references (to recover TSO) has
48 potentially outstanding references, branch/call/switch/return has 16.
<
> - anton