Slashdot Mirror
Eight New Meltdown-Like Flaws Found (reuters.com)
An anonymous reader quotes Reuters:
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 Corp'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... The magazine said Google Project Zero, one of the original collective that exposed Meltdown and Spectre in January, had found one of the flaws and that a 90-day embargo on going public with its findings would end on May 7...
"Considering what we have seen with Meltdown and Spectre, we should expect a long and painful cycle of updates, possibly even performance or stability issues," said Yuriy Bulygin, chief executive officer of hardware security firm Eclypsium and a former Intel security researcher. "Hopefully, Meltdown and Spectre led to improvements to the complicated process of patching hardware."
Neowin now reports that Intel "is expected to release microcode updates in two waves; one in May, and the other in August."
"Considering what we have seen with Meltdown and Spectre, we should expect a long and painful cycle of updates, possibly even performance or stability issues," said Yuriy Bulygin, chief executive officer of hardware security firm Eclypsium and a former Intel security researcher. "Hopefully, Meltdown and Spectre led to improvements to the complicated process of patching hardware."
Neowin now reports that Intel "is expected to release microcode updates in two waves; one in May, and the other in August."
Speculative execution bypasses the memory protection barriers for efficiency reasons. The actual problem is that cache coherence is global rather than per-process and its effects are measurable. That is the vector for wagonloads of side channel attacks. Speculative execution to addresses based on protected locations is just a rather elegant side channel attack since it does not count towards privilege violations and thus does not trigger an exception that would in turn cause a much larger impact on cache coherence and other measurable CPU state than what you are trying to measure.
Cache coherency is a side channel attack that will keep on giving for a long long while to come.
I can't wait for the "let's buy old hardware in protest" coments all over again.
Good luck with that. Basically you need to buy processors with fixed (rather than minimal) cycle counts in order to stop side channel attacks based on cache coherence. 80486 is already too new for that I think. If I remember correctly, it already sports something like 8kB internal cache memory.
MELTDOWN or SPECTRE? Because the effects of SPECTRE flaws that aren't like MELTDOWN can be almost completely mitigated through good program design. MELTDOWN class flaws however mean that once exploited anything the computer is doing can be exploited and program design doesn't matter.
Seriously, I remember the good ol' days with multiple quadruplicate and triplicate posts in a single day, back when duplicates were rare and single posts were unheard of.
Also are the new ones in the category of silicon fix (halve a year cycle time at best) or microcode??
It depends on which CPU you've got. Intel has already announced that they are never going to fix a whole bunch of CPUs with microcode updates, in spite of having fixed some other CPUs which are about the same age. Some have stated that they believe this means that they can't fix them in microcode. Personally, I suspect that they can, but the performance impact would be beyond anything we've seen so far, so they're simply refusing to do so.
I'd like to see Intel outright forced to issue a fix for any processor where it is possible, for those customers who can accept the performance impact. Remember, Intel abused their market position over AMD — and that market position was based on a competitive speed advantage which was in turn based on compromising security! Not forcing them to fix it in every possible case is literally rewarding them for bad behavior. I would go so far as to say that they should also pay for replacement of any system compromised; they should pay a percentage of the new system price based on the industry average percentage cost of the CPU.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"Hopefully, Meltdown and Spectre led to improvements to the complicated process of patching hardware." Neowin now reports that Intel "is expected to release microcode updates in two waves; one in May, and the other in August."Read more of this story at Slashdot. see: https://showbox.onl/, https://vidmate.onl/ & https://mobdro.onl/
And so I do now: Exclusive: Spectre-NG - Multiple new Intel CPU flaws revealed, several serious
100% sincere question: how does that work? My understanding is that a small claims lawsuit only works if you can quantifiably prove damages. "I had to buy a new desktop/server" seems easy enough, but if you went against Intel and won, how did you prove that Spectre and Meltdown were the cause of your purchase to the point where the judge ruled in your favor?
There are two primary ways to use small claims court for this type of purpose.
One of those ways is due to the fact these courts have upper limits on your claims (thus the name) plus the fact layers have less involvement (they are intended for two individuals to seek remediation)
This can be used (or some say 'abused') by an individual against a larger company by claiming a fairly small amount of damages, while using a small claims court local to where you live but the company has no actual presence.
You bet on the odds that the company won't even bother to send a representative to the court at all, and thus the judge rules in your favor by default.
These odds actually do work in an individuals favor so long as you don't get greedy.
It costs the company money to send a representative to the court, and from their point of view "winning" means they simply pay their own costs to win. "Loosing" means paying their costs to try and win, plus the damages that the judge agrees are legitimate.
Since presumably it would cost Intel more to fly a representative out to the court than to simply pay out $300 or so, the cheapest result for Intel is to just not show up and pay the damages.
Only if those damages would cost more than the time paid to the representative plus travel expenses, would there be any benefit to them bothering to defend their case.
Also if Intel doesn't bother putting forth any defense, you don't really need to provide much evidence like you mention.
Explaining to the judge that Intel refuses to fix the bug in the product you bought, and stating that bug is central to what you do (aka you can say that servers only purpose is to run virtual machines), combined with the two receipts that matter will be enough.
One receipt showing purchase of a defective CPU in a system to show you have standing, and another receipt showing purchase of a replacement CPU to show the amount of your damages.
You could mention that your time has a cost too, but it may be best to also just say you can't easily provide evidence of that cost and so you aren't including it in your claims.
I'm not sure if that would even matter, but I'd presume a judge would expect such a claim if you are being legit about things.
But remember the goal is to not get greedy so Intel won't think it is worth showing up at all.
The more you try to increase your damages claims, the less likely that gets.
It may take a while for AMD to get to the point where customers trust them more overall than they trust Intel.
From all I read on forums like this (not being in the "decider" circles myself), it takes time to build up a good reputation in the server market. Now AMD was almost out of the server business until a year ago, because their Opterons were quite a bit behind in performance. They were also not completely untouched by Spectre, albeit looking better than Intel in that regard.
Now AMD have an strong new line of server processors with Epyc, and they have left a better impression than Intel in the whole Meltdon/Spectre affair. So expect them to get quite a bit of interest by customers for Epyc's performance, and also a boost in getting to the point of "less distrusted than Intel". ;-)
But I still think it will be a relatively slow shift in the market, compared to the whims of the consumer market
C - the footgun of programming languages
No, it's Heise. Neowin's news team has been and remains a joke.
You're being silly. AMD seems to be immune to this class of exploits, but never believe that they don't have exploits of their own. Nothing that complex is without flaws.
I think we've pushed this "anyone can grow up to be president" thing too far.
Well, there is AMD which appears quite competitive again.
If you are buying stuff like an i7-3930K CPU @ 3.20GHz Ã-- 12, I'd guess you are probably among those enthusiasts who are following the news and read stuff like the AMD Ryzen reviews. So you should know they have a pretty competitive processor again.
Considering the Meltdown/Spectre debacle, AMD are not completely untouched but still looking better than Intel right now.
Performance wise and to my surprise, the Intel Core i7 7820X (Skylake X 8-core + Hyperthreading) is indeed not that much faster than the i7-3930K, according to what comparisons I can find on the net.
If your workloads are massively multithreaded, the AMD Threadripper might be worth a look...
C - the footgun of programming languages
They do it wrong. At least, most of the superscalar POWER processors do it wrong, and SPARC does it wrong. However, Itanic is supposed to be not vulnerable, so it finally has something going for it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
AMD seems to be immune to this class of exploits, but never believe that they don't have exploits of their own. Nothing that complex is without flaws.
They were being deliberately silly, but it's still a fact that Intel deliberately did bounds checking at the wrong time for a performance advantage, and AMD didn't. What else has Intel done wrong with their designs in order to get ahead of AMD?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Replacing an older Intel CPU and board with an AMD CPU+board of equal performance may actually be cheaper than replacing with fixed Intel parts, if the end user is the one paying. But of course, Intel would rather take the bigger hit on paper and hand out its own products, rather than funnel one thin dime to AMD, so unless any payouts are in cash, the replacements for anything are going to be more Intel.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
I presented some before and after patch benchmarks from my systems, and some independent ones I found online. Intel actually sent a local lawyer to represent them, but he only had their weasel word statements that it might get better eventually maybe.
I got 70% of the cost of two new systems plus court costs and wages for half a day off work. Oh, and mileage too, the judge reminded me of that.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Meltdown can be totally protected against in software however with a significant performance impact.
It is patched, by completely changing the way kernel works and not relying on memory protection anymore. Thank you very much, Intel !
Instead you need to context switch and make important kernel parts inaccessible on each system call.
(PCID is something that helps a bit the context switching : you don't actually flush the whole context, you use different process tags so the differently tagged process cannot be seen anymore).
Spectre can be divided into two kinds of attacks:
. One kind that bypass protection checks (range checks etc.) used to create software based virtual machines. These can be protected against in software.
Specifically, relying on by-passing any check (such as a boundary check on an array). It's ABSOLUTELY NOT virtual-machine specific.
The thing is, it's still the same process, still reading data that it has access to, to begin with (unlike Meltdown which basically fucks up any notions of memory protection). So its usability is limited to processes that both can run 3rd party provided code and contain critical data (i.e.: a badly designed webbrowser that runs web-provided javascript and its password manager both in the same context) (or another example: the Linux kernel's new-gen PacketFilter can be optionally configured to JIT compile the user-provided filtering scripts. USer-provided code in a kernel context, what could possibly go wrong ? Hint: There's a reason why it's not "on" by default).
But basically, most of the cases can be handled by keeping sane design pattern in software.
One kind that use shared branch prediction state between an attacker and a victim to influence speculative execution when running the victim code, this can be used to extract data that can be exfiltrated through a shared cache.
Which means that an attacker could be a userland software running on the cloud, and target could be the hypervisor itself. Which is several levels of scarry.
But this thing also requires very detailled knowledge of the internal of the CPU.
It has been successfully exploited on Intel Xeon by Google Project Zero.
The jury ist still out if it is possible to make a meaningul exploit on AMD CPUs (they also to indirect branching speculation, but in a completely different way, that currently seems unlikely to be actually exploitable.
This is in general not possible to patch in software.
It is actually pretty much patchable, the technology is called a retpoline. It's basically the compiler instructed to make special construct that cause mis-predicted branches to jump to an innocuous piece of code.
But it's compiler-dependant, meaning that you need to have a source code to recompile.
For the open-source world (like most of Linux distros), it's piece of cake, it's just recompiling the packages with different flags.
For closed source Linux drivers (hello, nvidia), for binary linux systems (the thing that your smartphone manufacturer put on your device and refuses to upgrade since basically the day after it started shipping), and for any windows computer : that's a nightmare.
Good program design have nothing to do with this.
Good program design try to keep sensitive data and 3rd party provided scripts separated.
That handles a lot of the Spectre v1 attacks.
It's not solving ALL the speculative execution problems tough. (it's doing nothing against Spectre v2 and Meltdown. But those are mostly due to lack of good *hardwware* design. Thanks again Intel !)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]