'Next Generation' Flaws Found on Computer Processors (reuters.com) 144
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.
not buying any more new computers & gadgets (Score:5, Insightful)
Re:not buying any more new computers & gadgets (Score:5, Insightful)
Nothing will ever be 100% secure, so just give up.
Re: (Score:3, Insightful)
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.
Re: not buying any more new computers & gadget (Score:5, Insightful)
Re: (Score:1)
I have a 100% secure computer. It's a paper and pencil, while i'm locked in a sealed room. 100% Turing complete, the problem is the processing speed is extremely slow, and has a high error rate..
Re: (Score:2)
the 100% percent secure computer is one that no one can access and no one knows where it is
Oh, that one. I remember that one-- in Langley, VA!
Re: (Score:2)
ARM produces the 32-bit Flycatcher CPU (Cortex M0+) has 12K gates, internet-of-things compatible, so it would be easy to prove that there aren't any secret backdoors. Add a C based GUI system and you would have a secure PC.
Re: (Score:3, Interesting)
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: (Score:1, Insightful)
you will have to apply crippleware patches to secure it - and reduce it to half the original performance
That "reduced performance" is actually the performance you should have had all along.
The problem is, Intel tried to cheat. "Speculative execution" is just a marketing gimmick created so they could claim that their chips were faster than the competition. And when one company cheats, and gets away with it, everyone else has to cheat too, in order to stay competitive. So now we're stuck with hundreds of millions of CPUs with design flaws.
Re:not buying any more new computers & gadgets (Score:4, Interesting)
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: (Score:3)
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: (Score:3)
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: (Score:3)
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 ar
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Make it run fast with a short pipeline, then branches won't cost much.
A long pipeline is required to increase the load-to-use latency allowing a higher frequency. If the pipeline is shortened, then the load-to-use latency requirements on the cache increase lowering the frequency.
Re: (Score:2)
Holy crap there is a lot of stupid here. First of all, out-of-order execution is older than Intel itself. Intel is a relative latecomer to the OOO party, having been beating by at least Control Data, IBM, and AMD. Second, it is not a 'marketing gimmick', it actually makes the processor run workload faster. There is no 'cheating. Perhaps you think the switch from relays to tubes to transistors to ICs were also all 'marketing gimmicks' to make processors 'seem' faster?
Re: not buying any more new computers & gadget (Score:1)
Re:not buying any more new computers & gadgets (Score:5, Interesting)
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 (Score:4, Informative)
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: (Score:2)
Spoken like a true (defunct) Detroit union boss of the late 1970s.
Unfortunately, the Japanese had already discovered the magic of making as much progress as possible with the resources in hand, which allowed them to manage inventory on a JIT basis, streamline production, and kick American butt, bigly.
Re: (Score:2, Informative)
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 d
Re: (Score:2)
Even Intel's own white paper cited a best case performance improvement with hyperthreading was ~30%
That was a typical performance improvement in a mixed workload, aka lots of multitasking. Worst case decrease was about 5% reduction and best case increase was over 100%, super linear. My cousin was an admin at a datacenter where he saw all kinds of work loads. Some where he disabled HT because of negative performance, and other where he got over a 50% improvement in system throughput.
Re: not buying any more new computers & gadg (Score:2, Informative)
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:not buying any more new computers & gadgets (Score:4, Funny)
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 & gadget (Score:1)
Back in the day, researchers from AMD and Intel would be Slashdot randoms. These days I doubt a Slashdot random could walk and chew gum at the same time.
Re: (Score:2)
Z80 is 100% immune. Time to dust off the old TRS-80.
Re: (Score:3)
Grab a solar panel and as many old MIPS WRT boxes as you can carry and run for the hills!
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re:not buying any more new computers & gadgets (Score:4, Interesting)
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 & gadget (Score:2)
Re: (Score:3)
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
Re: (Score:2)
We know how to make secure chips and there are research done in that area.
Yep. But we don't actually follow through on it, nor do consumers demand assurances to that effect, so the point is moot until that changes.
Re: (Score:2)
You are clearly talking out of your ass.
Re: (Score:2)
I would say it is your assertion that needs proof. So would anyone else who also studied VLSI design in college.
Re: (Score:2)
Meh. I did bother to google at one point and read a nice paper on a formal language for a formal pre-silicon design security validation language. But I closed the tab, and am bored with it now. You do know that subcontracting designs is a decades long practice and hardware trojans have been around for so long that the industry is on top of this problem, right? If you're concerned about "analogue security", lower your damn clock speeds so you aren't running all your gates right up to the edge of their spec
Re: (Score:1)
Why, are you running a public virtualization service?
I'm not, so I'm not really worried about Meltdown/Spectre attacks on my infrastructure.
Re: (Score:2)
You realize this flaw exists in almost every CPU built in the past 2.5 decades right? The newer CPUs are actually less susceptible...
Re: (Score:2)
Re: (Score:2)
I'm still on a 2600k and Windows 7 for my gaming box.
There are about 3 titles that are DX12 / Windows 10 exclusive that interest me - Killer Instinct, Sea of Thieves, and probably something else that I can't remember. Sea of Thieves currently has no content worthy of a purchase, so I'm fine passing on it for now. (I did play in the stress tests on a physically separate Win 10 install.)
Re: (Score:2)
Or "Computertechnik"... but naaaahh... that doesn't fit the magazine's topic at all.
Re: (Score:3)
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.
More of an issue now (Score:5, Insightful)
Re: (Score:2)
Full page reload for every action? (Score:2)
This is why I have been saying for years Javascript as GOT to go.
Would you prefer a form submission and full page reload for every action that you perform in a web application?
IDK if we should go to a locked sandbox with very limited tools
That's what JavaScript was supposed to be.
Re: (Score:2)
Not a language issue (Score:5, Insightful)
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: (Score:2)
Unfortunately, even if it's "harder," it's still possible to exploit in JavaScript, and with development of portable assembly language variants, it'll be easier. And once written as POC, it's easy to deploy in a vast variety of contexts.
Re:Not a language issue (Score:4, Informative)
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: (Score:2)
The solution to this is to fetch both instructions and speculatively do both until you know which way the branch went.
Speculative execution relies on the branch prediction to execute *one* of the paths after the branch. Eager execution executes both sides of the branch in which case branch prediction is not required. Only research processors use eager execution as it is incredibly inefficient compared to branch prediction which has gotten very good.
Re: (Score:2)
Direct article link (Score:5, Informative)
here [heise.de] (German)
Re:Direct article link (Score:5, Informative)
And here in English also [heise.de].
Next generation (Score:5, Insightful)
Re: Next generation (Score:1)
Re: (Score:1)
Re: (Score:1)
The short version is that Intel used BlackMagic(TM) called 'Speculative Execution' to enhance performance but it turns out that this introduces unwanted security problems. (Actually, this was known, but those who knew thought no one cared.)
The slightly longer version is that Intel took (performance) shortcuts in their implementation of speculative execution. A better (more secure) implementation will not have those (performance) shortcuts. This is generally understood to result in slower performance. AMD us
Re: (Score:2)
You clearly have no idea what you are talking about. First of all, what 'architecture' are you talking about? If it is the ISA, then ANY ISA will benefit from out-of-order execution, which is why even RISC processors use it (unless you know of some magical way to make memory accesses run at CPU speed). And if you mean the micro-architecture, then they clearly DID 'make the investments in making a better architecture' as they switched from an in-order architecture to an out-of-order one.
Meltdown was not c
Re: (Score:2)
If it is the ISA, then ANY ISA will benefit from out-of-order execution, which is why even RISC processors use it (unless you know of some magical way to make memory accesses run at CPU speed).
There was a way to do that back when CPUs were measured in tens of MHz... SRAM. But that's not practical with today's memory volumes, you have to go back to using e.g. a 68k with MB of RAM instead of GB.
Wow! News for the nerds, it is (Score:1)
contents of a computer's central processing unit -- designed to be a secure inner sanctum --
All these nerds who have been using the computers since they were toddlers would find this description of the CPU really really fresh, novel and eh, yes, news.
Reserving CVE numbers is a meta-security hole. (Score:3)
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.
Re: (Score:2)
There's no clear need for CVE numbers to be issued sequentially at all, whether individually or in blocks; only that they be unique.
Re: (Score:2)
Arguably, knowing that vulnerability disclosures are coming reduces the value of current and upcoming products and can even have an effect on stock prices.
That would be the best thing to happen in security in the last two decades (since ssh was invented, basically). Companies would suddenly start caring about security.
Re: More "new" bugs?? (Score:2)
Likely Variants on Spectre (Score:3)
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: (Score:2)
That's also what Spectre (and Meltdown did). They timed cache accesses before and after speculative loads using secure data as the "forwarding address".
The other variants (BranchScope if you're interested) uses a similar technique except it trains the branch predictor using secure data bits and then times the execution time.
conspiracy theory time (Score:2)
Next Generation Flaws (Score:1)
Lore
New architecture? (Score:3)
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?
Old Skool Time (Score:2)
Re: (Score:2)
UltraSPARC T1
Re: (Score:2)
Re: (Score:2)
Well, let's see. With modern high performance caches executing at 3 GHz with a 4 cycle load-to-use penalty, a 6502 would come out at like 375 MHz. There are faster processors than that which do not employ speculative execution including many current ARM cores.
Turns out Brian Krzanich was right. *wink* (Score:1)