
Intel Issues Updates to Protect Systems from Security Exploits - runesoerensen
https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/
======
illumin8
Why did CERT modify their vulnerability disclosure to remove the text:

> Fully removing the vulnerability requires replacing vulnerable CPU hardware.

Proof:
[https://webcache.googleusercontent.com/search?q=cache:rzc6iQ...](https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+&cd=4&hl=en&ct=clnk&gl=us)

This smells really bad to me, as if Intel pressured CERT into removing
language that could have caused their market value to instantly vaporize as
every consumer for the last 20 years joins a class action suit...

~~~
jve
I don't get these calls to a class action suit... If it was intentional, it
could have a reason. But I just don't get this attitude when they are having a
really bad day after someone discovered a new type of attacks on their chips.

~~~
pkd
Intel isn't having a bad day. The people who are stuck with chips that enable
severe security exploits are having a bad day. Actually they are going to have
a bad year till the design flaw is fixed in hardware. Or maybe even 5 years.
Who knows.

Intel is 100% liable to face a lawsuit over this. Consider if a major car
brake manufacturer discovered that there was a design flaw in the brakes that
prevented them from functioning in certain situations. It'd be facing multiple
lawsuits by now whereas Intel is going with "our chips are the most secure
ever" line.

~~~
GuB-42
I think you are confusing security and safety. Security is about dealing with
malicious attackers, while safety is about making sure random events and
mistakes won't kill you.

Your example with the brakes is about safety, i.e. making sure the car won't
kill you during normal operation. Normally, unless their CPUs start bursting
into flames, this is not a problem for Intel.

The problem here is about security. A car analogy would be that to start your
car, you need a code and that code can be found by measuring how long it takes
to process the input, making life easier for thieves.

As for liability, I don't think you can be liable in court if you didn't plan
for something that wasn't known at the time and isn't trivial.

~~~
iovrthoughtthis
Ironically, isn't your analogy a literal thing?

[http://www.bbc.co.uk/news/business-41367214](http://www.bbc.co.uk/news/business-41367214)

------
bpye
It looks like they expose some MSR to control the branch predictor, see:

[https://twitter.com/aionescu/status/948753795105697793](https://twitter.com/aionescu/status/948753795105697793)

[https://twitter.com/aionescu/status/948818841747955713](https://twitter.com/aionescu/status/948818841747955713)

~~~
cws125
It appears the retpoline fixes don't work in Skylake or later (it's smart
enough to speculate out of it?) and will require new support for IBRS/IBPB in
the microcode to mitigate.

From: [https://lkml.org/lkml/2018/1/4/615](https://lkml.org/lkml/2018/1/4/615)

~~~
j_coder
What I don't understand is why the kernel patches and microcode updates are
still been worked out today. They had 6 months to work on it.

No secret channel to communicate with Linux Kernel developers? No coordinated
effort? Last minute findings?

On this thread
[https://lkml.org/lkml/2018/1/4/174](https://lkml.org/lkml/2018/1/4/174) looks
like that the author is disclosing the info on the last minute.

~~~
geezerjay
IIRC Intel employs people to work on the linux kernel on behalf oh Intel.
Either Intel fumbled or it isn't that easy to circumvent the problem plaging
Intel's processors with a software hack.

~~~
hinkley
Or, they were holding out hope for a workaround that didn't make the entire
Cloud 20% slower and they couldn't make it work.

~~~
yndoendo
Code for the solution and then code for performance. Direct performance coding
is a bad return on investment.

First prove it works and then prove it can be made better and faster ...

~~~
hinkley
That’s easy for you to say. You’re not the person having to admit to a billion
dollar mistake.

Everybody stalls for time when the stakes are this high. How long can I
reasonably spend tying to turn this into a small problem before I have to go
public with it?

Saying it’s a bigger problem than it turns out to be is a PR nightmare of its
own. If there was a cheap fix then you cried wolf and killed your reputation
just as dead.

------
tasty_freeze
I'm disheartened by the number of comments here who are taking the stance that
Intel has idiot designers or that management doesn't care about security. This
attack is very clever and unexpected. Even though side-channel attacks have
been talked about for awhile, even the guy who developed Meltdown was
surprised that it worked. It just seemed like an "in theory" security hole,
not an exploitable one.

AMD isn't vulnerable to Meltdown not because they foresaw this issue, but
probably because they simply weren't as aggressive as Intel in allowing
speculative execution. For years people have preferred Intel over AMD cpus due
to their performance advantage, due in part to that higher sophistication of
their pipeline.

Or to recast it, nobody is hating on AMD right now, but AMD CPUs do allow a
user process to learn some things about the kernel via timing attacks. If next
month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly
idiots for missing an obvious security hole?

~~~
lawrenceyan
AMD did things the right way competing for performance without sacrificing
security. What's happening right now are the consequences of Intel's actions.

~~~
willvarfar
If AMD spotted the issue and avoided it deliberately all those years ago, why
didn't they tell anyone?

~~~
m_mueller
There is a difference between following good security practices (gratuitous
isolation, defensive design) and having exploits ready to show the world how
valuable it is. Noone was claiming AMD knew of such exploits beforehand.

------
carwyn
They are still sticking to this line:

"This is not a bug or a flaw in Intel products. These new exploits leverage
data about the proper operation of processing techniques common to modern
computing platforms, potentially compromising security even though a system is
operating exactly as it is designed to."

[https://www.intel.com/content/www/us/en/architecture-and-
tec...](https://www.intel.com/content/www/us/en/architecture-and-
technology/facts-about-side-channel-analysis-and-intel-products.html)

~~~
swsieber
Well, that's true (at least for the spectre attack). It's not a bug in _Intel_
products. It's a bug in _any CPU that uses branch prediction_ (please correct
me if I'm wrong, this is my current understanding)

~~~
betterunix2
The effect on Intel is far more severe than on other architectures. There were
three vulnerabilities, two grouped together as "spectre" and one called
"meltdown." Intel products are uniquely vulnerable to the meltdown attack,
while many CPUs are vulnerable to spectre. The summary AFAIUI is that for most
CPUs you can attack userspace processes with these techniques (think
Javascript running in a browser), while for Intel CPUs you can also attack the
kernel. Intel CPUs also seem to be somewhat easier to attack than others
because of a higher-bandwidth side channel.

~~~
bzbarsky
> Intel products are uniquely vulnerable to the meltdown attack

More precisely, there is only a PoC for Intel at this time. AMD processors are
believed to not be vulnerable. Some ARM processors _are_ believed to be
vulnerable.

> for most CPUs you can attack userspace processes with these techniques

Spectre can attack the kernel as well, at least according to
[http://www.tomshardware.com/news/meltdown-spectre-
exploits-i...](http://www.tomshardware.com/news/meltdown-spectre-exploits-
intel-amd-arm-nvidia,36219.html) . It's just harder to use than meltdown.

~~~
arohner
That link no longer loads for me.

AIUI, Spectre can be used to attack the kernel, only if you can get code
running in kernel-space, via, e.g. eBPF.

~~~
contrarian_
No, you could also find a gadget with ROP techniques. The eBPF thing in the
paper was purely due to convenience of exploitation.

------
lower
Lenovo has BIOS updates that specifically mention CVE-2017-5715 (Spectre). I
wonder if this is an Intel microcode update.

[https://pcsupport.lenovo.com/de/en/products/laptops-and-
netb...](https://pcsupport.lenovo.com/de/en/products/laptops-and-
netbooks/thinkpad-t-series-laptops/thinkpad-t470/downloads/ds120429)

~~~
reirob
For those like me are running Linux and asking how to update the BIOS, lenovo
provides a ISO file. Quoting from [1]:

"The BIOS Update CD can boot the computer disregarding the operating systems
and update the UEFI BIOS (including system program and Embedded Controller
program) stored in the ThinkPad computer to fix problems, add new functions,
or expand functions as noted below."

[1]:
[https://support.lenovo.com/fr/en/downloads/ds120430](https://support.lenovo.com/fr/en/downloads/ds120430)

~~~
duozerk
Yeah, basically all BIOS have that. Some simply need a FAT usb key inserted
with a specifically-named file that the BIOS looks for instead of a "true"
bootable media.

------
chrisper
And how do I get these firmware updates and microcode updates on Windows?

Checking AsRock, there aren't any Bios updates.

Also:

> Customers who only install the Windows January 2018 security updates _will
> not receive_ the benefit of all known protections against the
> vulnerabilities. In addition to installing the January security updates, a
> processor microcode, or firmware, update is required. This should be
> available through your device manufacturer. Surface customers will receive a
> microcode update via Windows update.

From:

[https://support.microsoft.com/en-gb/help/4073119/windows-
cli...](https://support.microsoft.com/en-gb/help/4073119/windows-client-
guidance-for-it-pros-to-protect-against-speculative-exe)

(There is also a powershell script to check if you are protected fully or not)

~~~
Donald
Microcode updates are distributed via Windows update.

~~~
chrisper
But Microsoft says they are not:

>In addition to installing the January security updates, a processor
microcode, or firmware, update is required. This should be available through
your device manufacturer. Surface customers will receive a microcode update
via Windows update.

[https://support.microsoft.com/en-gb/help/4073119/windows-
cli...](https://support.microsoft.com/en-gb/help/4073119/windows-client-
guidance-for-it-pros-to-protect-against-speculative-exe)

~~~
markphip
If the microcode update requires motherboard vendors to issue BIOS updates we
are all doomed.

~~~
evfanknitram
This appears to be the case at least on my Windows 10 laptop.

I've installed the hotfix for Windows, but when I run the PowerShell script to
determine whether mitigation is active, the script tells me that it's not
active, due to lack of hardware support. The script then goes on to give the
recommendation to "Install BIOS/firmware update provided by your device OEM
that enables hardware support for the branch target injection mitigation."

It's a 1-year-old ASUS laptop and I would be surprised if they even give a
sane response to my question to their technical support (I doubt they will
even know what I'm talking about).

~~~
thisacctforreal
"Dear OEM Vendor Technical Support,

There has been recent news about critical security issues in Intel CPUs,
requiring a firmware update for all laptops and motherboards with Intel chips.

The vulnerabilities include the potential for malicious websites to read
sensitive system memory, including passwords and encryption keys.

I have model XXYY-ZZZZ, do you have any information on when an update will be
available, and where I can access it?

If not, can you attempt to escalate this ticket? The security issues are
starting making their rounds in the news, and more information can be found at
[https://meltdownattack.com](https://meltdownattack.com)

Thank you, and happy new year :)"

Seems like it might be worth a shot.

~~~
pishpash
"Dear usr frend,

thx for ur interst in our product. our team will reach u. we have many new
products. hope u have great new year!

\- OEM volume sales"

------
317070
> Intel has developed and is rapidly issuing updates for all types of Intel-
> based computer systems — including personal computers and servers — that
> render those systems immune from both exploits (referred to as “Spectre” and
> “Meltdown”) reported by Google Project Zero.

Now I really wonder how they managed to patch both? Does someone know how you
could patch something like that from Intel's side of things?

~~~
userbinator
[https://en.wiktionary.org/wiki/chicken_bit](https://en.wiktionary.org/wiki/chicken_bit)

The first example usage given there is very illustrative:

 _As an example, modules such as branch predictors and speculative execution
units can be turned off with a variant of the “chicken bits”, control bits
common to many design developments to control the activation of specific
features._

~~~
Ajedi32
I kinda doubt they'd be able to turn off branch prediction and speculative
execution entirely and still be able to claim that

> the performance impact of these updates is highly workload-dependent and,
> for the average computer user, should not be significant

~~~
joeyh
If your workload does not branch, no performance impact AND Average user's
computer is mostly idle = Above intentionally misleading PR statement.

------
chrononaut
> _that render those systems immune from both exploits (referred to as
> “Spectre” and “Meltdown”)_

The language used seems to imply that they have patched all three identified
vulnerabilities.

Is it possible that if this update is applied to a system running an unpatched
Linux kernel on an Intel CPU that the system is no longer vulnerable to
Meltdown?

Or does this microcode update complement work done by the kernel developers
implementing KPTI as well as by the browser developers mitigating some portion
of Spectre?

(My initial take is that the efforts by CPU manufacturers and OS/Software
developers are orthogonal to provide better coverage to affected parties, such
as those on CPUs where no update exists yet)

~~~
space_fountain
I'd also be interested in an answer here. Right now it seems like this might
even just add support for OS vendors and software developers to mitigate this
down the road by selectively disabling pipelining features in their code or at
least that's what I'm reading seems to imply.

------
lifeformed
If it was kept secret, what would the value of this zero day exploit have been
on the black market?

~~~
kakarot
I'd be surprised if Meltdown was worth less than $2B. And I wouldn't be
surprised if it was worth over $100B.

Of course that is raw value, however in practice it would be EXTREMELY hard to
launder such a large amount of money into and out of an online transaction.

The question then becomes, what kind of person is the hacker? Are they in a
position where they can wait and find a good deal or would they rather wash
their hands of it over $100M or so?

~~~
tomschlick
For this kind of exploit, I don't think you'd have to worry about the
transaction. The NSA/(insert spy agency here) would gladly send a truck full
of cash to your house for it (assuming they didn't know about it already).

~~~
PuffinBlue
I like to think the NSA/TLA folks are sitting in an office somewhere
incredulous that someone found this bug they'd never have even dreamed up,
whilst a catalogue of simple buffer overflows and mandated backdoors that no
one has yet found sits on the shelf ready for offensive use.

~~~
rphlx
> they'd never have even dreamed up

Side channels in general have been known for a long, long time in mil and
intel communities, so it is likely that folks there long ago identified and
understood that it's a bad idea to share a single x86_64 core between multiple
tenants in a public cloud, for example, even if this specific attack vector
was not explicitly tagged & bagged.

~~~
kakarot
I was under the assumption that it's worse than just sharing cores or servers.
Even machines that do not share cores but share a common hypervisor are cross-
vulnerable.

From Wikipedia [0]:

 _Spectre has the potential of having a greater impact on cloud providers than
Meltdown. Whereas Meltdown allows unauthorized applications to read from
privileged memory to obtain sensitive data from processes running on the same
cloud server, Spectre can allow malicious programs to induce a hypervisor to
transmit the data to a guest system running on top of it._

However I have also read that Spectre is confined to userspace, so I'm not
sure who is correct.

[0]
[https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...](https://en.wikipedia.org/wiki/Spectre_\(security_vulnerability\)#Impact)

------
swasheck
So just to be clear, I'd need to install the OS patch as well as the OEM
update (to BIOS? Processor?) in order to mitigate both Meltdown and Spectre.

Additionally, how does this interact with VMs? It makes the most sense to me
that I'd need to microcode patch the hosts, but what about the guests?

~~~
wlll
My understanding of this situation is this:

Meltdown: Easier to exploit, fixable in software but perhaps up to a 30%
performance hit for some operations.

Spectre: Harder to exploit, not fixable in software, needs new hardware.

See these two links for more detail:

[https://twitter.com/nicoleperlroth/status/948684376249962496](https://twitter.com/nicoleperlroth/status/948684376249962496)

[https://googleprojectzero.blogspot.co.uk/2018/01/reading-
pri...](https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-
memory-with-side.html)

~~~
shagie
I was under the impression that the changes for Clang with retropipe was for
specter. Mitigation of it then can be done by recompiling... everything.

> Introduce the "retpoline" x86 mitigation technique for variant #2 of the
> speculative execution vulnerabilities disclosed today, specifically
> identified by CVE-2017-5715, "Branch Target Injection", and is one of the
> two halves to Spectre..

~~~
tyfon
Can't you just compile your own code without the mitigations inside the vm?

~~~
mort96
Yes, but then you'd just end up with having a vulnerable application running
inside of the VM. The mitigations in the compilers are for making programs
compiled by those compilers immune(ish?) to Spectre, not to make it impossible
for those programs to use Spectre to attack other processes.

------
dreamcompiler
These exploits are the result of the games we play to get high performance
when memory is slow but processors are fast (speculative execution; caches).

It's time to figure out how to make RAM dense, cheap, AND fast, so we can
finally eliminate the cache layer from the ridiculous hierarchy of storage
technologies.

~~~
ahh
Flops are cheap. Bandwidth is expensive. Latency is physics.

We aren't at full lightspeed latencies ram technologies, but we're closer than
you may realize, and it's unlikely we can do substantially better any time
soon without revolutionary advances.

~~~
user5994461
Electricity moves around 2/3 of light speed.

~~~
leni536
More precisely the electromagnetic waves on the waveguides of the motherboard
(bus) move around 2/3 as fast as electromagnetic waves in vacuum. Not as
fundamentally separated as one would imagine.

------
mtgx
They will update 90% of the chips 5 years old or newer, which I assume
includes Ivy Bridge and later. But the bug affects older chips, too. Important
to keep that in mind.

~~~
benjaminl
The actual quote is:

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

The post is silent on what will be done with older chips, it didn't say that
they are not going to be updated. It makes sense that Intel prioritizes the
newer chips.

~~~
ddebernardy
It makes sense but 5-10 year old laptops aren't uncommon nowadays.

Had this occurred 20 years ago nobody would have cared because computers would
get replaced super fast anyway. Nowadays, even a geeky household can have 5+
year old CPUs lying around and still used.

~~~
hug
Anecdotally: I game, compile, transcode, and do any other number of CPU-
intensive tasks on my machine. My household is definitely "geeky".

I still run an i7 2600k, which is a Sandy Bridge CPU introduced 7 years ago.

I don't (didn't? may not?) have any pressing reason to upgrade, although I was
considering it. Funnily enough, even before now I was considering the AMD Zen
architecture, and although I'm still undecided I'm being pushed further and
further towards AMD through ethical considerations alone.

~~~
gcbirzan
You won't need a microcode update. The microcode update is only needed for
Broadwell and newer (for those, retpolines don't work). Also, hello, fellow
2600k owner :D

------
dtx1
> including personal computers and servers — that render those systems immune
> from both exploits (referred to as “Spectre” and “Meltdown”) reported by
> Google Project Zero.

I thought you couldn't patch out Spectre

~~~
space_fountain
You can't in conventional software, this is almost certainly a microcode
update. It remaining to see at what cost. This change may well just totally
disable features that normally are heavily used in pipelining.

------
gaius
It’s interesting to see what companies choose to work on instead of security.
With Intel it’s speed, with Apple it’s the animated poop icon.

~~~
donarb
Like Intel didn't spend tons of money over the past 20 years on TV commercials
playing a unique set of musical tones to convince you to buy a computer with a
flawed chip inside.

~~~
softawre
> inside

------
discreditable
They don't explicitly say. Is part of this a microcode update?

~~~
userbinator
If it is (very likely, because only Intel can issue them thus far), they
probably figured out how to turn off the branch predictor.

The performance drop will still be there, but better than the "recompile
everything to not use indirect jump and call instructions"[1][2], at any rate.

[1]
[https://news.ycombinator.com/item?id=16066968](https://news.ycombinator.com/item?id=16066968)

[2]
[https://news.ycombinator.com/item?id=16070050](https://news.ycombinator.com/item?id=16070050)

~~~
mozumder
If it's a timing attack, they probably don't need to fully turn it off, but
turn it off and on randomly every now and then..

~~~
Skunkleton
That wont do it. The true data will still bias the results.

~~~
emn13
Even this PoC was limited to 2000 bytes a second; even a little noise may well
render the attack largely theoretical - or at least make the attack so slow as
to make it feasible to use other (expensive) mitigations only very rarely.

But yeah, it's not a brilliant solution. But it would help.

~~~
Skunkleton
Even one byte per minute would be enough to cause serious issues. Imagine if
some add served up by a torrent site could read information from another tab
rendered by the same process?

~~~
emn13
Not good, but still thousands of times better. And don't forget that you still
need to guess where to read from, which better be a very very accurate guess
at that rate. Making such an accurate guess is difficult when your runtime is
as complex as a browsers, and so even without that extra timing noise no PoC
exists (AFAIK?) attacking browsers.

But you know... you're not wrong ;-). I'm just not particularly worried about
the likelihood of this attack hitting anything I care about anytime very soon.

~~~
Skunkleton
Google does have a PoC for spectre that attacks Chrome via Javascript. That
said, I am not super worried either. Its not like all my personal data isn't
already out there for all to see (Thanks Equifax).

------
cultureulterior
Has anyone written anything on how process affinity would help with
Spectre/Meltdown?

~~~
blattimwind
The attacks require co-scheduling with the address space (thread/process) to
be attacked. So, exclusive process affinity is a working mitigation against
these attacks and other per-core micro-architectural attacks.

~~~
zeotroph
Using a thread to keep mispredicting as desired is just one (though faster)
possibiliy. It can be done in single threaded mode as well.

Also doing that on purpose would again worsen cache performance.

------
beamatronic
I just did a "sudo yum update" on CentOs and I see a slew of
firmware/microcode packages. Are these security patches ready to go already?

------
BuildTheRobots
I noticed a microcode update which was expected, but there's also been
firmware updates for Intel WiFi cards - which I wasn't expecting.

I don't suppose anyone can comment on why the WiFi update?

~~~
AnssiH
AMD CPU microcode is contained in the linux-firmware package/repository (
[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/amd-ucode) ) which also contains Intel WiFi card firmware.

So if your Linux distribution provides a new release of linux-firmware
package, you may get new versions of WiFi firmware packages as well with no
actual changes to those. This seems to be the case with at least RHEL:
[https://access.redhat.com/errata/RHSA-2018:0015](https://access.redhat.com/errata/RHSA-2018:0015)

The RHEL linux-firmware update contains an AMD microcode update that involves
Spectre mitigations. AMD microcode is mentioned at
[https://access.redhat.com/articles/3311301](https://access.redhat.com/articles/3311301)
and the linux-firmware package changelog says:

    
    
      * Wed Dec 27 2017 Rafael Aquini <aquini@redhat.com> - 20170606-57.gitc990aae
      - Add amd-ucode for fam17h
    

(Intel CPU microcode is part of microcode_ctl package, updated separately)

~~~
BuildTheRobots
Thank you very much for the response; I didn't realize RHEL would every
version-bump a package without anything actually changing!

For the sake of my own sanity, i tested the iwlwifi-1000 firmware package
iwl1000-firmware-39.31.5.1-57 and "-58" and can see no changes when hashing
the files.

------
fulafel
I wonder if the terminology of blocking specific exploits vs fixing
vulnerabilities is intentional.

Even the "facts" page consistently uses "these exploits" and says stuff like:
"These exploits, when used for malicious purposes, have the potential to
improperly gather sensitive data. Intel believes these exploits do not have
the potential to corrupt, modify or delete data."

Is this lawyering so they can say they never claimed to have addressed the
vulnerabilities?

------
dreamcompiler
It's easy to fix Meltdown with a microcode update. Do we know if Intel (or AMD
or ARM for that matter) are also attempting to fix Spectre? Spectre seems much
more difficult.

------
mtgx
I wonder what Linus thinks about all of this. Does he still believe this is no
different than a random UI bug, as he used to say not too long ago about
security bugs?

~~~
colonelpopcorn
He's pretty pissed, actually.
[https://lkml.org/lkml/2018/1/3/797](https://lkml.org/lkml/2018/1/3/797)

~~~
code_duck
I think that only scratches the surface of pissed for Linus. He barely even
swore.

------
bitL
Can we avoid Windows 10 update? Frankly, I don't want to have my gaming &
machine learning rigs slowed down (whatever you may say about negligible
impact) and would like to opt out of this update on some of my systems. Is it
possible? Or am I forced to just waste at worst 30% of my CPU cycles on
mitigating this issue, even if my computer never gets into browser for more
than a few seconds on very specific _trusted_ domains?

~~~
bennofs
These patches should only affect syscall entry/exit performance. So if you're
not doing things that do enormous amounts of syscalls, you should be more at
the 3% end of the scale. The 30% number comes from doing things like
calculating the file sizes of a directory with a lot of very small files,
where the performance overhead of a single syscall matters. In most
performance sensitive applications like games, you probably won't see any
syscalls in a hot loop since that'd be too slow anyway. Even if you're doing
heavy IO, then that is most likely also done in batch and blocked on disk IO
speed, not on syscall overhead.

~~~
bitL
There are reports on Reddit that NVidia's driver is affected due to heavier
usage of patched functionality which would mess with both gaming and Deep
Learning. In both, 5-10% drop is pretty unacceptable as that is often
basically performance offset to lower-tier card (e.g. non-Ti vs Ti card).

------
Taniwha
I wonder if an optional microcode update disabling usermode access to cache
flush and rdtsc instructions would make it impossible to do the low level
timings required to make the measurements

(of course it would break other stuff, but maybe being able to enable these
process by process might be appropriate)

~~~
Taniwha
thinking about it more a patch that masks out (or sets) the N LSBs of the
value returned to user space accesses to rdtsc might do the trick, it wouldn't
break anything, and time would still be monotonic

The recent CCC paper on how to write your own microcode (for AMD CPUs) means
that AMD owners can actually experiment with a fix of this on their own CPUs
... now if only Intel would let us hack the microcode on our own CPUs too ....

~~~
bennofs
Just masking the lower bits is not enough: you can easily reconstruct a high-
precision timer from that by observing the clock edges (waiting until rtdsc
increases): wait for clock edge, do your experiment, increase counter until
next clode edge in busy loop. the counter now correlates strongly with the
amount of time taken for the experiment.

Also, while cache flushes are the easiest way to trigger this, I am not
convinced that there aren't other ways to do it. For example, you could
attempt to clear the cache by spamming it with new data to cache, or you could
try to use one of the other sidechannels (I've seen ALU ports being mentioned
as one alternative: instead of accessing cache lines, you do some heavy math
operations that will cause the ALU ports of the cpu to be used and then you
observe how long ALU operations take in userspace)

------
oh-kumudo
Any idea how would they fix Spectre with this update? Or tries to make it
harder to exploit?

------
bluefox
So this was reported half a year ago and only now after publication Intel
releases updates?

~~~
chrisper
The Embargo was until January 4th.

------
dmateos
With these fixes and the performance losses, does that stack?

IE if you have a Server on amazon running a newer kernel with the patches but
then that underlying hardware is also running the newer kernel?

------
crimsonalucard
noob question here. Why isn't normal data readable? Why is only predicted
branch executions readable?

~~~
xigency
In at least one of the variants, I believe that the branch predictor is primed
in the attacker program with some value, say 0x00ABCDEF by jumping there
consistently in certain circumstances.

Then the CPU switches to running another program that is allowed to access
different memory. The CPU encounters a branch and predicts that it will land
at 0x00ABCDEF and begins running attacker code briefly. Since it's working on
the victim program, the code can access the victim program's data. After
several cycles the CPU realizes it made the wrong prediction and NOPs out all
of those instructions. However, the malicious code stores its results by
shuffling things on the cache, which aren't rolled back because the CPU
doesn't consider that to be nominal.

Therefore, the exploit can access memory from other programs. This is my
limited understanding of Spectre. Reading the white paper, it must be much
more complicated.

Apparently the CPU would normally stop accesses even speculatively when
running from the malicious program (except for Meltdown, where it doesn't even
stop that).

~~~
zeotroph
No, Spectre can only read its own memory, which makes it boring for programs,
but interesting for stuff running interpreted code because it can suddenly
peek outside, e.g. javascript.

Meltdown goes one step further in that it can read kernel memory (but not
memory of other processes either, unless it was explicitly mapped in).

~~~
pubby
Spectre allows one process to extract the memory of another process (assuming
certain conditions are met). I would not call that boring.

~~~
zeotroph
Damn, that is indeed possible. And I thought I understood these conceptually,
now I have to read the papers again.

~~~
tux1968
As i understand it, you can extract memory from another process by controlling
input data to that process. First sending data to train an exploitable branch
prediction point for success and then sending data which will use a
misprediction to extract some data.

The paper sited has an example C program that works within a single process,
but sets the stage to show how it could be achieved across process boundaries.

C program source:
[https://pastebin.com/9GSrXhi3](https://pastebin.com/9GSrXhi3)

~~~
zeotroph
This branch prediction inside a "gadget" needs to be mapped into the address
spaces of both attacker and victim (i.e. shared lib). But even if the attacker
can get this code to run on both sides and examine the dependent timings to
find out underlying values, the victim code can't be tricked to sequentially
read-by-speculation all its internal data.

Does the instruction cache get poisoned as well on a mispredict and carried
over?

------
orblivion
Oh nice. I know the average user is going to go right ahead and update their
CPU microcode.

~~~
herpderperator
Yes, they will. Microcode is hot-loaded. There is no way to permanently update
a CPU's microcode; it is uploaded to the CPU on each OS boot. They come
packaged in the appropriate Windows update or macOS update, or for example on
Ubuntu you'll get them the next time you upgrade with apt. So to answer your
question, the next time the user updates their operating system, provided the
OS manufacturer has included the new firmware, the user will automatically get
the new microcode which will get patched onto the CPU on each boot of that OS
from then onwards.

~~~
orblivion
Do you know why it can't be so easy with BIOS or Management Engine?

------
narrator
So is this the first year that computers will actually get slower vs. the year
before?

~~~
leni536
Yeah, also it's not about new computers. It's a huge portion of all existing
computers. Even my 10 years old Core 2 Duo laptop will get slower after I
update it (I'm not too happy about it).

------
m3kw9
Funny that nowhere to be found: the actual link to the fix and how to patch
it.

~~~
mathpay
Indeed, the latest linux microcode package has yet to be updated:
[https://downloadcenter.intel.com/download/27337/Linux-
Proces...](https://downloadcenter.intel.com/download/27337/Linux-Processor-
Microcode-Data-File?product=873) . Are they shipping specific CPU fixes to
vendors first before updating the full package?

