New Spectre-like CPU Vulnerability Bypasses Existing Defenses (csoonline.com) 57
itwbennett writes: Researchers from security firm Bitdefender discovered and reported a year ago a new CPU vulnerability that 'abuses a system instruction called SWAPGS and can bypass mitigations put in place for previous speculative execution vulnerabilities like Spectre,' writes Lucian Constantin for CSO.
There are three attack scenarios involving SWAPGS, the most serious of which 'can allow attackers to leak the contents of arbitrary kernel memory addresses. This is similar to the impact of the Spectre vulnerability.' Microsoft released mitigations for the vulnerability in July's Patch Tuesday, although details were withheld until August 6 when Bitdefender released its whitepaper and Microsoft published a security advisory.
There are three attack scenarios involving SWAPGS, the most serious of which 'can allow attackers to leak the contents of arbitrary kernel memory addresses. This is similar to the impact of the Spectre vulnerability.' Microsoft released mitigations for the vulnerability in July's Patch Tuesday, although details were withheld until August 6 when Bitdefender released its whitepaper and Microsoft published a security advisory.
What CPUs are affected? (Score:5, Informative)
A little more information would be nice - like do I own a CPU that is affected?
This article [computerweekly.com] seems to indicate that it is only Intel CPUs made since 2012:
Re: (Score:3)
This article [computerweekly.com] seems to indicate that it is only Intel CPUs made since 2012:
"Only"?
Re: (Score:2)
The vulnerability specifically affects all Intel CPUs that support speculative execution of the SwapGS instruction, which means all Intel processors from Ivy Bridge (introduced in 2012) to the latest processor series available.
So not AMD. Not ARM. Only Intel since 2012
Re: (Score:2)
My point was that affecting "Intel CPUs made since 2012" means the vast majority of computers and servers out there are affected by this - yet again. So qualifying it further with "only" seemed sadly humorous.
Re: (Score:2)
Re: (Score:1)
"Considering the previous exploits affected almost all CPUs like ARM and AMD"
Pretty much all of AMD's products were immune due to their encrypted-by-default memory, excepting like one oddball variant.
Try again when you actually know which platforms were vulnerable to which attacks.
Re: (Score:2)
That's very wrong, encrypted memory doesn't help against speculative attacks and AMD doesn't encrypt by default.
Re: (Score:2)
Re: (Score:2)
Pretty much all of AMD's products were immune due to their encrypted-by-default memory, excepting like one oddball variant.
That's not factually true. There' s a long list of AMD CPUs vulnerable to Spectre. [techarp.com]
Re: (Score:2)
There was one variant of the Spectre vulnerability that affected AMD (the other variants did not) and one variant of Spectre-NG that affected AMD. But none of ZombieLoad, Fallout and RIDL (named together as MDS), Meltdown or Foreshadow affected AMD - those all only affected Intel chips (and some affected certain ARM processors). The performance impact on AMD processors has been much smaller than on Intel chips (up to 28% on i9900K vs. 6% for Ryzen 3700X and 5% for Ryzen 3950X on mitigation-sensitive benchma
Re: (Score:2)
Re: (Score:2)
My mid-2010 Mac mini is immune! Yay!
Re: (Score:3)
AMD is only (intentionally) pointing at the first attack and as they say "For the attack that is not a SWAPGS variant" basically a veiled admission that they're at least partially affected and (just like Intel), existing Spectre/Meltdown fixes will stop any attack.
Re: (Score:2)
I don't understand. How can AMD be "only pointing at the first attack" if you can then quote the actual text of what they said about the other attack? Surely that means that they did in fact specifically mentioned both scenarios and what to do to mitigate the variant that does affect them? Given that the mitigation for this was to just use the mitigation that would already be in place after Spectre then this is pretty much a non-issue for AMD.
Re: (Score:2)
No AMD replied stating the facts and your dislike of them doesn't matter. Compare this clear statement to the Intel statement bundling Meltdown and Spectre together in order to claim they were not alone in being vulnerable... Now that's professional weaseling!
Re:What CPUs are affected? (Score:4, Interesting)
You're also asking the wrong question, it's not "do I own a CPU that's affected", it's "will I be affected". The answer is, for the vast majority of users, "no", because they're not running 50 different users' potentially hostile code on their personal laptops, unlike data centre owners on their servers.
Think of it like a malaria question, it's not "can I be affected?" - no, unless you're in tropical Africa or Asia - but "will I be affected?", to which the answer for the vast majority of people is "no".
The follow-on question is then "do I want to take a 5, 10, 20-percent performance hit to mitigate a string of CPU vulns that don't affect me?", for which the answer in most cases, again, will be "no". Not just no, but "hell no!".
WINTEL Only (Score:5, Informative)
“A quick analysis of the Linux kernel revealed that although it contains a gadget which may be used in an attack, it lies inside the Non-Maskable Interrupt (NMI) handler,” Bitdefender researchers said in their paper. “We therefore believe that Linux would be difficult (if not impossible) to attack.”
Re: (Score:1)
Emphasis on quick analysis. There is no way to actually claim for sure that the gadgets do not exist.
The main reason why that particular issue is not a big problem for Linux is the fact that Linux does not support the FSGSBASE feature which allows user space to write arbitrary GS/FS base values. Linux does not support that and limits GS to the canonical user space address space which does not allow the attacker to direct it at arbitrary kernel addresses. So the main thing which an attacker can observe is i
Re: (Score:2)
We therefore believe that Linux would be difficult (if not impossible) to attack
yeah no, that means Linux is affected, they just haven't figured out a successful exploitation of the bug yet.
Comment removed (Score:5, Informative)
Re:not exactly an AMD problem (Score:4, Insightful)
Indeed. AMD was a lot more careful than Intel here. Intel basically has a 737 max 8 CPU architecture out (and no replacement), because they wanted to push performance at all cost. They must have known what kind of risk they were running, since these attacks have been discussed in the scientific community for quite a while now, longer than the vulnerable Intel CPUs are on the market. We now also understand why AMD was behind in performance for quite a while: They did not do these irresponsible and dangerous things to their customers.
In the end, AMD is a CPU company, but Intel still is a memory company that only does CPUs on the side and has never really gotten how to do them roght. The Spectre catastrophe is by far not the only evidence for that.
Re: (Score:3)
Speculative processing has been proving itself to be a real danger, rather than an effective optimization. It costs chip space, generates heat, and wastes power because it keeps having to be entirely ignored as an unsafe operation. Is there any way to use it safely? It seems not.
Re: (Score:2)
It seems to me what you need to do is make it look to any outside observer (trying to piece things back together by probing cache and such) that both paths were correct and taken, even if this means making some unnecessary calls and throwing away the results. Previously the CPU would guess, generally correctly, and the other branch wouldn't get executed, so any data it touches would not have been fetched. Take that hint away -- make the fetch. Run down both paths until you know which one is being taken. Use
Re: (Score:2)
> making some unnecessary calls and throwing away the results.
Then you've used up most, if not all, of the benefit from the speculative processing. There are metaphors for this kind of programming, where the first code is written very quickly but is so error prone that the QA cycle is far more expensive than writing it more cautiously the first time.
Re: (Score:2)
If you have more cores (real or virtual) available than threads to run, why not treat every decision as a thread until you know better? We're getting pretty close to that point in many environments, if not already past it. It's wasteful from an energy perspective, but not from a performance one, because that silicon would have been dark if the branch prediction scheduler had been used.
Re: (Score:2)
Because besides burning power and generating heat, you then have to handle the results securely. This has proven not only difficult but dangerous. At this point, I'd say it's proven impossible to do safely. And the silicon is winding up "dark" anyway as the feature keeps having to be turned off for safety. So let us not inflict the management of unreported hyperthreading on software that didn't ask for it and wasn't written for it.
Re: (Score:2)
Then the question is, how much of a performance penalty are you willing to take to ditch branch prediction? 30%? 50%? 70%? More importantly, how much of a performance hit are the manufacturers prepared to inflict, knowing they're the ones on the hook for underwhelming results?
Re: (Score:2)
Applying the Spectre and Meltdown patches cost roughly 15% performance according to the tests I can find. That seems a reasonable threshold to abandon what has repeatedly proven to be an unsafe technology.
Re: (Score:2)
The big thing that has happened since those days, is that x86 serve
Re: (Score:2)
If I might ask, what benefits? Since we have the keep turning off these features due to security failures, the benefits are very temporary, useful only for driving sales when chips are first produced. It's wasting time and resources better spent on safer technologies.
Re: (Score:2)
There's certainly an argument to be made on whether or not we want perfectly side-channel proof CPUs (which I'm sorry to tell you, will *never* exist) and what exactly the appropriate trade-offs in performance are, but there will always be trade-offs.
Now, there are certain classes that are fast and deterministic enough to be dan
Re: (Score:2)
> OpenSSL- it sacrifices quite a bit of speed to prevent side-channel attacks. It should. It's in a market where the target is concise, and data can be highly important and contextual. The RAM of your system? Not so much.
This approach, this idea that no one will bother to abuse what have repeatedly proven to be a vulnerable technology, is why such designs cannot be trusted. Modern consumer systems are almost inevitably doing _something_ with SSL.
> But the statistical chances of good, or meaningful in
Re: (Score:2)
This approach, this idea that no one will bother to abuse what have repeatedly proven to be a vulnerable technology, is why such designs cannot be trusted. Modern consumer systems are almost inevitably doing _something_ with SSL.
Which is why it's a good thing that OpenSSL does what it can to make it a difficult target for side-channel attacks, *including* from other users of the CPU it is running on.
Based on reported vulnerabilities, the chances seem much closer to "inevitable".
Did you even read what I wrote? Inevitable? Sure. If you leave your machine pegged running Evil code indefinitely until it finds enough data to be useful, leaking *bits* at a time of inferred data.
Trying to win against Spectre is to try to win against the very nature of modern superscalar CPUs. Even rolling back the clock entirely wil
Re: (Score:2)
I read what you wrote. Based on the actual reported vulnerabilities, I'm afraid it does not seem to be founded on reality.
> Trying to win against Spectre is to try to win against the very nature of modern superscalar CPUs
Please, do not confuse "speculative execution" with the simultaneous execution needed for superscalar systems. "speculative execution" runs code that was not requested by the programmer, in ways that the software programmer, the compiler, the system libraries, and the kernel never direct
Re: (Score:2)
I read what you wrote. Based on the actual reported vulnerabilities, I'm afraid it does not seem to be founded on reality.
Feel free to explain to me why you're afraid of Spectre style side-channel information leakage.
Please, do not confuse "speculative execution" with the simultaneous execution needed for superscalar systems. "speculative execution" runs code that was not requested by the programmer, in ways that the software programmer, the compiler, the system libraries, and the kernel never directly requested. Since It seems to meet the precise problem described by Donald Knuth, to wit:
Super-scalar architectures require speculative execution to keep the pipeline full.
While premature optimization may be the root of all evil, pipeline stalls are the difference between a CPU running at >=1 IPC, vs. a fraction that.
What do you propose be done on a branch instruction? Wait for it to be complete before the fetch?
Re: (Score:2)
> While premature optimization may be the root of all evil, pipeline stalls are the difference between a CPU running at >=1 IPC, vs. a fraction that.
Which has, repeatedly now, proven unsafe. It's not clear that it _can_ be done safely.
> What do you propose be done on a branch instruction
Do what the programmer wrote: the branch instruction, _only_ the branch instruction, and stop mishandling the security of the alternative possibilities. Based on the patches needed to avoid these bugs, the performan
Re: (Score:2)
Which has, repeatedly now, proven unsafe. It's not clear that it _can_ be done safely.
No multitasking can be done truly safely if that's the bar you're setting.
Do what the programmer wrote: the branch instruction, _only_ the branch instruction, and stop mishandling the security of the alternative possibilities.
Ok, It's clear I'm now talking to someone ridiculous.
If we allow a stall on every conditional branch, you'll quickly find that your 4GHz processor operates at an equivalent speed of ~250MHz. You enjoy that. I'll be laughing at you.
Based on the patches needed to avoid these bugs, the performance loss is only a few percent.
The patches needed to avoid these bugs are targeted patches to avoid specific leakages of speculative execution. They by no means avoid speculative execution- which can not, and will not be done- ie, why th
Re: (Score:2)
If you want to go back to the latest in-order Intel Atom you're welcome to do that, the rest of the world likes speculative execution.
You are oversimplifying, speculative execution does waste power compared to a theoretical processor with an oracle and out of order execution in itself wastes power due to dynamic scheduling. But we don't have perfect processors with oracles and in many cases speculative execution is more power efficient than avoiding it. It isn't "entirely ignored" and isn't generally unsafe
Re:not exactly an AMD problem - just 50% of Intels (Score:2)
While AMD does not speculate through SWAPGS, it still is affected by a mis-speculated branch which does NOT issue SWAPGS when it should.
That means on an entry from user space the CPU speculates around the SWAPGS path and any subsequent GS based access uses the user GS base. So AMD is affected as well, but only on one of the possible mis-speculated branches.
So AMD has just 50% of the problem, but as Intel is affected by Meltdown, the Meltdown mitigation - if enabled - mitigates the Intel only path already b
Apparently a broken firehose (Score:2)
I submitted this story two days ago and it was apparently rejected for no reasons.
There were also stories about a critical KDE vulnerability, Harmony OS and other submissions. I'm not sure what's wrong with the firehose. Or maybe /. editors have suddenly decided to resubmit stories by themselves. Who knows.
Re: (Score:2)
You'll notice a correlation between the hours of submission and the rate of acceptance. Do this while they're on the clock, and your chances go up. Otherwise, once you get pushed off the front page of Firehose, you can forget about getting picked up.
Just turn it off! (Score:1)
At this point, Intel chips are so full of security holes that you might as well turn the damned things off.
If you haven't switched to AMD chips, now is the time.
Re: (Score:3)
You'd think that based on the reporting hyperbole, because that reporting never mentions the most critical part. "How many of these types of holes were actually used by bad actors in the past".
And when you find out that answer is "zero", conclusion on naive people who keep knee jerking every time a "new spectre-like vulnerability" pops up.
Re: (Score:2)
Are you running your Windows 95 machine without a firewall?
Re: (Score:2)
AMD has security holes too, there are four at least unique to AMD
Re: (Score:2)
You're not talking about those "Requires root access" "bugs" that was just basically a hit piece are you?
Re: (Score:2)
No, these allow getting root access. AMD recent chips (maybe not latest Epyc2?, I don't know) have many more flaws than those of course, over a dozen.
Real world exploits might tell someday which really is the least secure, but just saying AMD isn't a given safety zone.
Re: (Score:2)
Can you link me please. I obviously didn't know of the ones you were speaking and would like to know as I run AMD. Kthx.
Comment removed (Score:5, Interesting)
Re: (Score:2)
meanwhile AMD just keeps getting better and better with faster and faster chips without all these weaknesses.
Without some of those weaknesses. They undoubtedly have their own unique vulnerabilities as well, just not picked up yet because Not Intel (fewer eyeballs on the problem). I wouldn't bet the farm on AMD not getting hit badly themselves. (Not saying they will, or that I know of anything specific, but they could, so how much do you want to commit?)
Do I think AMD makes more sense right now? Hell yes, and not just because of vulnerabilities. That's why I wouldn't be put off them even if they were open to every
Re: (Score:2)
Re:Jesus Intel.. (Score:5, Insightful)
Most of these vulnerabilities that affect Intel but not AMD seem to come down to Intel doing something reckless to increase performance which AMD didn't do.
Sure, there might be AMD specific issues that haven't been discovered, but it certainly sounds like AMD cared about designing a secure architecture and Intel didn't.
Re: (Score:2)
"Without some of those weaknesses"
Without ALMOST ALL of the weaknesses simply due to AMDs architectural choices like encrypted RAM, and careful choice of what does or does not get speculative execution.
Boy you spread a lot of FUD.
Re: (Score:1)
Love the provable intel downmod since I've got direct IP access to /. comments as part of my contributions to this site.
Wanna try that again, asshole Mal-2 and friends?
Re: (Score:2)
They undoubtedly have their own unique vulnerabilities as well, just not picked up yet because Not Intel (fewer eyeballs on the problem). I wouldn't bet the farm on AMD not getting hit badly themselves. (Not saying they will, or that I know of anything specific, but they could, so how much do you want to commit?)
I have to disagree here. AMD's CPUs may have unknown vulnerabilities however most of Spectre is based on speculative execution which AMD not only does differently than Intel but also Intel relied more on this to boost their CPU performance in the past. While the use of speculative execution helped Intel chips perform better the unknown hidden cost was security.
Sounds like Boeing (Score:2)
Make money and consumers be damned.