Talos Secure Workstation

[ClassicHasClass]

Talos is definitely susceptible to Spectre or something like it, though the attack would need to take into account any of the microarchitectural oddities of later Power ISA. But after some late night work on the datasheets, my opinion is that due to unusual limitations on speculative execution of indirect branches, earlier PowerPC chips such as the G3 and G4 may not be as vulnerable. I posted my analysis here: https://tenfourfox.blogspot.com/2018/01 ... r-why.html

There is still no evidence I've seen that Power ISA is subject to Meltdown-type attacks, though it looks like one type of ARM Cortex core is as well.

Bottom line, I'd still feel safer on one than on an Intel-based workstation.

[Raion-Fox]

As usual Classic's blog posts are informative, talk to instead of at the viewer and give me confidence in what he writes.

One question I do have is if in-order POWER architecture versions, such as POWER6, have this vulnerability. If you have some time, Classic, I'd appreciate it. I suspect that since branch prediction is still a thing on P6 that yes, but the in-order operations complicates things. A lot.

[GRudolf94]

As far as my quasi-layman, noobish understanding goes, the exploit relies on the fact that BP speculation behavior can be known/predicted (that's a recursion!)

With in-order execution, there are no predictions to be made, and as such, no vulnerability.

Am I right or did I go wrong somewhere?

[ClassicHasClass]

Unfortunately in-order CPUs can still speculate on execution; the difference is in how they issue instructions, which can be done speculatively or not, so the POWER6 is probably in the same risk category as the G5.

Interestingly, the RPi cores don't speculate per Eben, so they're immune completely.

[bifo]

Unfortunately in-order CPUs can still speculate on execution; the difference is in how they issue instructions, which can be done speculatively or not, so the POWER6 is probably in the same risk category as the G5.

Interestingly, the RPi cores don't speculate per Eben, so they're immune completely.

Doesnt the power6 in the talos allow alterations to the microcode, or am i thinking of a different machine?

[Raion-Fox]

The Talos uses Power9, Bifo.

[GRudolf94]

Unfortunately in-order CPUs can still speculate on execution; the difference is in how they issue instructions, which can be done speculatively or not, so the POWER6 is probably in the same risk category as the G5.

Interesting, thanks for the clarification

Interestingly, the RPi cores don't speculate per Eben, so they're immune completely.

Spectre-vulnerable ARM cores

This here lists the ARM cores affected, neither the ARMv6 in the first RPI, neither the Cortex-A7 or -A53 of gens 2 and 3 appear on the table. Guess I'll be using my original model B RPi to access web banking services

[ClassicHasClass]

IBM will issue firmware updates for at least the POWER7+ forward. My bet is these disable speculative execution of indirect branches.

https://www.ibm.com/blogs/psirt/potenti ... er-family/

[GRudolf94]

My bet is these disable speculative execution of indirect branches.

Of course that, for some niches, security is way more important than raw speed. However, do you have any idea on what the performance impact would be if they forced the BP to never take branches?

Also, I was translating the original Project Zero document into Portuguese to gain some insight on the flaw and to satisfy a friend's curiosity. Reading about variants 1 and 2 of the exploit, I became curious. Don't know if you can answer all that, but you're clearly better educated than me on how code executes at machine level.

How tough of a job do you think it'd be to modify the branch predictor and cache behaviors to avoid exploits like these (if even feasible without fundamental changes in how code executes)? Is that even feasible to do on a single silicon stepping without a major redesign of other parts of the CPU core, or a major change to the architecture itself? All speculative-executing CPUs are theoretically vulnerable due to how the machine operates while a mispredicted code execution is happening, right?

More questions appeared, but I don't remember them all. Thanks for your knowledge

[ClassicHasClass]

It's not that the BP can't take fixed branches, just indirect ones (where the CPU can branch to the contents of a register). The crux with Spectre, in short, is that if the attacker can get some control of the register in question or can get the CPU to speculatively execute a code path that sets that register to a known block of code, then they can accurately predict how the processor will continue to speculate and then use the cache timing attacks to leak data. Indirect branches on Power ISA were never very quick; that's why the G5, for example, has special hardware -- in this case a dedicated rename mapper -- for the only two registers that allow them. I believe this mapper is still in current designs and that's probably what the patches will disable in microcode. It will impact performance and it won't be negligible, but it's probably not going to be massive.

I was able to confirm the POWER6 is vulnerable with the Spectre PoC, but I can't get the G3 or 7400 to leak data, so those processors at least so far seem resistant. More on that, including a link to a PPC version of the Spectre PoC: https://tenfourfox.blogspot.com/2018/01 ... re-on.html

[robespierre]

Interesting. I have a DLSD running 10.4.11, do you have a zip of the binary?

[ClassicHasClass]

Sure. The attached zip contains the generic PPC, 750, 7400 and 7450 binaries at all four optimization levels so you can reproduce the test. How fast is your DLSD? Is it an A1139 (mine is)?

[robespierre]

It's an A1138.
Here are the results from 10.4.11 on a PPC7447A:

Code: Select all

-arch ppc -O0: 16 bytes wrong in 3.58 sec
-arch ppc -O1: 17 bytes wrong in 2.62 sec
-arch ppc -O2: 17 bytes wrong in 2.59 sec
-arch ppc -O3: 13 bytes wrong in 2.60 sec

-arch ppc750 -O0: 16 bytes wrong in 2.64 sec
-arch ppc750 -O1: 28 bytes wrong in 2.62 sec
-arch ppc750 -O2: 20 bytes wrong in 2.60 sec
-arch ppc750 -O3: 15 bytes wrong in 2.59 sec

-arch ppc7400 -O0: 15 bytes wrong in 3.54 sec
-arch ppc7400 -O1: 17 bytes wrong in 2.62 sec
-arch ppc7400 -O2: 14 bytes wrong in 2.60 sec
-arch ppc7400 -O3: 24 bytes wrong in 2.60 sec

-arch ppc7450 -O0: 17 bytes wrong in 3.56 sec
-arch ppc7450 -O1: 29 bytes wrong in 2.62 sec
-arch ppc7450 -O2: 13 bytes wrong in 2.61 sec
-arch ppc7450 -O3: 23 bytes wrong in 2.66 sec

All bytes for all tests are reported as "Unclear", whether right or wrong. The architecture and optimization level does not seem to have any effect on how much of the data is read correctly, and it appears pretty much random. I ran all the tests SUID to nobody, using a csh script:

Code: Select all

foreach p (./spectre{,G3-,7400-,7450-}O[0-3])
echo; echo Timing attack $p ::; echo
time $p
end

and ran them using "source timeattacks > results". It's possible that the various tests were affected by the cache being hot from preceding tests; I ran the suite of tests once before from battery power and it was getting more bytes wrong.

[ClassicHasClass]

Thanks for the data. My conclusion from that is that the DLSDs' power management does indeed foul the attack. The hot cache turned up a bit in a couple other people's testing, but I can't really find any reliable pattern about what level of cache priming is necessary.

[jirka]

The attached zip contains the generic PPC

Tried on my iMac G5 (1st model, OS 10.4). On the full speed it says "Success" for -O0 and "Unclear" for all other -O[1-3]. But all bytes are correctly recovered. On the reduced speed the results ("Unclear" vs "Success") are inverted (only for -O0 it says "Unclear"). But all bytes are correctly recovered, too.