
Intel CEO: Patches will come to 90% of chips in the next week - elektor
https://techcrunch.com/2018/01/08/intel-ces/
======
bcantrill
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.

~~~
8_hours_ago
FYI, Ubuntu released updates today for Meltdown:

Ubuntu 16.04 LTS:
[https://usn.ubuntu.com/usn/usn-3522-1/](https://usn.ubuntu.com/usn/usn-3522-1/)

Ubuntu 14.04 LTS:
[https://usn.ubuntu.com/usn/usn-3522-2/](https://usn.ubuntu.com/usn/usn-3522-2/)

Ubuntu 17.10:
[https://usn.ubuntu.com/usn/usn-3523-1/](https://usn.ubuntu.com/usn/usn-3523-1/)

~~~
tannhaeuser
Would you know if the patches are or will be included in the mainline kernels
which are at 4.4.14 and 4.4.15?

------
maltalex
How does one patch a CPU?

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-...](https://support.microsoft.com/en-
us/help/936357/a-microcode-reliability-update-is-available-that-improves-the-
reliabil)

~~~
donaldihunter
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.

EDIT: There are microcode updates included in the OS updates:
[https://access.redhat.com/articles/3311301](https://access.redhat.com/articles/3311301)

~~~
JumpCrisscross
> _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?

Textbook case of PR and IR incompetence.

~~~
BuildTheRobots
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.

~~~
jayflux
Is that really good PR? Or just news that hasn't hit the mainstream because
they don't understand it or doesn't affect them much.

~~~
cratermoon
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.

~~~
flukus
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.

------
guelo
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.

~~~
jacquesm
Do you trust all of the userland?

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.

~~~
rayiner
How do open ports factor in? And what if you’re internet connected but have JS
disabled?

~~~
InclinedPlane
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.

~~~
rayiner
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.

------
flukus
According to last weeks press release, they mean 90% of recent chips, which is
far less than 90% of intel CPU's out in the wild:
[https://newsroom.intel.com/news-releases/intel-issues-
update...](https://newsroom.intel.com/news-releases/intel-issues-updates-
protect-systems-security-exploits/)

> 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?

~~~
petascale
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.)

[1] [https://ark.intel.com/products/series/75023/4th-
Generation-I...](https://ark.intel.com/products/series/75023/4th-Generation-
Intel-Core-i7-Processors)

~~~
flukus
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.

------
jokoon
I wonder what will the next big security hole.

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.

~~~
sigmar
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.

~~~
jacquesm
And do not visit untrusted webpages with javascript enabled? And how do you
know which pages you can trust?

~~~
flukus
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/](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.

------
dm319
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.

~~~
rocqua
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.

------
dooglius
If Intel knew about the issues on June 1, why are the patches only appearing
now? I thought the point of an embargo was to let the fixes come first.

~~~
dm319
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.

------
pdelbarba
So when will chips with a fix in silicon be available?

~~~
welder
Just buy an AMD chip right now.

~~~
privong
> Just buy an AMD chip right now.

AMD chips are reportedly susceptible to Spectre, so that's not going to help.
From [https://meltdownattack.com](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._

~~~
lawrenceyan
Meltdown, however, is the one that results in nontrivial performance
degradation in order to patch.

And Meltdown specifically only affects Intel processors.

~~~
onedognight
Meltdown affects some ARM prcessors as well.

[https://developer.arm.com/support/security-
update](https://developer.arm.com/support/security-update)

~~~
lawrenceyan
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.

~~~
privong
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.

------
dmitrygr
Keep in mind, they did NOT say patches with no cost. Mostly they are adding
ways to disable speculation on indirect branches. This has a cost.

------
phkahler
I half thought he was going to talk about using ME to push updates to Intel-
based machines. Thank god they have a backdoor to fix security issues! ;-)

------
donaldihunter
[https://support.apple.com/en-us/HT208394](https://support.apple.com/en-
us/HT208394)

------
zeep
10% equals how many billions of chips?

------
maltalex
Any guesses as to which vulnerabilities they're going to patch? Some of them?
All of them?

~~~
pizlonator
Just the indirect branch bug. That’s “half” of Spectre. IMO the harder to
exploit half.

------
quadcore
How do you patch a CPU remotely? Are the instructions programmable?

~~~
InclinedPlane
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.)

------
lifeformed
Have there been any reports of exploits using Meltdown/Spectre in the wild
yet?

~~~
Tom4hawk
[https://meltdownattack.com/](https://meltdownattack.com/) > FAQ > Has
Meltdown or Spectre been abused in the wild?

> We don't know.

So probably no reports ;)

------
y3sh
At what performance cost?

------
glandium
I thought they already provided a microcode update?

~~~
nickysielicki
Latest version on downloadcenter.intel.com is 20171117; no microcode update
has been published since Spectre/Meltdown have been disclosed.

edit: see below, not true; they haven't published it on their own site but
have pushed microcode updates to redhat.

~~~
kzrdude
There's a partial update package debian: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=886367#22](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=886367#22)

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).

------
kyledrake
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._

~~~
sounds
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."

[1] [https://newsroom.intel.com/news-releases/intel-issues-
update...](https://newsroom.intel.com/news-releases/intel-issues-updates-
protect-systems-security-exploits/)

"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.

~~~
userbinator
...or maybe the other 10% are in-order non-speculative designs which are
intrinsically immune; they still have a few:

[https://en.wikipedia.org/wiki/Intel_Quark](https://en.wikipedia.org/wiki/Intel_Quark)
(basically a die-shrink of a 486!)

[https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)](https://en.wikipedia.org/wiki/Bonnell_\(microarchitecture\))

~~~
planteen
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."

