Top Linux Developer On Intel Chip Security Problems: 'They're Not Going Away.' (zdnet.com) 87
During his Open Source Summit Europe keynote speech, Greg Kroah-Hartman, the stable Linux kernel maintainer, said Intel CPU's security problems "are going to be with us for a very long time" and are "not going away." He added: "They're all CPU bugs, in some ways they're all the same problem," but each has to be solved in its own way. "MDS, RDDL, Fallout, Zombieland: They're all variants of the same basic problem." ZDNet reports: And they're all potentially deadly for your security: "RIDL and Zombieload, for example, can steal data across applications, virtual machines, even secure enclaves. The last is really funny, because [Intel Software Guard Extensions (SGX)] is what supposed to be secure inside Intel ships" [but, it turns out it's] really porous. You can see right through this thing." To fix each problem as it pops up, you must patch both your Linux kernel and your CPU's BIOS and microcode. This is not a Linux problem; any operating system faces the same problem.
OpenBSD, a BSD Unix devoted to security first and foremost, Kroah-Hartman freely admits was the first to come up with what's currently the best answer for this class of security holes: Turn Intel's simultaneous multithreading (SMT) off and deal with the performance hit. Linux has adopted this method. But it's not enough. You must secure the operating system as each new way to exploit hyper-threading appears. For Linux, that means flushing the CPU buffers every time there's a context switch (e.g. when the CPU stops running one VM and starts another). You can probably guess what the trouble is. Each buffer flush takes a lot of time, and the more VMs, containers, whatever, you're running, the more time you lose. "The bad part of this is that you now must choose: Performance or security. And that is not a good option," Kroah-Hartman said. He added: "If you are not using a supported Linux distribution kernel or a stable/long term kernel, you have an insecure system."
OpenBSD, a BSD Unix devoted to security first and foremost, Kroah-Hartman freely admits was the first to come up with what's currently the best answer for this class of security holes: Turn Intel's simultaneous multithreading (SMT) off and deal with the performance hit. Linux has adopted this method. But it's not enough. You must secure the operating system as each new way to exploit hyper-threading appears. For Linux, that means flushing the CPU buffers every time there's a context switch (e.g. when the CPU stops running one VM and starts another). You can probably guess what the trouble is. Each buffer flush takes a lot of time, and the more VMs, containers, whatever, you're running, the more time you lose. "The bad part of this is that you now must choose: Performance or security. And that is not a good option," Kroah-Hartman said. He added: "If you are not using a supported Linux distribution kernel or a stable/long term kernel, you have an insecure system."
Re: (Score:1)
I think this is a bit overblown. (Score:3, Interesting)
So it's best to stick to the same kinds of practices the OpenBSD folk have been doing for years: good controls on code quality, audits, and turning off anything unnecessary, limiting feature sets (sorry managers), etc.
Re: I think this is a bit overblown. (Score:2, Interesting)
yes. (Score:2)
I don't have the link handy but yes there was a javascript proof of concept attack published quite a while ago. it was on slashdot in fact.
Re: I think this is a bit overblown. (Score:5, Informative)
Is there a proof of concept attack somewhere? and if there is, can it be performed from JavaScript? Any attack without a PoC is not an attack.
https://developers.slashdot.or... [slashdot.org] https://it.slashdot.org/story/... [slashdot.org]
Re: (Score:3)
Any attack without a PoC is not an attack.
Security requires being proactive and identifying sensitive parts that can (at least conceptually) be broken under some circumstances, that it's hard to demonstrate a vulnerability doesn't mean it doesn't exist!
Re: (Score:2)
Here is a JavaScript sample here from authors website https://mdsattacks.com/ [mdsattacks.com]
Re: (Score:2)
Re: (Score:2)
You have it backwards. If only the bad guys write attack code, there is no public PoC, but the risk is real.
Re: (Score:2, Interesting)
Spectre, Meltdown, et al are all bullshit. The chances of any attacker not only getting into a hardened network, hardened computers on that network and somehow gleaning important information at 10 bytes per second in a huge, encrypted memory environment are basically impossible. This is an excuse for the hardware and software makers get people to give them more money.
Technically, they aren't even bugs, they are the way that modern microprocessors are INTENDED to work. For the tinfoil hatters, maybe they sho
Re: I think this is a bit overblown. (Score:2)
Re: (Score:2)
I'm glad I waited the extra couple years to do my new build. I was so close to buying Intel after dealing with shitty Phenoms for years. But now my Ryzen 3800x is running smooth as butter, and the 3000 series are immune to all the speculative execution attacks. I made sure to buy ECC memory to take advantage of that as well. I still have avoided buying any Intel CPUs. I did break down and get an Intel SSD once, but I'm using Samsungs in my new build.
My only complaint is a lot of the Ryzen 3000-compatible mo
Re: (Score:3)
Dude. Asus AMD boards are worst of the breed. Only 4 vrms that get 100c hot! It won't last.
For the 3800x and 3900x you need the expensive top tier boards with x570 and not the Bs. Gigabyte master is top rated with the most horrible bios. MSI Ace is 2nd place and I own the Intel version of the board. Don't get the Godlike as it is $$$$ but it's not cheaper ACE Meg has same vrms. Just no liquid nitro support for overclocking or 3 nvme cooler covers for raid 0. You still can do raid but only one hascmetal plat
Re: (Score:2)
Second, low end ASUS for AMD is particularly bad. If you are spending under $300 then MSI is a great choice with ASRock as the runner up.
Re: (Score:2)
When did this happen? AMD chips are faster than Intel already. AMD shit canned the horrible Bulldozer architecture and hired Apple/Alpha chip designer to create Ryzen.
AMD demolishes the i9 https://www.trustedreviews.com... [trustedreviews.com] even on single core benchmarks
Re: (Score:2)
Not if you believe PC World.
Oh, wait ...
Re: (Score:2)
The recent 3000 series? Not the 1st Gen Ryzen?
Re: (Score:2)
Unfortunately I don't think one series of successful AMD processors is going to convince corporations to change right away. That includes the IT department I currently head. There are a few reasons for that:
- Past reputation of AMD processors is meh! Nobody was going to hang their reputation for $100 - 200 saving per workstation
- Because Intel was the go to, there was/is a larger hardware offering to satisfy wider spectrum of needs.
- Lots of software maker build their application around Intel processors, h
Re: (Score:3)
Modern processors aren't designed to leak information - that they do is unavoidable* but not something designed for. Thinking they are are clear indication of either not knowing shit or being the tinfoil hatter...
(* realistic shared resources always leak some information however most leaks are so noisy they aren't a problem, the new generation of attacks aren't noisy enough)
Re:I think this is a bit overblown. (Score:5, Informative)
A huge portion of services is running on cloud-based virtual computers (like on Amazon Web Services or Microsoft Azure). You don't need to hack to get on a server, you can simply buy a slice of computing power from the said service providers. And because these flaws make it possible to get data across virtual servers, this is a problem. At 10 bytes per second, you can get 315 MB per year in a single instance, and one can easily replicate that over a huge number of servers. That's a pretty high possibility to get something of significance, like cryptographic keys - especially since the important pieces of data are often such that they're loaded in memory, and often in multiple copies.
The issue with this kind of side channel attacks is that it often doesn't need any other vulnerability to be able to exploit these, and they are able to cross so many security borders. You don't need root access or anything such, it is enough to be able to run some code in some sort of environment (even JavaScript that has been sandboxed) to exploit these vulnerabilities. Sure, there are situations where these don't matter - like a non-virtual server only running trusted code, but there are also even more situations where these do matter.
Re:I think this is a bit overblown. (Score:4, Interesting)
Re: (Score:1)
These types of attacks are about more than just servers running on the cloud. They're also potentially attacks against web browsers running multiple tabs. Malicious Javascript in one tab could steal your banking information from another tab, even if the Javascript is run in a sandbox and each tab is run in a separate process.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Indeed. The goal here would be to, say, making a 128 bit key take > 100 years to sniff. That would probably defeat this attack. But getting the numbers right is really hard and would probably run into issues with the attack itself getting better.
Re: (Score:2)
This is actually very hard to get right. You need to make sure the original signal is far enough below the noise-floor and your jitter must be crypto-quality. Even then, the attack just takes longer. It may be possible to make the attack take a few 100 years that way, but this is very hard to assure.
Re: (Score:2)
Then disable JavaScript. If you do not permit other people's untrustworthy code to execute on your computer, there is no problem.
Re: (Score:2)
Have you actually tried browsing (or better said, using, as a lot of it is interaction and not just about looking at stuff) the Internet without JavaScript recently?
Re: (Score:2)
Not overblown at all. As soon as somebody publishes a reliable exploit, anybody can attack these vulnerabilities on the cheap. Your set-up may still be secure (mine is likely too), but anything in clouds is at risk and that is a lot.
Then walk over to AMD (Score:5, Insightful)
If yes, buy it and support that product
Choose a different brand.
Re: (Score:2)
Yeah, golly, it sounded like their "two options" were leaving out something!
Re:Then walk over to AMD (Score:4, Insightful)
AMD CPUs are the best choice for most people right now. A few Intel models can get a few percent better performance on the odd game or benchmark, but also cost a lot more. Unless your primary interest is topping benchmark league tables you should get a Ryzen.
Re: (Score:2)
I'd like to hear from AMD about these issues. They keep saying they are secure but are they?
The real big thing is that AMD CPUs are not vulnerable to Meltdown, the worst of these attacks, but ultimately that's just one of many, and an easier one to fix. And indeed Intel fixed it in its latest CPUs.
But AMD doesn't do magic, they also use speculative execution, caches, and therefore are susceptible to timing attacks. So, generally, everything that applies to Intel applies to AMD (and ARM) too, even if some sp
Re: (Score:3)
AMD uses secure instructions for their SMT. Internally each thread has an I'd and is partitioned in hardware on the chip. Intel has no concept as it was designed in the 1990s. AMD V has security built in as well which Intel- VT does not.
Intel will need to redo these from scratch which is difficult as it would break comparability.
Intel never updated their shit from when Windows98 was Kong where everything was local admin and it shows
Re: (Score:3)
AMD has different branch-prediction. The trick in the Spectre attacks is to train the branch predictor to make the wrong jump at a specific point so the CPU speculatively executes to some place it is not supposed to. For the Intel branch-predictor, this is apparently pretty easy and the resulting attack is still hard to do. For the AMD branch-predictor, this is apparently pretty hard and may just make the attack overall infeasible on AMD.
Hence it is unknown whether this works in practice on AMD. It is known
Re: (Score:2)
Re:Intel's quiet war to avoid redesign (Score:5, Interesting)
In the fabrication world it takes about 5 years between initial design and production. For instance AMD's chiplette designs started ~8 years ago now. Being generous to Intel, lets suppose they began a redesign to fix their security nightmare early last year, then they are still about 3 years away from producing a chip without the flaws.
Dropping a bit of the generosity, Intel also has to contend with skipping 10nm and coming up with their own chiplette designs (they cant go back to the Pentium 4 "dual core" chiplette design because that also brings back everything else of their horribly performing netburst era.) The only time Intel has been able to race a design to production (~2 years) was the Core 2 series, because that was just reverting back to the Pentium 3 design and upgrading their hyperthreading to a full second core.
I'm been saying this for years here: Sell your Intel stock. Make sure your 401K's and Roths arent anywhere near Intel. Intel is completely fucked, and Intel has known it at least since their first round of massive layoffs and their announcement of a new "cloud strategy."
This isnt like a retail store that can go under overnight. Its slow motion. The killing blow has already been dealt by the rent-a-fabs. Intel is ragdolling into the gutter.
Re: (Score:2)
Cloud strategy is exactly where these bugs bite them, too.
Re: (Score:2)
Sadly, enterprises are still buying Intel. They are probably getting a discount, but Intel has inertia. They have long been shady, and a worse deal than AMD, but that hasn't stopped them before, why should it stop them now. Lots of people around here are willing to make excuses for Intel about how these exploits don't matter because they are difficult to execute. Intel can sell that same story to probably the majority of high dollar decision makers. If they were intelligent, discerning, or scrupulous, they
Intentional NSA backdoor? (Score:1)
Re: (Score:2)
More likely is that the easy solution to the problem of speculative memory access is just wrong from a side channel standpoint.
Re: (Score:1)
The TPM chips - Intel Management Engine, and AMD's version fTPM - are where the backdoors are installed. Notice that both manufacturers started putting it on all their boards at the same time. Someone went to both companies, and made them an offer they couldn't refuse.
In the late 90s, Congress tried passing a law mandating that all computers include a TPM. That proved to be unpopular. When it couldn't be done legitimately - by vote - they went to the manufacturers in secret. By 2005 you could not buy a des
Re: (Score:3)
>"Sadly, enterprises are still buying Intel. "
They don't have a whole lot of choice, because the high-end "enterprise" equipment they need has all been based on Intel by the big players that can support it (HP, Dell, etc). But that is likely to change now. They can't afford to keep ignoring AMD, and customers are likely to start demanding additional options.
Re: (Score:2)
Lots of VPS hosts, data centers, etc. are still buying Intel. And that's where you'd think AMD would shine - excessive amounts of cores, and not much gaming or multimedia workload. Intel's advantage in the cloud/virtualization space disappeared as soon as Spectre and Meltdown came out. Whether it catches up to them remain to be seen
Re: (Score:2)
Intel just works. AMD is less reliable. Chipsets, internal qa, support from vendors, etc. AMD is starting to work on this but no one wants a server that has reliability problems or weird chipset quirks which AMD outsourced design to ASmedia to cut costs.
It will be years before AMD can make inroads in the data center again
Re: (Score:2)
Re: (Score:2)
I wonder how long Intel has known about this problem.
They've known it was possible from the design stage. They just hid their heads in the sand. Intel has been taking risks like this for performance reasons, it's how they've maintained their advantage of AMD who was doing things right.
Re: (Score:2)
Pretty much this. For these 3 years, they have nothing and when they have something, it will be slow and have other issues, as it was designed in haste. At the same time AMD will have its 3rd generation of a much better design out.
Intel has gigantic financial reserves, so they may survive this, but this is in no way assured.
Re:Intel's quiet war to avoid redesign (Score:5, Informative)
Wrong: POWER actually does have the same problem. It's often overlooked that IBM pulled exactly the same shady shit as Intel. At least POWER7 through POWER9 are vulnerable to MELTDOWN.
AMD has come out of this looking like a goddamned hero.
Re:Intel's quiet war to avoid redesign (Score:4, Informative)
No they don't - there is no way to use the Meltdown attack on any AMD chip as they simply don't have the same issue.
Re:Intel's quiet war to avoid redesign (Score:4, Interesting)
Re: (Score:2)
Correct on all counts. AMD at least tried to do the right thing, and they consequently put together a more secure CPU. Without these differences Intel would have had no performance advantage over AMD, despite their process advantage, and with mitigations taken into account, AMD is now faster. They've always been a better value (save perhaps the original K6, which had too narrow a FPU) but now they're also performance leaders - if you care about security.
Intel is sleazy in every feasible way, from business p
Re: (Score:2)
Any architecture that runs speculative out-of-order execution will absolutely be vulernable to at least some Spectre variant.
We've know about timing attacks for almost a decade but up until the first Spectre attacks (the people who developed spectre called it that because they knew it would haunt computing for years) were demonstrated no one thought it was possible to execute a timing attack.
Once the barn door was thrown open with Spectre and Meltdown attacks the variants have been fast and furious as each
Re: (Score:2)
Any architecture that runs speculative out-of-order execution will absolutely be vulernable to at least some Spectre variant.
Data leakage is through non-restored state after bad speculation. If the state was restored, then Spectre attacks would have nothing to work with. AMD is immune to Meltdown because speculation checks privilege levels before state is altered.
So there are structures which could be added to prevent Spectre style attacks while still allowing speculative execution. These might take the form of something like duplicate cache and buffer structures or perhaps victim cache which restores the state of the main cac
Re: (Score:1)
On the subject of security issues that only affect Intel and not AMD;
Foreshadow, Meltdown, TLBleed and the ever popular ME, (Intel Management Engine).
There may even be more CPU security issues affecting only Intel today.
Re: (Score:2)
Re: (Score:3)
the same shady shit as Intel.
The fact that so many chip makers have this problem makes me think that its less about shady dealings and more the common issue that engineers and developers don't consider security. Putting security first is hard and a new paradigm. For tech professionals who have spent their entire careers working through different models it can be hard to adapt to. I think this just shows how pervasive the mindset is in the industry and hardware design will require the same overhauls that software design did to account f
Re: (Score:2)
Security is part of the job. The Intel chips don't check security after the access by accident, that decision can only have been made consciously. Whoever made the decision probably thought it would be good enough, but pretending that the security features of the CPU were meaningful in certain ways in which they knowingly didn't make them was fraud.
Re: (Score:2)
Security is part of the job. The Intel chips don't check security after the access by accident, that decision can only have been made consciously. Whoever made the decision probably thought it would be good enough, but pretending that the security features of the CPU were meaningful in certain ways in which they knowingly didn't make them was fraud.
Intel's vulnerability is a side effect of their design which checks for exceptions during instruction retirement which simplifies exception handling. Unfortunately however this means the state of cache and buffers is altered by bad speculation.
System Sharing (Score:5, Insightful)
All these problems arise from code running for different users sharing the same hardware.
Own or rent the whole box and run only the software that serves your interests and cross core/cross thread/cross VM attacks are moot. Your adversary is on a different box, unless you really messed up.
Re: (Score:2)
Re:System Sharing (Score:4, Interesting)
You hope your adversary is on a different box. If you are renting servers from Amazon, how will you know who is sharing your CPU?
By paying by the box rather than the VM instance. This is already a common cloud service feature for governments that demand it. A rare occasion where governments get security right.
Re: (Score:2)
What about running an untrusted application in a sandbox? Is that not valid?
Re: (Score:2)
No, sandboxing is not enough; a major problem with these vulnerabilities is that they allow sandboxed applications to extract data from other processes running on the same machine. The basic problem is that these are hardware flaws, so they're very hard to mitigate at the software level. You can probably do it by doing things like flushing the cache when switching between programs, but that undermines a lot of the performance advantages the clever hardware was supposed to achieve.
Re: (Score:2)
Indeed. And that is the whole problem here and that is also why Intel is so desperate to gloss over this thing. You really only have a choice between security or performance on Intel and there will be stretches were you do not get that security even if you chose it.
Re: (Score:2)
I didn't mean to say sandboxing would fix the problem. I was replying to TechyImmigrant's claim that running untrusted processes on the same system is somehow wrong, and the implication that these problems are our fault when they occur. That's nonsense.
Re:System Sharing (Score:4, Insightful)
Re:System Sharing (Score:4, Interesting)
Re: (Score:2)
Unfortunately, web-servers are running code on your machine too these days, and do so in what looks like pretty ordinary web-surfing. The only way to be really secure is to use a dedicated machine for web-surfing on which you do not crypto and have no sensitive information. Also, singel-tab surfing whenever you log in to something may become necessary eventually, depending on how reliable and powerful the eventually available exploit code will be.
All this is so much hassle, that moving to AMD (not immune, b
Re: (Score:2)
The critical difference is that web-servers will run only interpreted script on your machine by default. You can mitigate the attacks by adding jitter to the time measurements available from javascript.
Using ad-block, noscript or uMatrix is a good idea. Getting an AMD processor is a good idea too.
Re: (Score:2)
The critical difference is that web-servers will run only interpreted script on your machine by default. You can mitigate the attacks by adding jitter to the time measurements available from javascript.
That is tricky to get right. It would be nice if that solves the issue. But if it only reduces the signal, the attacker just needs a bit longer. Hence, with a thorough mathematical analysis and a secure implementation ("crypto-quality" jitter) I would welcome such an approach.
Agree to the rest of your statement.
Re: (Score:2)
GPS SA gets this right. The offset is random but varying at a much lower frequency than the signal of interest and the mean takes a long time to discern and tells you nothing about the current offset. To get around it you need a fixed reference (like differential GPS does).
For crypto purposes, this is harder. Trying to suppress a signal with noise is a loser's game.
Better still to use modes of operation that makes iterative inference impossible, such as changing the key and data every iteration through a bl
Re: (Score:2)
Problem is renting a box doesn't scale. If you website suddenly gets Slashdotted then your box melts and the site goes down.
That's why everything is moving to VM instances in the cloud. When traffic goes up the system automatically spins up some new instances on its pool of servers and keeps the service responsive. You don't have to pay to run all those servers 24/7 just waiting for the next hit.
Re: (Score:2)
Just pray that you don't fall victim to some zero-day RCE in a service you run.
Re: (Score:2)
>Just pray that you don't fall victim to some zero-day RCE in a service you run.
What makes you think everyone uses cloud computing to run services?
A lot is to do compute tasks on large numbers of machines simultaneously. I've done it. A month to compute on a fast PC. $100 gets it done in a few hours. A bargain when you have a product to design. Write your code to cope with 2+ machines and you can easily dump it on 1000 cloud machines if you need to.
CPUs are cheap... (Score:2)
How many VMs/containers do people typically run on a single server? In my (admittedly limited) experience, it generally is somewhere around the number of processor cores.
If this is the case, then one solution would be to dedicate a CPU to each VM or container. Excess CPUs can be allocated dynamically (with performance hits). This obviously eliminates a lot of flexibility, but would eliminate nearly all Intel security issues.
Re: (Score:2)
Hahaha. More like 16 VMs to a CPU for windows desktops, and 8-20 per CPU for servers. More at cheaper levels.
Re: (Score:2)
You do realize what it would do to performance to force assign a physical CPU to each VM right?
In all the hypervisors the virtual CPU and physical cpu are completely untethered. None of the virtual machine systems are designed to tether a VM to a physical CPU, though in some you can, but the performance hit to do so would be pretty significant. And it's not just the CPU's, it's the memory too. To tether the VM to a physical cpu and specific memory space would be devastating to performance, you'd be better
So you flush buffers (Score:1)