Slashdot Mirror
Intel Says 'Partitions' in New Chips Will Correct the Design Flaw that Created Spectre and Meltdown (geekwire.com)
Intel said on Thursday it is introducing hardware protections against the Spectre CPU flaw that was discovered last year. From a report: Starting with the Cascade Lake version of its Xeon server processors later this year, Intel will incorporate "protective walls" in its hardware that prevent malicious hackers from using speculative execution techniques to steal private information from the secure part of the processor. These fixes will also ship with the PC version of the Cascade Lake chips, but the tech industry has been much more concerned about the effect of these design flaws on server processors running in data centers and cloud vendors.
The new fixes allow Intel to still benefit from the performance advantages of speculative execution -- in which a processor guesses which upcoming instructions it will need to execute in order to speed things up -- without the security risks. The hardware changes address Variants 2 and 3 of the Spectre and Meltdown issues first disclosed in early January, and software fixes should continue to address Variant 1, Intel said.
The new fixes allow Intel to still benefit from the performance advantages of speculative execution -- in which a processor guesses which upcoming instructions it will need to execute in order to speed things up -- without the security risks. The hardware changes address Variants 2 and 3 of the Spectre and Meltdown issues first disclosed in early January, and software fixes should continue to address Variant 1, Intel said.
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
me_cleaner: Set HAP AltMeDisable bit with -S option
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could ga
Intel will incorporate "protective walls" in its hardware ...
Big, beautiful walls and Intel will get AMD to pay for them. :-)
It must have been something you assimilated. . . .
Where are the weaponized exploits that were going to sweep the internet and the zillion-unpatched-windows hordes? *YAWN* Again, I've gotta kick the news habit. What a hyperventilating waste of time this has been watching IT news and vendors nearly faint.
Whats good for AMD is good for Intel eh CTS labs?
Intel has already failed at exactly that before :
IntelME was supposed to be exactly that: a separated isolated ARC core in the chipset, that was used to handle administrative tasks even if the main x86 CPU was shutdown (IntelAMT - Intel own NIH syndrom "lights out management" vaguely similar to IPMI). Got further repurposed for some trusted security tasks (TPM), got further repurposed for DRM related task, used also for critical steps to bring the hardware up.
And was the target of attacks and exploits last summer. Attacks that thus work EVEN when the main x86 CPU is turned off (remembre, before the overarching list of roles, it began as an IPMI-like solution). To the point that vendors like DELL started offering new BIOS/UEFI firmware, in which the Intel ME code was stripped to the bare strict minimum for just the "bring hardware up" part.
But I'm sure *this time around* the walled secure CPU core that Intel promise will be flawless and never exploited~~
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Please, please please Intel, provide a mechanism to COMPLETELY disable the IME BackDoor in your CPUs ( https://en.wikipedia.org/wiki/Intel_Management_Engine/ )
AMD has its bugs, but one new feature that they have implemented is RAM encryption. This way, one VM has no way of obtaining content from another VM's RAM space, should a leak be possible. Why not be proactive in dealing with virtualization and keeping stuff separate, perhaps adding some pipeline randomization to foil side channel attacks?
Intel knows what they are doing. Might as well be ahead of the curve and add some useful security features.
what's wrong with "check for permissions in the pipeline before doing a speculative memory access"
Partitions inside Intel CPUs? How often will we have to re-format the damn things?
#DeleteFacebook
No, these are rather small modifications to existing designs: moving protection checks earlier (for meltdown) to prevent speculative execution past a guaranteed exception is not a complete redesign.
The protection bits are in the TLB entry, that you need to look up for address translation anyway, and then they may be checked in parallel with the cache access. Compared to looking up the tags for an 8-way (or 4, can't remember) cache access, checking the protection is simple.
Recent chips have 57 virtual address bits of which only the 12 lower go without translation, the TLB is at least 4 way set associative, so this means that you need 4 45 bit comparators to select the TLB entry. Once translated, the L1 cache lines are 64 or 128 bytes on a physical address range of 46 bits, so this means that the cache tags are 39 or 40 bit wide (some AMD CPUs even allow a larger physical address space).
Therefore, for the address translation and cache tags matching, you end up with at least 8 comparators about 40 bits wide each, more if the associativity is higher.
Well, the protection bits in the TLB and the current privilege levels altogether are less then 8 bits (2 for the current privilege level, 3 or 4 for protection in the TLB entry).
Completely negligible in terms of silicon area. Of course the logic has to be able to say: stop here, but it already needs to take into account the case of a TLB miss, and of a cache miss. It's probably not that hard to change the logic to treat a protection violation as a TLB miss, except that all that logic in Intel's core dates back to the PentiumPro...
Not between Intel before and after the patches but Intel after against Ryzen and ThreadRipper now/after.
Sure I know Intel perform worse with an SSD now and possibly even worse with virtualization but can I please get to see how Ryzen perform with it too?
While you went about paying a company to diss AMD, I checked CTS' report, found out one of my intel systems uses one of the mentioned vulnerable chipsets, the ASM1142, for its USB 3.1 controller.
I bet that the PoC exploit would work on the intel platform right out of the box, if the CTS code isn't full of shit.
Gimme a copy so I can test it out.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
We called it "mandatory security levels and categories" (eg, Dockmaster.mil), and then reinvented them for minis (eg, Trusted Solaris) and micros (eg, SELinux), and now Intel is doing the category part in hardware, just like Multics. Methinks they're a tiny bit behind the times...
davecb@spamcop.net
Spectre and Meltdown being mixed constantly such to always drag AMD and ARM along with their much worse Meltdown bug. Complete nonsense Spectre and Meltdown are always mention together.
This is what we call a 'workaround'.
If somebody beats you up every time you go to the supermarket, the fix would be to get this slugger arrested. Now you can go to the supermarket without a hassle.
The alternative would be to walk around the block and avoid that battler. This is what Intel has chosen as their 'solution'.
I'm not judging, I'm merely pointing out the difference.