'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

[DigiShaman]

Good luck. From understanding the flaw, finding a solution, testing for unintended consequences, creating a new mask with the changes to fabrication....probably a year wait or longer.

Best we can hope for is a microcode update that doesn't leave much of a performance hit.

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

[BlueStrat]

I think the point FudRucker is making that there is no point in buying high-end stuff at premium prices when a year or two down the line you will have to apply crippleware patches to secure it - and reduce it to half the original performance; if you buy yesterday's tech, you could get the same cripplewared performance at a fraction of the price.

That's why you release new OS's and software that *only* work with "new generation" hardware while promulgating new web standards that embrace "new generation" hardware-specific standards but are incompatible with the old.

Strat

Re:not buying any more new computers & gadgets

[Megol]

A lot of hot moist air coming from your direction, do I also detect some alcohol?

I own my computer. I also own my own body. I may not be able to tinker with everything in my computer but the same applies to my body. IOW bogus.

No these problems/vulnerabilities aren't intentional. Anybody with a working brain would understand that but as you seem to lack that part: these fall out perfectly logically when tracking the progress of processor design, also adding a problem intentionally means giving up ones market share.

That someone with resources can find a problem is just hand waving. Complex systems have more chances to leak information, processors and computers are very complex beasts so yes statistically it is probable that given enough resources some kind of vulnerability can be found. But that doesn't make them practically exploitable, that doesn't create exploits that aren't there in the first place, that obviously do not make any vulnerability exploitable remotely (ludicrous idea!).

We know how to make secure chips and there are research done in that area. So absolutely wrong.

In short a bunch of inane ramblings. I do hope you can blame the alcohol.

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

[Anonymous Coward]

really? Okay, they overstated it -- speculative execution isn't just a marketing gimmick, but they *did* cheap out on implementation which is why AMD was less affected.

There are, of course, worse marketing gimmicks. Like pretending that the number of virtual cores is the same as physical cores. Anyone with technical knowledge knew better, but marketing was careful to let consumers draw wrong conclusions. Even Intel's own white paper cited a best case performance improvement with hyperthreading was ~30% (I don't recall the exact figure) and a naive implementation actually had a (minute) performance loss. By the time it was put into pentiums the hardware assured there was never any loss, but mostly there is no performance benefit to hyperthreading and definitely there is none if you are doing embarrassingly parallel tasks.

But it is hard to overcome marketing. I do 3d rendering and tried to educate others, encourage them to do their own tests (and shared mine). The tests showed what I already knew: that performance with hyperthreading was identical to without.

Ignoring the very real marketing impact and shortcuts for performance reasons just exacerbates the problems.

Re:not buying any more new computers & gadgets

[skids]

Grab a solar panel and as many old MIPS WRT boxes as you can carry and run for the hills!

Re:not buying any more new computers & gadgets

[Carewolf]

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.

Yeah, and fetching things from memory during speculative execution has replaced prefetching, and removing that would get is back to needing instrumented prefetching, so they need to be smarter in undoing an invalid fetch.

Re:not buying any more new computers & gadgets

[imgod2u]

What exactly do you think the difference between prefetching and speculative execution is? Most prefetches use program patterns (some even go so far as runahead to guess addresses) to prefetch into cache. It's this exact behavior of populating the cache before permissions are resolved that is both fast (speedup) and insecure.

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]

What exactly do you think the difference between prefetching and speculative execution is?

Not the GP, but prefetching, unlike speculative execution, is not rolled back. In speculative execution, you start executing instructions that probably will be executed, but if you shouldn't actually have executed them then you silently discard the results and reset the pipeline to the earlier state. In prefetching, you pull in data from main memory to the cache that might be needed soon, but if it isn't used then you still leave it in the cache and still evict whatever you displaced to load it.

Both are observable and provide side channels, but prefetching is simpler (speculative execution can also trigger prefetching, so they're non-orthogonal).

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.

Re:not buying any more new computers & gadgets

[TheRaven64]

The original MIPS processors are immune, because they had a 3-stage pipeline and a branch delay slot and so always had the branch destination available by the time that they needed to fetch the target instruction. Almost all later MIPS cores are vulnerable to variations of Spectre, though I believe some of the Cavium ones aren't because they have lots of hardware threads and simply pause a thread on each branch and execute another until they get the branch target.

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.

Reserving CVE numbers is a meta-security hole.

[craighansen]

The process of reserving CVE numbers clearly discloses timing of discovery of vulnerabilities. The CVE numbering authority should close that potential security hole.

I'm at least half serious about this. Arguably, knowing that vulnerability disclosures are coming reduces the value of current and upcoming products and can even have an effect on stock prices. It may also embolden black-hat security to step up efforts to discover vulnerabilities, knowing of the presence of them, and encourage them to attempt to subvert security measures to keep them secret until patches are available.

Likely Variants on Spectre

[crow]

It is likely that there are other bugs related to speculative execution that can leak data. For example, you could have code that leaks data through timing instead of through direct cache impact. You measure the number of cycles after writing clever code that consumes one more or less based on a bit of restricted data.

Re: not buying any more new computers & gadget

[sexconker]

A 100 percent secure computer can be turned into a military grade cipher machine by every competent computer scientist...

Nope. A 100% secure system wouldn't let the computer scientist modify it or even determine that its hardware met milspec.

New architecture?

[duke_cheetah2003]

Maybe the entire architecture paradigm needs a start-from-scratch perspective?

We've been doctoring and hacking the PC architecture for what, 30 years now? Under the hood, everything still basically laid out the same as it was with the first 286 and 386 machines. Not much has changed. Maybe it's time to redo everything?

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.

Re: not buying any more new computers & gadg

[Anonymous Coward]

AMD Ryzen 1700, the previous gen, has, 8 cores, 16 threads, 3+ ghz base, 4ghz burst. 65watts.
It's not much faster than my 8120fx, but it has twice the threads for half the watts.

So its 4x as fast per watt and fits in Tiny itx builds.

Re:The magazine is named c't?

[dunkelfalke]

Actually "computing today".

c't used to be awesome back in the day - the most geeky computer technology magazine in Germany, with a lot of DIY projects. Also sometimes as thick as a mail order catalogue. Their website used to have the same "slashdotted" effect as the actual slashdot of the same time period. Unfortunately with the start of this century c't slowly changed the target group from geeks to more or less mainstream.