Slashdot Mirror
Academics Publish New Software-Level Protections Against Spectre and Rowhammer Attacks (bleepingcomputer.com)
Catalin Cimpanu, writing for BleepingComputer: Academics from multiple universities have announced fixes for two severe security flaws known as Spectre and Rowhammer. Both these fixes are at the software level, meaning they don't require CPU or RAM vendors to alter products, and could, in theory, be applied as basic software patches.
The first of these new mitigation mechanisms was announced on Thursday, last week. A research team from Dartmouth College in New Hampshire says it created a fix for Spectre Variant 1 (CVE-2017-5753), a vulnerability discovered at the start of the year affecting modern CPUs. Their fix uses ELFbac, an in-house-developed Linux kernel patch that brings access control policies to runtime virtual memory accesses of Linux processes, at the level of ELF binary executables.
[...] The second fix for a major flaw announced last week came on Saturday from the Systems and Network Security Group at VU Amsterdam. Researchers announced a new technique called ZebRAM that they said is a comprehensive software protection against Rowhammer attacks.
The first of these new mitigation mechanisms was announced on Thursday, last week. A research team from Dartmouth College in New Hampshire says it created a fix for Spectre Variant 1 (CVE-2017-5753), a vulnerability discovered at the start of the year affecting modern CPUs. Their fix uses ELFbac, an in-house-developed Linux kernel patch that brings access control policies to runtime virtual memory accesses of Linux processes, at the level of ELF binary executables.
[...] The second fix for a major flaw announced last week came on Saturday from the Systems and Network Security Group at VU Amsterdam. Researchers announced a new technique called ZebRAM that they said is a comprehensive software protection against Rowhammer attacks.
Don't publish a freaking paper, send a goddamn diff on the LKML, and we'll be able to comment. This PR-seeking behavior from researcher is pretty deplorable.
So why should AMD systems slow down to cover Intel? or say in a system where I don't need security like this but need speed?
At least with linux I can force it off at the kernel level.
Publicity for an academic paper, on the other hand, can lead to funding.
Software can be subverted, these flaws have to be addressed in hardware redesign
This is Spectre 1, not Meltdown. I believe it also affects AMD. IIRC, it was also expected to be quite difficult to implement, though I didn't hear any follow-up about that.
I also didn't hear that Rowhammer was specific to Intel. Do you have reason to believe differently?
FWIW, and IIUC, while Linux allows you to disable the protection against Spectre (or was it Meltdown), the kernel automatically optimizes it away if the processor is not vulnerable. (IIUC, the original patch submitted by Intel didn't do that, but AMD submitted a revised patch.)
I think we've pushed this "anyone can grow up to be president" thing too far.
It's not a good forwards-looking option, but with all the vulnerable computers already out there, it's an excellent interim step. And its going to take a long time for all those computers to get replaced. IIRC, there are still a few i486-s still running. I know of an i386 that was running until about 3 years ago...it was even running MSWindows 95a.
I think we've pushed this "anyone can grow up to be president" thing too far.
Yes, let's take us some juicy hardware problems and fix'em in software!
Well, that's not an especially good idea, even if you can successfully do it.
OK, I'm personally going to need several new replacement CPUs once the hardware fixes have been implemented. Will you buy them for me?
Yes I realize someone could figure out a mass application exploit at any time now, but are there any actual active threats out there besides the mental scare tactics currently imparted by all the news outlets?
Found the Intel shill! Seriously, though - there is no reason to believe they are not in active use. The time between a vulnerability being publicised and seen being exploited as part of a professional criminal exploit in the wild is generally under two weeks. After all, you don't leave your car unlocked because nobody has stolen it yet.
After the moderate success of the Pentium 3, when AMD and Intel were pretty level, Intel went NETBURST.
Netburst was an ultra long pipeline design chasing 10GHz. It was the biggest disaster in x86 architecture to date. As it became clear to Intel that AMD would trivially defeat netburst with its own x64 design, Intel infamously went back to the Pentium 3, updated the architecture, and made Core 1/Core 2 which eventually became todays vastly improved core architecture.
Intel used AMD patents for the core 2, while AMD (in an act of unthinkably stupidity) used Intel Netburst patents to design AMD's own disaster, Bulldozer. The two companies have a cross patent sharing agreement.
Now how does this fit into the 'spectre' etc current dister for all Intel parts on sale today (but not AMD's incredible Zen)? Well it turns out that when Intel driopped Netburst, and built core 1/core 2 on the back of the Pentium 3, to give themselves a FAKE NEWS perfromance boost, they dropped all hardware privilege testing of memory access.
An analogy. When a modern multi-threading program accesses memory, it should work like a key opening a chest. Without the right key, you cannot look in the chest. But the very handling of 'keys' and the time it takes to unlock the 'chest' and look inside has an impact on performance. It turns out that after Netburst, as all modern processors went multi-core (then simulatneous mutli thread per core) Intel never implemented the lck and chest approach that is essential to secure processing.
AMD did. The bulldozer underperformed against the intel equivalents cos AMD had the lock and chest and Intel did not. Intel's performance advantage, in other words, comes from pure hardware cheating. Put the hardware lock and key back in, and Intel would fall way behind AMD's current ZEN design (and zen is already faster on instructions per clock when code is optimised for both Intel and AMD- which sadly rarely happens with commercial code, which is optimised for Intel only).
So for all the years Intel cheated and had dangerous and incorrect processing design, how did they get away with it? By conspiting with Microsoft to use atrocious 'code memory domain' methods. This is a software technique that forms trust based seperation of assets owned by threads. But low level black-hat code can always subvert this OS fantasy, and use the lack of proper memory hardware on Intel CPUs to allow one thread to read the assets of another.
Also, the Intel cheat met the needs of the NSA, CIA, GCHQ etc in making every PC insecure.
How do you fix any of Intel's current CPU's? By running only ONE thread at a time on the chip, and doing a complete state flush when a new thread is given its time slice. A current 4 core 8 thread Intel i7 would fall to less than 5% of its current max performance if an ordinary OS were forced to do this- which in reality is the ONLY secure fix for Intel parts.
TLDR- Intel x86 CPU's post netburst (all the 'good' chips from the last 10+ years) are faulty by design, where the purposeful memory architecture fault gives Intel a massive unfair thread memory speed advantage, and allows the NSA to use user level code to interogate even Ring Zero assets on any Intel CPU.
Intel needs an entire new architecture to 'fix' the fault (won't happen for at least three years), and even then Intel will then lag far below current AMD CPU designs.
if only I could have enjoyed witnessing the spending of close to EUR50k of useless spending for no other sake than spending money to justify the next funding cycle...
What ELFbac is doing is to partition the memory space into regions with different protection depending on which region the access is coming from.
You could say that it is like automated partitioning of a program into multiple processes communicating via shared memory.
The cool feature here is that the access control matrix is derived from the existing link information in the binary itself (ELF format), which means that no code rewrite is necessary.
I'm not sure how it would stop Spectre though, especially on Intel which runs code speculatively before access control. I'm looking forward to reading the paper (especially since I'm already drawing ideas from it to another project ...)
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
Someone else is/was running the i486's. The i386 was only for the purpose of running MSWind95, and when the need for it went away, so did the machine. (Well, actually hardware problems rather forced the issue...but if I'd had to keep it running I would have.)
That said, neither is a really good choice on a modern machine. Easier would be the keep it running isolated from the web, which the i386 definitely needed anyway (and that was easy, because it was running MSWind 95a...no included internet connection). For the i486 you'd be running an unsupported OS, so you had BETTER be keeping it isolated from the web. And if you're going to do that anyway, you might as well use a modern processor, unless you've got a good reason not to. (I had this timing dependent software that wasn't upgraded and where MSWind 97 munged the timing.)
I think we've pushed this "anyone can grow up to be president" thing too far.