Intelpocalypse


From the linked site:

More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).

In terms of Intel that means everything since the Pentium Pro, except those listed there. Your PowerPC classic mac should be safe, as should your 68k Amigas and STs. I'm not sure exactly when ARM introduced Out of Order execution, and whether that's all that's needed to exploit these bugs, but as far as I can tell nothing's been implemented for ARM yet.
 
Does this mean the Pyra will be slower too?
Cortex-A15

Yes (under review)

Yes

No

Yes​

What does this mean for performance? Dunno. I'm lookin at my omap4 and omap3 phones that wont get a kernel update for ages now...
 
Yes, that seems likely - but the Pandora should also be slowed down by a similar factor, as should all android. ARM's advice seems to be more that it should be fixed with compiler options, but presumably the debian arm people are looking at kernel fixes too. Either way, it's looking more like under 5% slower rather than 15-30% as previously speculated around the web.
 
I get the feeling this may hit performance in the short term due to rushed patches, but later on i'm guessing they will develop more effient patches to minimise performance impact
 
  • Like
Reactions: ___
yeah it looks like the expected 30% was an absolute worst case exaggeration. thanks for the link, this puts my mind at ease a bit.

all those android phones going unpatched for years to come...
 
interesting fact... Intel CEO dumps all stock to the abolute minimum of 250,000 shares TWO MONTHS ago......someone saw it coming

Everyone probably did that due to the tax change. In 2017 it was better to dump your stocks as it would be more expensive in 2018.
The CEO wouldn't just dump his stock when he feels like it, there a probably procedures,lawyers and forms he needs to pass before doing something like this.
 
I'd say these are the worst vulnerabilities ever, Spectre is a whole new class and pretty much unfixable in software (you can patch some specific cases it may target, but the attack surface is so large that's it's unfeasible to patch everything IMO). It can only be fully fixed with new hardware, but even that isn't clear how to do without ruining performance.

What does this mean for performance? Dunno. I'm lookin at my omap4 and omap3 phones that wont get a kernel update for ages now...
Well those are not affected by Meltdown and Spectre can't really be fixed, so I'd say there is nothing you can do anyway.

Also Cortex-A8 is in-order only with limited branch predictor, I'm kind of hoping it's not speculating ahead enough to be feasible for practical exploits, even when ARM listed A8 as affected. A8 is so old now that nobody will be interested in doing a PoC, so we might never know... I might not be patching pandora (and taking the performance penalty) until there is a working exploit.
 
Btw, someone made a proof-of-concept for Spectre on Linux :
github.com/Pl4gue/spectre-attack-demo

On my AMD Ryzen 5, i was able to confirm (to my dismay) that i was vulnerable to Spectre.

Also, strangely enough, no statements from OpenBSD on the matter, other than the fact that they may have fixed it 10 years ago.
Kinda unusual from them. Oh well
 
I get inline function api mismatches when trying to build it on my atom netbook running Arch linux on kernel 4.14.4 (I'm planning to do a big update once the patch it ready).

It built okay on my dual core E2220 server though, but when I run it it crashes saying 'Illegal instruction'. I get the same with the prebuilt 'spectre' binary they ship.

Looks like I'm protected from this version of the exploit, but largely by accident I think.
 
Spectre seems to be really bad. Sure the direct threat of Meltdown is bigger, but it has a fix (albeit costly in performance). Spectre basically invalidates a whole performance improvement strategy. Exploitable via javascript too... it almost makes activex sound like a good idea.
 
Back
Top