'Next Generation' Flaws Found on Computer Processors (reuters.com)

An anonymous reader shares a report: Researchers have found eight new flaws in computer central processing units that resemble the Meltdown and Spectre bugs revealed in January, a German computing magazine reported on Thursday. The magazine, called c't, said it was aware of Intel's plans to patch the flaws, adding that some chips designed by ARM Holdings, a unit of Japan's Softbank, might be affected, while work was continuing to establish whether Advanced Micro Devices chips were vulnerable. Meltdown and Spectre bugs could reveal the contents of a computer's central processing unit -- designed to be a secure inner sanctum -- either by bypassing hardware barriers or by tricking applications into giving up secret information.

Comments

not buying any more new computers & gadgets

[FudRucker]

until the CPU manufacturers resolve this issue, if necessary will scour craigslist and second hand PC shops and buy used junk for cheap, no more high dollars spent on new desktops & laptops & tablets & phones until this CPU vulnerability issue is resolved in a proper and long term way

Re:not buying any more new computers & gadgets

[Anonymous Coward]

Nothing will ever be 100% secure, so just give up.

Re:not buying any more new computers & gadgets

[ravenshrike]

Except they won't. At least not till quantum computers actually become usable by the regular consumer. Until then all processors will be vulnerable to some extent to SPECTRE class attacks(not however meltdown, that was purely Intel's fuckup) because you lose way too much performance dropping speculative execution entirely. There will merely be mitigation in place to make exploiting such attacks as difficult as possible.

Re:not buying any more new computers & gadgets

[amorsen]

This is simply not true. Speculative execution has real benefits on real code. Disabling it makes processors drastically slower, not just in benchmarks.

Luckily it looks like we can get to keep most of the benefits without the security flaws.

Re:not buying any more new computers & gadgets

[rogoshen1]

Please.

Are you seriously suggesting that some random on slashdot doesn't actually know more than a team of researchers at intel/amd?

Re:not buying any more new computers & gadgets

[mikael]

Out-of-order execution is similar to the way hospitals are run. You have a number of instructions (patients), you have treatment rooms (arithmetic units), waiting rooms (caches). Any patient might need a number of tests to be performed on a single visit, and the need to perform a particular test might depend on previous tests. Not all treatment rooms are available at the same time, so there is a need to keep patients waiting. There is also the security/confidentiality restriction that patients aren't supposed to see the notes of other patients, but that can happen if staff aren't careful.

Speculative execution was an idea that the CPU evaluates the two possible future state of itself then discard the outcome that doesn't happen. But they updated the main cache and not some private cache, so a high-level application could do timing tests to see if particular blocks of data were in cache or not.

Re:not buying any more new computers & gadgets

[TheRaven64]

Speculative execution was an idea that the CPU evaluates the two possible future state of itself then discard the outcome that doesn't happen

I know of a couple of research processors that have worked that way, but nothing in production. It doesn't really scale, because typical C code has a branch (on average) every 7 instructions, but a modern processor can have almost 200 instructions in flight at a time. If you execute both paths (assuming branches are simple conditional branches and not computed jumps), you need to be able to handle both instruction streams for every speculative operation. That means doubling the resources every 7 instructions and you quickly run out of transistors.

Speculative execution is about guessing what instructions you're going to run next[1] and running it as soon as you have its input operands available, then throwing away all of the state associated with the results if you guessed wrong. This is why branch mispredicts are expensive: the pipeline spends some time executing the wrong thing, then some more time discarding any of the state. The root cause of meltdown and spectre is that 'all of the state' turns out to be more than expected. In the simple case, values are loaded into (or evicted from) the cache as a result of speculatively executed instructions. This can be worked around by fetching values into some separate cache space and only writing them back to the main cache when the instructions are committed. In the more complex case, the time taken to execute and cancel the instructions varies depending on the values. That's much harder to address, because you can't simply roll back time to a little bit earlier...

[1] In most processors, anyway. The Alpha did value speculation, so would guess the results of instructions and guessing the address of the next instruction was just a special case of this. Fortunately, no one does that anymore - Spectre on the Alpha would have been so much worse than on anything from Intel.

More of an issue now

[FeelGood314]

CPUs have always had flaws and as a developer there was always an errata sheet you had to read and understand. The problem today is cloud computing and to some extent javascript. People are now running untrusted code on the same systems as their trusted programs. It was assumed that as long as your sandbox for these programs was secure and well defined that this was safe. Spectre and Meltdown proved this wasn't true.

Direct article link

[isj]

here (German)

Re:Direct article link

[Misagon]

And here in English also.

Next generation

[110010001000]

Very possibly the next generation of Intel processors are going to be slower than the previous generation once they have to fix these architectural issues.

Re: not buying any more new computers & gadget

[ralphsiegler]

the 100% percent secure computer is one that no one can access and no one knows where it is

Not a language issue

[FeelGood314]

It's not the language it's the CPU instruction pipeline. On your old 8 bit computer it would take 4 ticks to fetch the instruction, fetch the arguments, do the calculation, store the result. Then we got a pipeline where each tick you would do all 4 things, fetch instruction 4, get the arguments for instruction 3, do the calculation for instruction 2 and store the result of the instruction 1. Over the years pipelines got longer and more complex. An inefficiency in pipelines occurs when you do a branch, then have to wait for the pipeline to fill. The solution to this is to fetch both instructions and speculatively do both until you know which way the branch went. Unfortunately there were two security problems with this. Intel wasn't checking if you had permission to gather the arguments until after they were fetched and second some effects of following the branch that wasn't taken could be seen by the branch that was. So the trick was to get the speculative branch, the one your code won't take in the end, to fetch something you shouldn't have access to and then in the other branch look at that data.

It is actually very easy to exploit Meltdown and Spectre in assembly and C and much harder in JavaScript. However, my web browser doesn't regularly download and run binary files, it does regularly load JavaScript and automatically run it.

Re:Not a language issue

[complete loony]

Right, each of the variants use that same model; code that is executed speculatively, reads from memory. Your code can see some side effect, and work out what values are in that memory. To extend that simple description slightly to the currently known variants;

Meltdown (CVE-2017-5754). Speculatively executed code can bypass features of Intel CPU's that would normally prevent you from reading the kernel memory of the operating system. The workaround to this problem required changes to how the kernel swaps from "user mode" to "kernel mode", making this process much slower.

Spectre-V1 (CVE-2017-5753). Untrusted code, like JIT compiled Javascript, running inside the same process as trusted code, speculatively executes a read from an array that's out of bounds. This can read any memory that the trusted process can normally read. The linux kernel includes a JIT compiler, so you could use this flaw to read any memory from the kernel. A work-around for this is specific to each program that combines trusted and untrusted code and would probably make every read from an array slower.

Spectre-V2 (CVE-2017-5715). This one is hard to explain in a simple way, but I'll try. For some types of assembly branch instructions, you can train the CPU into branching somewhere the program wouldn't normally go. You use this to trick a trusted program into speculatively reading it's own secrets from memory (which it does normally have permission to do). Then your program can see the effects of this execution. The trusted program could be any another program, the OS kernel, or even running in another VM. It just has to be running on the same physical CPU. A work-around can be built into every compiler, by avoiding using these assembly instructions in every trusted program.

Note that you can combine Meltdown & Spectre-V1 so that Javascript can read from kernel memory. Lots of discussions of these issues have been very murky and confusing, often getting the specific details mixed up. Like which issue can be used to read from the kernel, and which of Intel and AMD is vulnerable.