Meltdown, Spectre: The password theft bugs at the heart of Intel CPUs The severe design flaw in Intel microprocessors that allows sensitive data, such as passwords and crypto-keys, to be stolen from memory is real – and its details have been revealed. On Tuesday, we warned that a blueprint blunder in Intel's CPUs could allow applications, malware, and JavaScript running in web browsers, to …
I would be trying to make sure CPU designers "overlook" that problem deliberately. I mean all CPU vendors have plausible deniability since this could just as likely have been an accident.
It's just like UEFI or ME. It looks like simple stupidity, but it greatly benefits certain agencies.
[...] it greatly benefits certain agencies
Exactly that. Especially given that Intel and AMD are American, and ARM is British, but their chips are used globally. From an agency and gov point of view: What's not to like? I bet they are more upset that this has come to light than they ever were about the existence of those flaws.
I'd also be inclined to wager that there are more flaws like this in CPUs and other chips/hardware. It's no secret after all that the 5 Eyes would like to see backdoors and reversible encryption everywhere.
Lets face it, the underlying problem is the "need for speed" and the resulting mismatch between the CPU core at ~3GHz and main memory in the ~1GHz and below range. So lets throw hardware at it, millions and billions of transistors to try and play God/quantum by plying out all possible paths within the instruction pipeline.
And they got it wrong. Not massively so in normal terms, but they did not design based on the assumption of bad actors abusing this. Because no one bought hardware that was slow and secure, at least, not the majority of PC gamers or business managers chasing the ever-bloating OS and web browser problems. Make it fast, make it now. Ship it when its half-baked and if we get too many problems then put out a microcode update which users may (or probably not, given the shittyness of many motherboard makers) apply.
Sorry, but in most cases like this it is simple "incompetence" for not really planning high security from the original start because that is not what the boss will get bonuses for.
"... they did not design based on the assumption of bad actors abusing this."
I agree. For illustration, have a look at this Intel manual page from 1986, explaining why CPU-enforced sandboxing was introduced: the focus was entirely on detecting, and confining the damage of, "bugs". I think this is understandable because malware wasn't such an issue back then, but it has been obvious for a long time now that Protected Mode is a critical security defence, not just a stability feature, and there is no excuse for holes in its sandboxes in recent CPUs.
'Trusted Computing' Model 2.0'...
"....."The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility," (EFF)..."
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
OK - as a home user, here's a couple of data points for you to consider.
MS have issued the patch for Windows 10. which takes you from build .125 up to build.192.
I ran a handbrake video conversion before and after and also ran the passmark test before and after. This was on my I7-3770.
Handbrake. Before: average FPS 168. Time taken - 18mins.
Handbrake. After: average FPS 167.5. Time taken 18 mins 20 seconds.
Passmark. Before After
Total 3219.7 3228.7
CPU 8214 8224
2D 557 561
3D 3585 3605
Mem 1752 1758
Disk 2444 2409
So, the only thing that seems to have suffered is disk I/O and that by around 1.5%
YMMV - this is just what I found.
"the 30% that has been bandied about." needs to specify the workload used for the performance measurement. My recollection is that it was one of the SPEC benchmarks. If it matters, you can find it, the truth is out there somewhere. Use the source, always use the source.
Seems Theo was looking at this a decade ago so I guess OpenBSD is already okay.
"Seems Theo was looking at this a decade ago so I guess OpenBSD is already okay."
AFAICT those OpenBSD fixes related to an unpublished change w.r.t bits of page table being cached when previously they were not. I think it would be dangerous to assume those fixes also cover Meltdown.
The points Theo made about the errata preventing people from implementing secure software remain valid.
As I've said before folks really should look at the errata before purchasing a CPU - it is shocking just how broken some of them really are. That won't always help though - case in point try tracking down all the errata that Theo talked about (eg: AI90) 10 years ago... You may well struggle - because Intel's policy is to unpublish errata after they've made a fix/spec change... If anyone does find those errata - let me know. ;)
As it turns out (and in fairness to Intel) I did actually find the Core 2 Duo errata Theo referred to back in 2007 after a bit more fiddling around with search criteria...
http://download.intel.com/design/processor/specupdt/313279.pdf
The closest issues to Meltdown that I found (maybe someone smarter can find more) were AI56, AI91 and AI99:
AI56 "Update of Read/Write (R/W) or User/Supervisor (U/S) or Present (P) Bits without TLB Shootdown May Cause Unexpected Processor Behavior"
AI91 "Update of Attribute Bits on Page Directories without Immediate TLB Shootdown May Cause Unexpected Processor Behavior"
AI99 "Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF"
There are probably places where the first two generations of Alpha-architecture chips (e.g. EV4 aka 21064 and EV5 aka 21164, and so on) are still available. They didn't have speculative/OoO execution; Alpha only got speculative execution in the EV6/21264 chips.
At a complete guess...
I'd assume if you set part of the computation to CPU core 1, and part to 2, with the requirement of 1 to compute before 2, but allow it to pre-fetch the data (as in Meltdown). But this time you adjust that code, then execute with core 2.
If the CPU has to write to memory to pass from core 1 to core 2, it could allow you to arbitrarily set any code, by arbitrarily setting something into pre-fetch, knowing no checks will be done on the pre-fetched data!?
Good question. Core 2 cannot see core 1's L2, so does the OoO write on core 1 cause the written data to propagate to L3 to maintain cache coherency? Otherwise, the OoO write never makes it past core 1's L2 and core 2 then loads it's L2 with the original copy from L3 and so never sees core 1's abandoned write.
The Faily Fail will no doubt have a sensationalist article along the lines of "your data is about to be stolen and everyone's ID will be stolen and everyone's bank accounts will be emptied computer armageddon horror" followed by some useful advice along the lines of "Don't use your computer or phone and keep a lookout for immigrants trying to steal your data".
actually is roughly four column inches of inevitably-oversimplified description which seems to come largely from ex-Sophos bloggist Graham Clueless and ends by crediting TheRegister for discovering this particular fail.
(I read the Daily Mail at my neighbour's, honest).
Maybe scripts on webpages.
Mozilla managed to make Firefox 57 incompatible with Noscript (they made it hard for devs to migrate by NOT documenting API and releasing versions to devs first). Now they updated Firefox 52ESR (52.5.3) to break every plug-in. Got all working again except noscript.
So I have installed uMatrix on Firefox as a script blocker. It also uses a database of evil tracking and malware domains. So good.
Iceweasel now simply installs Firefox 52.5.3, so no good. Palemoon seems too much like a beta.
I have Classic Theme restorer. Mozilla, if I wanted something like Google Chrome, I'd install Chromium.
So yet again, the scary zero days are NOT beaten by AV systems (that often slow or break Windows), but by no remote content in email (I use a client for POP3 & IMAP), not opening attachments you shouldn't and Script blocking (White listing, blacklisting and blocking entire 3rd party domains).
"Interface is not as nice as the previous verison, but it does work."
The interface is genuinely terrible -- it "guesses" what scripts to allow if you don't have a rule, and doesn't inform you about them in the icon (i.e., no partial "no" symbol over the "S" as in the old version of Noscript).
On the other hand, the old version of Noscript does work on Firefox 52.5.3, contrary to what Mage has stated.
(I'm using the 64-bit version, in case that's a factor.)
>>This is, essentially, a mega-gaffe by the semiconductor industry.
This is a bit rich I feel.
It has taken the world a *decade* to find this on what are the two most popular architectures (x86, ARM) which are open on the details of the involved HW (out of necessity for SW use).
The number of technical people and engineers who have seen this is not insignificant over that decade.
Yet it has taken so long to identify it.
Hindsight might be 20/20, but to call this an obvious gaffe is contrary to a decade of evidence.
Well for it to be gaffe it should be an embarrassing mistake, a mistake made rarely/by a few.
For it to be a "mega-gaffe", it would have to be a obvious oversight, made by no-one and blindingly obvious.
So I see a mega-gaffe as a mistake made on the very obvious. And obvious this isn't.
I mean what is "mega-gaffe" about it? "Mega-gaffes" don't take a decade to find which is my point.
"don't forget your routers, raspberry's, and all that wonderful IoT stuff many are based on (Broadcom) ARM Architecture"
ARM's site lists the affected processors. AFAICS Pis aren't amongst those affected. As per a previous comment about stuff you control - the embedded processors shouldn't be exposed to random stuff off the net.
is how, given that this is the result of a flaw at the level of the chip design, how it can affect chips with different architectures. Even if all these chips have speculative execution, surely the in silico implementation must be quite different for the different chips?
I'm no expert at all, but the example exploit relies on using speculative execution to bring out of bounds data into the cache, then hit the cache to get that data... The basic flaw, which as I understand it is that boundary checking can be bypassed through speculative execution then picked out of the cache, seems to be architecture independent as everyone has taken the same approach!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
