Intel CEO: Patches will come to 90% of chips in the next week
techcrunch.com
techcrunch.com
As for Spectre, these are just the microcode updates that have the additional MSRs that allow system software to mitigate certain variants of Spectre attack against the system software itself. They are necessary, but emphatically not sufficient -- and it would disingenuous for Intel to pretend that this in any way means that 90% of systems are protected from Meltdown and Spectre.
EDIT: thanks for the update (or did I misread earlier?).
By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
The FreeBSD Security Team was notified of the issue in late December and received a briefing under NDA with the original embargo date of January 9th. Since we received relatively late notice of the issue, our ability to provide fixes is delayed.
Meltdown (CVE-2017-5754) ~~~~~~~~~~~~~~~~~~~~~~~~ In terms of priority, the first step is to mitigate against the Meltdown attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for this is ongoing, but due to the relatively large changes needed, this is going to take a little while. We are currently targeting patches for amd64 being dev complete this week with testing probably running into next week. From there, we hope to give it a short bake time before pushing it into the 11.1-RELEASE branch. Additional work will be required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE.
The code will be selectable via a tunable which will automatically turn on for modern Intel processors and off for AMD processors (since they are reportedly not vulnerable). Since the fix for Meltdown does incur a performance hit for any transition between user space and kernel space, this could be rather impactful depending on the workload. As such, the tunable can also be overridden by the end-user if they are willing to accept the risk.
Initial work can be tracked at https://reviews.freebsd.org/D13797. Please note this is a work in progress and some stuff is likely to be broken.
Spectre (CVE-2017-5753 and CVE-2017-5715) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When it comes to the Spectre vulnerabilities, it is much harder to sort these out. Variant 1 (CVE-2017-5753) is going to require some static analysis to determine vulnerable use cases that will require barriers to stop speculation from disclosing information it shouldn't. While we haven't done the analysis to determine where we are vulnerable, the number of cases here are supposed to be pretty small. Apparently there have been some Coverity rules developed to help look for these, but we are still evaluating what can be done here.
The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier as it affects both normal processes and bhyve. There is a proposed patch for LLVM (https://reviews.llvm.org/D41723) that introduces a concept called 'retpoline' which mitigates this issue. We are likely to pull this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately, the currently supported FreeBSD releases are using older versions of LLVM for which we are not sure the LLVM project will produce patches. We will be looking at the feasibility to backport these patches to these earlier versions.
There are CPU microcode fixes coming out when in concert with OS changes would also help, but that's a bit down the road at the moment.
If anything significantly changes I will make additional posts to clarify as the information becomes available.
Best regards, Gordon Tetlow with security-officer hat on
Anyone else thinks this was kind of a slap in the face to the smaller communities and companies or is it just me?
They were notified in late December, right before the holidays, so that's basically only 2-3 weeks of work. Obviously nobody _had_ to notify anyone, could have just released it right away, so it was a professional courtesy, but why not extend it to a few more projects?
Before anyone says "but OpenBSD broke an embargo before", this is a different project and besides having BSD in the name don't see why they were excluded.
Indeed. There seems to be a security oligarchy now consisting of Google, FB, Apple, Amazon et al. and Intel.
Intel and Google don't have a leg to stand on: I'm super glad they found the bugs, but their disclosure has been nothing but a shitshow.
AFAIK they all share the same brand name BSD and they are all closely affiliated.
This is a gross falsehood.
They all variously diverged from a parent project, called BSD, in the 90s. Since then they are wholly independent. Because of the common license and heritage, code sharing is often easy and legally unrestricted. But their leaders, policies, and philosophies are very distinct.
FreeBSD secteam does not leak NDAed or embargoed information to other BSDs.
Ubuntu 16.04 LTS: https://usn.ubuntu.com/usn/usn-3522-1/
Ubuntu 14.04 LTS: https://usn.ubuntu.com/usn/usn-3522-2/
Ubuntu 17.10: https://usn.ubuntu.com/usn/usn-3523-1/
Why is that? In theory, on a generic CPU, the microcode changes to stop Meltdown are drastically simpler than the mitigations for Spectre. Are Intel chips incapable of implementing them?
(And I'll laugh pretty hard if it's confirmed that these super-complex branch buffer adjustments are possible, but simple prefetch filters are just not possible on current Intel hardware.)
Does the update come in the form of a BIOS update? If so, then the patch still has to travel through the PC manufacturers, like when Google patches Android. Or can it be somehow applied directly?
Edit: Apparently the OS can update the CPU's microcode. No need for BIOS updates. It was even done in the past. For instance, an unrelated Windows Vista update that updates microcode: https://support.microsoft.com/en-us/help/936357/a-microcode-...
The real news here is that Intel thinks they can fix this via microcode. This is surprising because initially there were some strong arguments that this wouldn't be possible.
> The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems.
We still need the various manufacturers to release a BIOS version for a bunch of hardware they manufactured years ago. I'm not sure that's going to happen, at least not quickly.
[ 0.000000] microcode: CPU0 microcode updated early to revision 0x19, date = 2013-06-21
I think the rest of the cores get updated a bit later in the process.
In the early days after disclosure at least, a BIOS/firmware update for my machine (from Dell) was required to provide the necessary hardware support for their branch target injection mitigation. As far as I can tell, that's still the case today.
Perhaps they're waiting for the updates to be available for more processors before pushing an update?
However, there could be an issue where updating the microcode at kernel time can cause an issue due to a microcode version (or lack of) from the BIOS.
Only other thing I could think of is the microcode update that disables TSX, I believe, could only disable it if TSX wasn't used yet.
So I suppose it's also possible that the microcode has to be updated by the BIOS because some boot process prevents the kernel from being effective with its microcode update step.
EDIT: There are microcode updates included in the OS updates: https://access.redhat.com/articles/3311301
This crisis has taken Intel, in my mind, from an American behemoth at the vanguard of technology to a sclerotic overgrown mess. Bugs happen, crises happen. When you're a $200 billion company, those mistakes scale deafeningly. The bugs are unfortunate, but not unreasonable.
Intel's communication, however, from the first press release to crap like this, has been disingenuous to the point that it arouses suspicion. Why are they being dishonest? Is there something more to be discovered? What else have they lied about?
Textbook case of PR and IR incompetence.
Every geek I speak to will tell you the world's on fire. Every non-geek I speak to responds with "oh, really? if it's such a big problem how come no-one has heard about it? Oh, ok, well there might have been that one headline..."
I am infuriated by Intel's response no end, however I'm also somewhat impressed. They seem to have completely avoided a PR disaster and their stock price is largely unaffected.
My take on it is that non-tech savvy people are now largely desensitized to any vulnerability discovery, as long as it hasn't been exploited in the wild. Computers have bugs? What's new?
Intel's PR, good or bad, doesn't matter that much.
Meltdown/Spectre are severe and perhaps even unprecedented security problems but if you put them in the overall security context there are many other issues that outrank them at least from the perspective of non-technical users.
1. A majority of Americans using credit had their private data compromised in the 2017 Equifax breach. [0] That's just one of what are now countless breaches of data. The damage from Meltdown/Spectre is somewhat theoretical at this point whereas the data breaches have led to real fraud against countless individuals and business.
2. Even recent OS versions have large numbers of security bugs--see Greg Kroah-Hartmann's comments on obsolete kernels for specific Linux examples. [1]
3. State actors ranging from the US to North Korea have well-funded operations to steal or corrupt data. If they really want your data they will probably get it even if Meltdown/Spectre had not been discovered.
Finally it's only fair to point out that some of the claims of Intel being disingenuous on the august Hacker News forum [2] turned out to be overblown--other processors are subject to some of the same problems and many users will not notice much difference in the patched systems.
[0] https://www.consumer.ftc.gov/blog/2017/09/equifax-data-breac...
No-one really believes that the Norks with their steam-powered computers are hacking anything. Propaganda cuts both ways.
With that in mind, and assuming computer hardware is still being tossed away after such short times of usage (I'd wager PC hardware is used more, but mobile phones are still being tossed like candy paper), I wonder if any IBM clones ever reached North Korean soil. If North Korea speculated on Bitcoins, which they supposedly did (with which computers?), they got some nice income out of that as well. Or would you recon this is all done outside of NK borders e.g. by spies?
Intel is being very disingenuous when they say "contact your OEM/vendor for microcode updates". In consumer reality, vendors mostly won't provide updates, and even if they do, consumers won't install them.
The only practical way to deliver microcode updates to Windows users is through Windows Update, so the real question is when these will make their way to Windows Update.
Microcode updates that enable or disable various feature flags or patch the microcode used to interpret specific instructions from the outside CISC world to the native RISC world that all modern x86 processors use.
In terms of deployment, there is support for OSs to deploy microcode from Ring 0 each time the system boots, or the permanent fix is a new UEFI that includes the new microcode at system init.
Not saying that there isn't a scenario where it would be ok to turn that off, but it's the exception.
Is your machine internet connected?
Do you have any open ports?
Do you run everything as root?
If your answers are yes, no, no, and yes than it likely will make no difference. Otherwise (and the last one is just for fun to attempt to show you this is probably not a wise decision) you probably would do better to take this serious.
Exploiting meltdown means you can read all of kernel memory, that destroys any additional layers of protection you might fantasize you had. It means that in memory passwords and encryption keys can be copied. It means that IO between other processes can be spied on. It means that all of the juicy locations to exploit for "return oriented programming" in order to gain local root will be laid bare. And so on.
That's why it's called meltdown. Imagine someone who had hand crafted the equivalent of a modern OS with all of the best practices in place for an internet server. You have kernel address randomization. You have each service running as its own non-privileged user and also in a chroot jail. You have your filesystem permissions locked down tight. And so on. All of that is gone out the window with meltdown, it doesn't matter, because even code running at the lowest possible privilege level can gain access to the contents of any part of kernel memory.
As for "workstation" systems. If you are behind a firewall, you never run untrusted code, and you have JS disabled then potentially you are safe.
So worst case you compile your own kernel
> Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years
It's also unclear what they mean by "introduced within" Does it mean when the product was first developed? First on sale? If I bought a new computer 3 years ago what is the likely-hood that it's CPU was "introduced" much earlier?
5 years is Haswell, so Haswell and newer should get the microcode fix. A 3 year old computer is likely to have a CPU no more than 4 years old, but you can look it up to verify. (Both Windows and Linux can show the CPU model, and Intel's Ark site gives the release date.)
[1] https://ark.intel.com/products/series/75023/4th-Generation-I...
I'm becoming very pessimistic about how I can trust computers.
Computers can do amazing thing, but software seems fragile, unreliable and untrustworthy.
I have been keeping notes on paper for years now, and it doesn't look like it's going to change.
Internet is still growing, and so is the computer security economy. Look at all the data breaches and leaks.
So I just do not put all my eggs in the same basket, I do not store much personal information on my computer, I store even less online, I do not store any money/payment related information, and I just admit I will however sometimes get my butt kicked here or there.
It is like my house. Anyone can break in at any time, and steal my belongings. Do I install an armoured door? Do I build grids on windows? Do I install an alarm with a direct link to a security company? No, no, and no. I just lock my front door. It only protects from a part of opportunity robberies and that's enough for me. I won't take measures to prevent all other possibilities. They can happen at any time, with no difficulty. And so what?
Back to computers. So this very basic mitigation, very limited damage control is enough to make me feel OK. It feels better to admit insecurity as a given, than to constantly fight for a false feeling of security I cannot achieve anyway.
...and more importantly, not make our lives significantly worse in pursuit of that "perfect security".
Think about how many successful jobs computers have done for you/us compared to how many breaches/failures actually occur.
We get overwhelmingly more stuff done with computers than without.
Even if I had to attempt to send an email 10 times before it worked, that's much more convenient than walking the actual distance and delivering it myself.
A stack of vulnerability whitepapers looks intimidating, but you're not getting the whole picture.
Not to mention the damage it can do to individual people, because it hard to measure.
AMD chips are reportedly susceptible to Spectre, so that's not going to help. From https://meltdownattack.com:
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
And Meltdown specifically only affects Intel processors.
Knowing that, can it be possible that Intel can patch their CPU via micro-code in a manner that does not affect performance to a great degree, and not require a software patch to solve the Meltdown attach ?
https://www.amd.com/en/corporate/speculative-execution
Ryzen is only affected by "Spectre variant one, Bounds Check Bypass"
It's fixed by OS updates with negligible performance impact expected.
Some reported instances:
https://community.amd.com/thread/215773?start=1635&tstart=0 (user jcoiner, 1726PGT)
https://community.amd.com/thread/215773?start=1725&tstart=0 (user scorpio810, 2x 1728SUS)
https://community.amd.com/thread/215773?start=1770&tstart=0 (user ryzlin, 1733PGT)
https://community.amd.com/thread/215773?start=1785&tstart=0 (user flyinryzen1700, 1737SUS)
https://community.amd.com/thread/215773?start=1830&tstart=0 (user skimba 1725PGT, user xtronom 1728PGT)
https://community.amd.com/thread/215773?start=1860&tstart=0 (user jc_yang, 1742SUS)
https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective... (user grosbof 1733SUS)
https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user triplesal, 1733PGS)
https://www.reddit.com/r/Amd/comments/7ar15o/psa_amazon_is_s... (user istockporno, 1726PGT)
Presumably this is something that will be fixed in the Zen+ stepping/Pinnacle Ridge (Ryzen 2 - not to be confused with Zen2, which will release in 2019?, likely as the Ryzen 3 series).
But for the meantime, be aware that you are absolutely buying silicon with known issues and that you should test it and RMA if necessary, and that there is fixed silicon coming within a couple months here that will probably run significantly faster due to process improvements.
Some of these elements are hardwired into the silicon, some are controlled via decode tables, and some are controlled via flags and perhaps even instructions running on different components of the CPU, all of that together is grouped under the heading "microcode". A modern CPU is not infinitely programmable because a lot of functionality is hardwired (for example, what each micro-op does) but there's still a great deal of flexibility in how things work (such as exactly how the branch predictor and scheduler work, the translation of instructions to micro-ops, etc.)
> We don't know.
So probably no reports ;)
edit: see below, not true; they haven't published it on their own site but have pushed microcode updates to redhat.
Seems to be taken from redhat updates. It's floating around unseriously in debian unstable instead of being a security update, I guess Debian's FOSS imperative doesn't mix so well with non-free (intel-microcode) updates.
> Anyway, uploading a partial, unofficial set of updates to unstable to close the bug. Several processors are still missing. I expect an official release from Intel soon, hopefully with updates for everything.
> Implements IBRS and IBPB support via new MSR (Spectre variant 2 mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
> LFENCE terminates all previous instructions (Spectre variant 2 mitigation, conditional branches).
Make a web page on the Intel site with concise, real information on what's going on and what to do. We're a week into disclosure and there's still no patch for most people's servers. A patch that takes up to a 30% performance hit but may not be necessary if there's going to be a microcode fix?
I know this is just a cute speech and debate practice session for the Intel execs, but I have servers that will have to get trashed because of the slowdown patch, they will be too slow to function in their current role and will need to be replaced. This is seriously affecting my life, my work schedule and my wallet. Please have real engineers provide real information here.
> He also said that Intel expects to issue updates
> to its processors soon. More than 90 percent will be
> getting them within the week, and the rest by the end
> of January.
90 percent of what?
It should be self-evident that Intel means 90 percent in whichever way gives them the largest percentage. I expect this means Intel discounts "older CPUs" that are "probably not in use." In other words, 90 percent of CPUs sold in the last N years for whatever N makes the percentage largest (5 years [1])
"The rest by the end of January" can be taken with a huge grain of salt. Intel is documenting and exposing an MSR to flush the [ed] branch predictor, but only for recent CPUs, and admits they aren't able to do so in a timely manner, or they would have said "100 percent."
[1] https://newsroom.intel.com/news-releases/intel-issues-update...
"Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years"
Edit: I incorrectly stated the MSR was for the TLB, it is not. It is for the branch predictor.
You write to CR3 register to flush TLB (or use INVPCID to invalidate just a subset of TLB). So not sure what that means, why would you need an MSR for that?
https://en.wikipedia.org/wiki/Intel_Quark (basically a die-shrink of a 486!)
... the rest by the end of January."
Not "the rest are not affected," or "the rest are intrinsically immune." If they were, Intel could have deflated a lot of the PR around AMD being immune while Intel is affected.
"Intel Quark SoC X1000 contains a bug #71538[11] that "under specific circumstances" results in crash, known in the industry as a segfault. The workaround implemented by Intel is to omit LOCK instructions in the compiled code.[12] While Yocto Project based embedded systems incorporate this workaround, general purpose Linux distributions such as Debian are deeply affected by the bug. Such a workaround is not easy to implement on multithreading systems as they require LOCK instruction to function properly."