This is only Spectre, not Meltdown. Meltdown requires KPTI, which depends on your OS. For OSs that did not enjoy months of advanced disclosure (which is: any OS that isn't Windows, MacOS or mainline Linux), that work is ongoing and will depend on the OS. (Speaking for SmartOS/illumos, that work is reasonably far along and making promising progress -- but we don't yet have a functional prototype.)
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.
What's the story for Illumos as to Meltdown and Spectre? I expect KPTI for Meltdown and then the same disable-speculation-for-indirect-call-in-kernel fix that everyone else is applying. With KVM the Illumos hypervisor should be free of attack, so maybe Joyent needs nothing more.
EDIT: thanks for the update (or did I misread earlier?).
> This is only Spectre, not Meltdown. Meltdown requires KPTI, which depends on your OS.
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?
I'm aware, that's why I asked. Do you know? Do you have a reference?
(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.)
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
> FreeBSD Security Team was notified of the issue in late December
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.
FreeBSD secteam was only notified — at all — because Netflix (a big FreeBSD user) requested it of Intel. It was a big slap in the face to smaller communities by Intel.
FreeBSD isn't two people in a garage, it's a foundational part of the internet developed by professionals who can be counted upon to do the right thing.
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.
I’m not arguing for or against anyone in particular getting notice. I’m just pointing out why they’d limit it in principle. You have the draw the line somewhere.
>>> 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.
AFAIK they all share the same brand name BSD and they are all closely affiliated.
> 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.
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?
Intel's not patching anything. They're relying on Windows, Linux and macOS patches to work around the vulnerability. Presumably that's how the 90% claim can be made. Very disingenuous of Intel tho.
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?
As much as I hate to say it, I think the Intel PR machine is working stunningly.
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.
> Every non-geek I speak to responds with "oh, really?"
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.
There's a 'too big to fail' thing going on here I think, because what you've said about Intel is exactly how I felt about Equifax's breach. At a certain point of terrible-ness people just shrug and carry on.
It's good PR. If a mainstream media outlet looks into it they are predisposed to "hear" two views and weigh them equally. They'll get one from the OS/Security community saying "this is really bad" and one from Intel (via their spokespeople) saying "don't worry about it, we got it". Then their journalistic tendency will be to give more weight to what Intel say over what a bunch of "nerds" say, and the resulting headline will be "Intel fixing chip bug some say is puts the cloud at risk" or some such nonsense.
I thinks it's more a case of bad "marketing" from project zero. Had the stuck with a single name "spectre" (with 3 variants) then the media would have had a story that's much easier to understand and repeat/sell. When it's a case of "x affects a" and "y affects a, b and c" then the story gets to confusing for them and their readers.
Without taking Intel's side there's another perspective.
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.
I was quite in the know in the 2nd hand PC market in the beginning of the '00s because one of the projects was I involved in was to get people who couldn't afford computer & internet access to our 2nd hand computer network, including with internet access. We were running practically on donated hardware (and ran on 100% free software), except for our main internal and public server which were purchased. It was called, translated, an "internet free place" because the word "[internet] pub" was protected by law. I suppose nowadays it'd be called a hackerspace of some kind but that word didn't exist back then. Now, if you'd seen the stuff which was thrown away... perfectly working computers from a few years old really. There were projects to get these to 2nd and 3rd world countries as well (though by other organisations than ours, since we were local to our city).
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?
I’m not saying what I believe but what the general public believes. Our leaders simultaneously tell us that the Norks are a failed state and are technically advanced enough to defeat the West in cyberwarfare. They can’t both be true.
They even tried to name the macro in Linux something like "INSECURE_KERNEL" instead of accurately describing that the insecurity lies in the CPU, not kernel.
I can download microcode updates for Linux from Intel's website, and IIRC Ubuntu has shipped microcode updates before. I know Windows Update does deliver microcode updates, but thus far I'm unaware of Windows Update distributing any for Spectre.
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.
My understanding is the hat they are only patching the indirect branch issue, so you’re still vulnerable to Spectre if you install the patches. They aren’t patching the (not indirect) conditional branch issue. That requires software changes or disabling speculative execution (which would have catastrophic perf cost).
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.
Those strong arguments were not coming from Intel. To me it's more surprising that someone not involved in the design of Intel CPUs can state what Intel can and can not do - after all, not that long ago people didn't even know the Intel CPUs ran a version of Minix (the Intel ME)
Yeah, well, let's not break out the champagne yet. According to your link:
> 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.
Microsoft is still saying that users need firmware/BIOS updates to be protected. Their messaging is at best confusing on this if they're going to apply microcode updates themselves.
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?
I think that claim is incorrect. I'd be surprised if Windows Update didn't download and load updated vendor microcode, and most Linux distributions do (or can), too. At least, I know Fedora does it by default.
Like others have said typically the microcode update is applied by both the BIOS and kernel. Typically the kernel has the latest microcode.
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.
I think it's more accurate to say that they believe they can fix this with a combination of SW + microcode. The microcode is a sort of HW assist for the new defensive measures. If you don't also update kernels, the new microcode is useless.
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.
What I'm worried about is that it will be hard to avoid these security patches when you don't need them. Say you have a non-virtualized, non-shared server that only runs your own trusted code. I don't want to be forced to pay the performance penalty but it might be unavoidable without resorting to maintaining your own linux fork.
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.
For private servers that are totally not connected to the internet in any way and don't need to be, run self-developed code on data which is mainly CPU-bound but also need a lot of disk IO for reading files and memory mapping data, I'm pretty certain it'll make a noticeable difference, for no security benefit.
In the short term, maybe. But the OS update processes are incremental. If the user wants to upgrade their OS version for some reason (new feature, etc), they will get the performance hit bundled together.
For an average user that doesn't bother with security to the point that nothing on the server runs in sandboxes - Spectre and Meltdown are not of much concern. Running under a different user is not the same as running in a sandbox, certainly not on linux/bsd/windows. A user still has an enormous attack surface to play with. And due to the nature of multiuser software typically running on servers where all users live within the same trust boundaries any exploitable vulnerability is going to do as much damage, as if it was running under root, think Cloudbleed for example. You can't make things noticeably worse by turning off KPTI.
Open ports mean there is a service listening. A service listening means that there is code on your box interfacing with the internet. That means there is the possibility that an exploit in that code could lead to remote code execution. The meltdown vulnerability means that any remote code execution vulnerability can be escalated to the highest levels.
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.
But on my home server, I don’t have layers protection and I don’t need them. If there is RCE that gets you into my RDP session, or my email, etc., you’ve got everything in the machine that’s worth having.
What happens when your trusted code gets exploited? That's also the reason why we have overhead in the form of ACLs, memory protection, ASLR, packet filtering, deprivileged processes, seccomp sandboxes, etc. even though in principle we're all running "trusted code".
Not saying that there isn't a scenario where it would be ok to turn that off, but it's the exception.
Other commenters have addressed turning off kpti (nokpti boot flag), and Linus has said any additional protections should be toggle-able: https://lwn.net/Articles/743712/
(on linux) there's a way to disable it. AFAIK you add 'kpti=off' to the kernel command-line which is possible, e.g., by pressing 'c', from grub. IDK about other OSes.
> 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?
Presumably the launch date, Intel lists launch dates for all of their processors on ark.intel.com [1]
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.)
Thanks. My work computer is in the legacy section (release Q4'11), so it looks like I might be getting a new one. A shame really, it's still mostly adequate, the only thing making it age are the continued bloat from Visual Studio.
It's been a while I don't bother much about security any more, because I consider everything insecure.
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.
Internet-connected computers are more secure now than they ever have been. Just take the standard precautions: update your OS and don't install untrusted apps.
Even trusted webpages pull in crap from all sorts of places that I don't trust, the way the web is structured is a disaster. My public news provider for instance (http://www.abc.net.au/news/) has all sorts of shit broken when you run ublock or noscript. There "live breaking news feeds" that are rather important may as well be a blank page because it just reposts twitter messages. And they're one of the better sites with no advertising.
>Computers can do amazing thing, but software seems fragile, unreliable and untrustworthy.
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.
You're right, but computer security can become an issue, and it can do incredible damage. It's a new threat, so it is creating new problems that must be solved, and quickly.
Not to mention the damage it can do to individual people, because it hard to measure.
Surely he is talking about the Win/Mac/Linux kernel patches? Would seem bizarre for all the work to go on the kernels when Intel had some firmware patches up their sleeve? Also I thought Spectre is something that is unlikely to be patched in the near future.
I believe there are microcode patches that help make spectre harder. I also have a vague recollection of the fix for meltdown on the newest CPUs requiring a microcode patch for complete protection.
It was meant to be embargoed til today, but the news came out earlier than expected. Sounds like people have been working round the clock since the discovery to patch this.
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.
AMD is not susceptible to Meltdown. So the issue is not inherent to the x86_64 architecture.
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 ?
My response was in the context of privong stating that Intel and AMD were equivalently affected, when it is specifically Intel that suffers performance degradation in patching due to their unsafe usage of speculative execution.
I only said they were both affected by Spectre. But it wasn't clear if the OP was worried about performance issues or security issues, so it isn't clear on what basis they were suggesting that buying AMD is a solution.
How common is the Linux segfault problem on Ryzen now? Just reading about the horrible RMA procedure puts me off AMD unless they can clean up their terrible handling of this problem.
It's still out there. To be clear, virtually no chips before Week 25 pass the segfault test, a large number of chips afterwards pass the segfault test. AMD clearly either upped their production standards or is binning out the worst chips. But there is still a baseline of chips failing.
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.
CPUs have code that runs code, essentially. Think of a modern CPU as like a collection of micro-controllers. You have micro-controllers which reads a stream of machine code instructions for a particular instruction set (e.g. x86-64) translates that code into "micro-ops" (RISC-like fine grained instructions) that are then re-ordered and so forth and fired off into the CPU core(s) proper. That whole process relies on a ton of code that exists as essentially "firmware" (microcode) within the processor. Things like translation tables for architecture level instructions (x86-64) to micro-ops as well as code for the scheduler, the branch predictor, and various other micro-architectural parts of the CPU.
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.)
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.
This is how this terrible CEO tells us about microcode fixes, at a CES speech? Or is he even talking about a microcode update, or about the patches everybody else has been losing their lives working on? What a crap response to such a huge and existential issue.
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.
Let me break down what the article really says (it's pretty short):
> 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.
Intel expects 90 percent will "get an update."
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."
"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.
Just read the Wikipedia, looks like you are trading one hardware bug for another on the Quark. At least you know when a segfault happens I guess.
"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."
"Intel expects to issue updates to its processors soon.
... 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.
> exposing an MSR to flush the TLB, but only for recent CPUs
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?
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.