
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw - el_duderino
https://www.bloomberg.com/news/articles/2018-01-03/amd-soars-after-rival-intel-said-to-reveal-processor-flaw?cmpid=socialflow-twitter-business
======
dsign
This is a clusterf __ __/ big deal. Beyond the security implications, it means
that all companies paying for computing resources will have to pay roughly 30%
more overnight on cloud expenses for the same amount of CPU, assuming that
they can _just_ scale up their infrastructure.

I know that bugs happen and that there was nothing intentional on this one,
but at times like this is hard to held at bay the temptation of claiming for a
class lawsuit against Intel....

~~~
rbanffy
It's a good thing CPU is fairly compressible. Unless you meter it very
carefully, you'll see the performance hit and it'll not impact you that much.
Very few of my physical boxes are over 70% CPU utilization on a daily average.

It's, however, really bad if you sell CPU cycles for a living. You just lost
between 5 and 30% of your capacity. If you have a large building, you just
lost part of your parking lot to the Intel Kernel Page Problem building.

~~~
devcpp
Problem is, most companies that need a lot of power only care about one thing
- peak performance. And they tune it carefully in order to not overspend while
guaranteeing minimal downtime. This means that they'll have to pretty much
scale their infrastructure up by exactly 30%. That's a LOT for these big
clients.

Honestly, I'd just make sure the server firewalls are super tight and not take
in the future patches. At least for now.

~~~
ajross
Very very few highly tuned "peak performance" workloads are dominated by
syscall overhead like the test that produced that 30% number was. It's best to
hold off on the hyperbole.

~~~
dijit
I have a power dependent workload that scales horizontally and is currently
already dominated by the cost of system calls. This will effectively, directly
cause me to buy 30% more compute on a huge infrastructure. (2,000~physical
machines. Quite beefy dual socket machines with a lot of memory)

I know I’m not alone.

Then again. Think of microservices, Kubernetes for instance; Network requests
are system calls.

~~~
rbanffy
If your workload has no code that's untrusted, you can safely skip this patch
or disable it on boot. If not, at 2000+ physical machines, it may be worth to
move some of that into kernel modules that would collapse a couple syscalls
into a single higher level one.

~~~
rogerthis
But then you have to release the module as GPL, no?

~~~
lmm
Only if you want to do something that would otherwise be a violation of
copyright - e.g. distribute the module to other people (assuming it's
sufficiently entangled with linux to be a derivative work therof). The GPL
only licenses you to do things that you otherwise couldn't do, it doesn't
restrict you from doing things that were never a violation of copyright (e.g.
privately modifying your own things).

------
jrochkind1
Best summary I've found for the somewhat technical but not hardware-or-low-
level-hacker reader is arstechnica.
[https://arstechnica.com/gadgets/2018/01/whats-behind-the-
int...](https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-
flaw-forcing-numerous-patches/)

~~~
noxecanexx
My head is still spinning writing an OS is a BIG DEAL!!!!

------
rayiner
Can someone help me understand why this is such a big deal? This doesn’t seem
to be a flaw in the sense of the Pentium FDIV bug where the processor returned
incorrect data. It doesn’t even seem to be a bug at all, but a side channel
attack that would be almost expected in a processor with speculative execution
unless special measures were taken to prevent it. And it doesn’t seem like it
can be used for privilege escalation, only reading secret data out of kernel
memory. It seems pretty drastic to impose a double-digit percentage
performance hit on every Intel processor to mitigate this.

~~~
DannyB2
There is this thing called "return oriented programming". You write your
program as a series of addresses that are smashed onto the stack through some
other type of vulnerability. When the current function returns, it returns to
an address of your choosing. That address points to the tail end of some known
existing function, such as in the C library and other libraries. When the tail
end of that function returns, it executes your next "instruction" which is
merely the next return address on the stack.

The first "instruction" of your program is the last address on the stack, in
the list of addresses you pushed to the stack.

You are executing code, but you did not inject any executable code, you did
not need to modify any existing code pages (which are probably read only), you
did not need to attempt to execute code out of a data page (which is probably
marked non executable).

Address Space Layout Randomization is a way to prevent the "return oriented
programming" attack. When a process is launched, the address space is randomly
laid out so that the attacker cannot know which address in memory the std C
lib printf function will be located at -- in this process.

Now let's think about the kernel. If you could know all of the addresses of
important kernel routines, you could potentially execute a "return oriented
programming" attack against the kernel with kernel privileges. Without
modifying or injecting any kernel level code. These hardware vulnerabilities
allow user space code to deduce information about kernel space addresses.

Now that's a lot of hoops to jump through in order to execute an attack. But
there are people prepared to expend this and even more effort in order to do
so. Well funded and well staffed adversaries who would stop at nothing in
order to access more and better pr0n collections.

~~~
rayiner
Thanks for the explanation. But I don't understand this part:

> If you could know all of the addresses of important kernel routines, you
> could potentially execute a "return oriented programming" attack against the
> kernel with kernel privileges. Without modifying or injecting any kernel
> level code.

The user <-> kernel transition is mediated (on x86-64) with the SYSCALL
instruction, which jumps to a location specified by a non-user writable MSR.
How does return-oriented programming work in that case?

~~~
valleyer
Basically, let's say there's a syscall that takes a user buffer and size and
copies it into kernel stack for processing. (This is common.) If you overflow
that buffer, you can overwrite the return address in the kernel stack, which
you can then launch into ROP.

~~~
userbinator
_If you overflow that buffer, you can overwrite the return address in the
kernel stack, which you can then launch into ROP._

The crucial point here being that there must already be an existing overflow
vulnerability in the kernel. Knowing all the addresses is no use if you can't
force execution to go to them.

~~~
rincebrain
The hypothesis I've seen, and why people seem to be rushing to patch it
without explaining, is that you might be able to not only leak addresses, but
actual data, from any ring, into unprivileged code, at which point, your
security model is burned to the ground.

AIUI, the present circumstances are:

\- there exists a public PoC from some researchers of side-channel leaking
kernel address information into userland via JavaScript which may be unrelated

\- there exists a Xen security embargo that expires Thursday that might be
unrelated

\- AWS and Azure have scheduled reboots of many things for maintenance in the
next week, which seems unlikely to be unrelated to the Xen embargo

\- a feature that appears to be geared toward preventing a side-channel
technique of unknown power has been rushed into Linux for Intel-only (both
x86_64 and ARM from Intel)

\- a similar class of prevention technique has been landed in Windows since
November for both Intel and AMD x86_64 chips (no idea about ARM)

\- the rush surrounding this, and people being amazingly willing to land fixes
that imply a 5-30% performance impact, strongly suggest that unlike almost
every major CPU bug in the last decade, you can't fix or even work around this
with a microcode update for the affected CPUs, which is _huge_. The AMD TLB
bug, the AMD tight loop bug that DFBSD found, even the Intel SGX flaws that
made them repeatedly disable SGX on some platforms - all of them could be
worked around with BIOS or microcode updates. This, apparently, cannot.
(Either that or they're rushing out fixes because there's live exploit code
somewhere and they haven't had time to write a microcode fix yet, but
O(months) seems like they probably concluded they outright can't, rather than
haven't yet.)

~~~
rincebrain
Addendum for anyone still reading:

\- Intel issued a press release saying they planned to announce this next week
after more vendors had patched their shit, which lends me more cause to
believe that the Xen bug might be the same one [1]

\- Intel claims in the same PR that "many types of computing devices — with
many different vendors’ processors" are affected, so I'll be curious to see
whether non-Intel platforms fall into the umbrella soon

\- macOS implemented partial mitigations in 10.13.2 and apparently has some
novel ones coming up in 10.13.3 [2]

\- someone reasonably respected claims to have a private PoC of this bug
leaking kernel memory [3]

\- ARM64 has KPTI patches that aren't in Linus's tree yet [4] [6] ([6] is just
a link showing the patches from 4 aren't in Linus's tree as of this writing)

\- all the other free operating systems appear to have been left out of the
embargoed party (until recently, in FBSD's case), so who knows when they'll
have mitigations ready [5]

\- So far, Microsoft appears to have only patched Windows 10, so it's unknown
whether they intend to backport fixes to 7 or possibly attempt to use this as
another crowbar to get people off of XP 2.0

\- Update: Microsoft is pushing an OOB update later today that will auto-apply
to Win10 but not be forced to auto-apply on 7 and 8 until Tuesday, so that's
nice [7]

[1] - [https://newsroom.intel.com/news/intel-responds-to-
security-r...](https://newsroom.intel.com/news/intel-responds-to-security-
research-findings/)

[2] -
[https://twitter.com/aionescu/status/948609809540046849](https://twitter.com/aionescu/status/948609809540046849)

[3] -
[https://twitter.com/brainsmoke/status/948561799875502080](https://twitter.com/brainsmoke/status/948561799875502080)

[4] -
[https://patchwork.kernel.org/patch/10095827/](https://patchwork.kernel.org/patch/10095827/)

[5] - [https://lists.freebsd.org/pipermail/freebsd-
security/2018-Ja...](https://lists.freebsd.org/pipermail/freebsd-
security/2018-January/009651.html)

[6] -
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64?h=v4.15-rc6&qt=grep&q=kpti)

[7] - [https://www.theverge.com/2018/1/3/16846784/microsoft-
process...](https://www.theverge.com/2018/1/3/16846784/microsoft-processor-
bug-windows-10-fix)

~~~
johncalvinyoung
[https://security.googleblog.com/2018/01/todays-cpu-
vulnerabi...](https://security.googleblog.com/2018/01/todays-cpu-
vulnerability-what-you-need.html)
[https://googleprojectzero.blogspot.com/2018/01/reading-
privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-
memory-with-side.html)

Seems that Google/Project Zero felt the need to go ahead and break embargo.
Worth adding to the above list of news sources.

~~~
victorhooi
No, that's not accurate.

If you read the article you quoted:

> We are posting before an originally coordinated disclosure date of January
> 9, 2018 because of existing public reports and growing speculation in the
> press and security research community about the issue, which raises the risk
> of exploitation. The full Project Zero report is forthcoming (update: this
> has been published; see above).

Just from public Gooogling, I believe it may have been the Register who tried
to get in on the scoop, and broke the embargo:

[https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...](https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/)

~~~
lmm
No-one necessarily broke the embargo. A blogger noticed unusual activity
around a certain linux patchset and put two and two together, and the register
mostly sourced from his article (
[http://pythonsweetness.tumblr.com/post/169166980422/the-
myst...](http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-
case-of-the-linux-page-table) )

------
qubex
I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips,
the distinction between how it affects Intel _vs._ doesn’t affect AMD reminds
us of a fundamental lesson we seem to have conveniently forgotten:
monocultures _of anything_ are bad. We need diversity and diversification in
order to have reasonable amount of robustness in the face of unknowable,
unpredictable risks.

I’m wondering whether ARM chips are affected if they are whether they are
uniformly affected or whether it depends on vendor implementation choices.

~~~
thraweigh666
>We need diversity and diversification in order to have reasonable amount of
robustness

Ironically, in human populations it produces the opposite effect.

~~~
adornedCupcake
Why?

~~~
edraferi
More diverse population—> lower trust —> less social will to support each
other.

~~~
cryptonector
So we should be tribal societies, then? (I.e., endogamous. As in cousin
marriage.)

------
dsign
Here are some numbers quantifying the problem. Big caveats apply as they are
very preliminary, but the hit due to the software patches looks extremely
significant:

[https://www.phoronix.com/scan.php?page=article&item=linux-41...](https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2)

~~~
0xcde4c3db
Superficially, it seems like the performance hit mostly scales with IOPS or
transactions per second, which might have some pretty serious implications for
performance/dollar in the kinds of intensive back-end applications where Intel
currently dominates and AMD is trying to make inroads with EPYC.

~~~
eptcyka
It has very little to do with what kind of syscalls (I/O or other kinds) and
all to do with how many syscalls a given application makes per given time
period. Compute bound applications are already avoiding syscalls in their
hotter parts. This will mostly be a blow to databases, caching servers and
other such I/O limited applications.

~~~
bunderbunder
In other words, don't worry - pretty much all the key performance bottlenecks
most of us deal with at work will be getting tighter, but at least our video
games will still run OK.

~~~
josefx
Right now I am just hoping that it wont add significant overhead to OpenGL. My
application already has a bottleneck on changing OpenGL states and issuing
render commands and I have no idea how much of that time is spend making
syscalls.

~~~
elFarto
OpenGL implementations shouldn't be effected by syscall overhead. Historically
it's been DirectX that had a syscall per draw call, but I believe both now
just write the command to GPU RAM directly.

~~~
bartread
That's at least somewhat encouraging. Nevertheless, it sounds rather like the
old, "Yes, but will it run Crysis?" question will perhaps have renewed
relevance.

------
rwmj
AMD must be pretty happy about this patch:
[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

~~~
uniformlyrandom
Not so sure about that. I am reading the merge commit, and comments are pretty
interesting:

    
    
      --- a/arch/x86/include/asm/processor.h  
      +++ b/arch/x86/include/asm/processor.h
      + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
      + * address, then that syscall will enter the kernel with a
      + * non-canonical return address, and SYSRET will explode dangerously.
      + * We avoid this particular problem by preventing anything executable  
      + * from being mapped at the maximum canonical address.
      + *
      + * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
      + * CPUs malfunction if they execute code from the highest canonical page.
      + * They'll speculate right off the end of the canonical space, and
      + * bad things happen.  This is worked around in the same way as the
      + * Intel problem.

~~~
amluto
I wrote that text. It's just documenting a bug that never affected Linux at
all.

I'm having trouble finding a good reference right now.

------
NinjaKitten
"Intel has a bug that lets some software gain access to parts of a computer’s
memory that are set aside to protect things like passwords."

Seems like very little got through to the media about the details regarding
this flaws effects and costly workaround.

~~~
dspillett
Very little by way of details has been made public yet. Not even the technical
press. Even relevant comments in the Linux source are redacted at the moment.
Hopefully, further details will be released in good time (in the next month?)
when people have had time to install the patches that are going out
RealSoonNow (i.e. the huge plan of updates on Azure's VM hosts).

~~~
teraflop
> Even relevant comments in the Linux source are redacted at the moment.

People keep repeating this claim because it sounds dramatic, but I'm not sure
it's a fair description. The original source appears to be a single snide
tweet from @grsecurity [1] referencing this comment [2].

It's far from obvious that the comment was even "redacted" at all. It seems
more likely that "stay tuned" is either a reference to the more detailed
comments elsewhere in the patch (in arch/x86/kernel/ldt.c), or a reflection of
the fact (which is clearly spelled out in the commit message) that future
patches are likely to change the location of the LDT mapping.

I've skimmed through the commit messages and comments from the latest patchset
[3] and couldn't find anything else that even hinted at redaction, nor could I
find any mention of redactions on the linux-kernel mailing list.

Furthermore, it's worth bearing in mind that @grsecurity has been involved in
numerous public feuds with the Linux security folks. So in the absence of
concrete evidence, I'm not particularly inclined to assume his tweet was made
in good faith.

~~~
teraflop
D'oh, I left out the links from this comment.

[1]:
[https://twitter.com/grsecurity/status/947147105684123649](https://twitter.com/grsecurity/status/947147105684123649)

[2]:
[https://github.com/torvalds/linux/commit/f55f0501cbf65ec41cc...](https://github.com/torvalds/linux/commit/f55f0501cbf65ec41cca5058513031b711730b1d#diff-556e2727cb1c1dcc08666f181aee361cR854)

[3]: [https://tglx.de/~tglx/patches-
pti-184.tar.bz2](https://tglx.de/~tglx/patches-pti-184.tar.bz2)

------
cma
This isn't really too far out of proportion with normal daily fluctuations of
AMD stock this year.

~~~
zelos
Quiet, you're spoiling the narrative we're imposing on semi-random, chaotic
events.

~~~
cma
To add another point: NVDA is up 5% and doesn't have the same direct
competitive narrative. If money has to be spent rectifying the issue with new
or more CPUs due to performance loss, that's less money available for spending
on Nvidia GPUs. It might tip a few marginal applications in favor of eating
the development costs to migrate to GPGPU, but that effect isn't likely nearly
as high, especially if applications with lots of system calls are affected the
most.

~~~
tedunangst
Chipotle is also up 5%. All these engineers are going to need lots of burritos
to eat.

~~~
jabl
You're saying that gas in the cleanroom caused the chips to behave
incorrectly?

Excuse me while I go and invest in a company making rubber underwear.

~~~
adjkant
Someone's gotta sell Burger King sesame seeds...

------
moomin
"Chip design flaws are exceedingly rare."

Writes someone who's never seen an errata.

------
aeleos
What started as speculation about recent kernel developments has really turned
into a shitshow for Intel. I can't imagine they thought that these massive
changes would get through without anyone finding out. However, there really
isn't any other better option for Intel, so it seems they are in a lose lose
situation with no way out. Or at least a way out that doesn't involve them
going bankrupt trying to repair the damage.

~~~
mandeepj
> going bankrupt trying to repair the damage.

I think you took it a bit too far. May be, I am missing something. Is it
really that bad?

~~~
aeleos
There are at least tens of thousands, possibly hundreds of thousands of Intel
CPUs in just datacenters around the globe. Most of which are controlled by
companies that make a lot of money and paid a lot of money to intel for their
CPUs. And I doubt that they will just take this kind of hit to their
performance sitting down. And thats just datacenters, not to mention all the
personal computers (mine included) that will suffer. At this point, if this is
real, its not a question of if it will cost them, its how much. And
considering the sheer numbers of the products affected, I can't imagine it
will be cheap. I am not saying that I think they are going to go bankrupt, and
I would be surprised if they did, but a 30% percent performance hit is
multiple generations of fallback, and considering the importance of computing
today (and the number of different entities that are affected by this) I find
it hard to imagine that it will be just taken sitting down.

------
littlestymaar
Interestingly enough, Intel and AMD market values are affected by this but the
cloud provider aren't, which I find surprising.

~~~
Waterluvian
Hm. Do cloud providers need to provide up to 30% more capacity for the same
price, or do customers need to purchase up to 30% more capacity to get the
same speed?

~~~
rocqua
Unless demand is fully inelastic, if you up the price fewer people will buy.
As such, this should hit the cloud provider profits.

~~~
maratd
> Unless demand is fully inelastic

It's mostly inelastic. People don't buy resources unless they need to do work.
Alternatives, such as on-prem hardware, are affected as well.

The only work that would be affected would be the work that becomes
unprofitable at a 10-30% hardware cost increase and this is probably marginal
enough to be ignored.

~~~
scottlamb
> It's mostly inelastic. People don't buy resources unless they need to do
> work.

I work on a system (at Google) with significant hardware cost. Fundamentally,
the work my system is doing needs to be done. But the time we spend improving
efficiency is hugely elastic. I look at a CPU profile or request flow, have an
idea to improve it, look at how much machine resources we're spending,
guesstimate how long it will take us to implement and maintain, and use a
chart to see if my idea is worth my team's time or not.[1]

If the resources get more expensive or simply impossible to acquire,[2] we'll
optimize more.

[1] There are other considerations (will it make the code more complex, thus
increasing risk of a security/privacy flaw? what about opportunity cost given
that it's hard to hire more engineers and scale a team?) but that's a
reasonable mental model.

[2] There's a global RAM and SSD manufacturing crunch already, and if lots of
CPUs are replaced due to these vulnerabilities or simply are no longer enough,
that's gonna be a big crunch as well. If you're one of the few biggest cloud
providers, I think you can't just replace / add tons more hardware than
planned without dramatically increasing the price per unit for everyone.

~~~
maratd
> But the time we spend improving efficiency is hugely elastic.

In the context of the above posts, "elastic" is an economic term used to refer
to the demand curve. There is no supply/demand curve when it comes to internal
technical decisions for optimization =)

I would say your work is highly correlated to the price of hardware per some
unit of performance AND the amount of work that you need to complete AND the
amount of hardware already available AND the cost of labor needed for
optimization.

I imagine in your case, since these systems are tightly controlled, you can
probably run unpatched without taking a substantial risk.

------
microcolonel
This is not a PR nightmare, it's a technical competitive nightmare. For many
workloads, last-gen AMD server chips are now competitive with current-gen
Intel server chips; and the current generation already had a lot in its
favour. There's no amount of PR fluff that can save Intel from this, they can
only release a new design with this fixed and hope they don't lose too much
ground in the mean time.

------
Havoc
As a shareholder that's great. Concerned that this is a very fragile win
though. I don't think there will be much real world fall out.

~~~
swarnie_
How you hold this stock is a mystery to me. With it bouncing between $10 and
$15 constantly last year it just seems far to volatile. I'd be panic buying /
selling every day to adjust which seems stressful...

Maybe why its a favorite of /r/wallstreetbets

~~~
meddlepal
You're doing it wrong if you're day trading stocks... dollar cost averaging is
your friend when it comes to volatility and well if you're investing you're
doing so because of long term belief in the company so it should be easy to
hold and not worry about it.

~~~
betterunix2
"dollar cost averaging is your friend"

Research suggests otherwise:

[https://personal.vanguard.com/pdf/ISGDCA.pdf](https://personal.vanguard.com/pdf/ISGDCA.pdf)

Diversification is a more effective strategy for dealing with volatility.

~~~
nimnio
I only read page one of that link (thanks for sharing), but it appears to
limit its scope to a specific scenario: given a lump sump of money (a
windfall), it is it better to invest all at once or dollar cost average over a
period of time? It is not recommending against dollar cost averaging in
general; it is recommending against it for windfalls. Diversification is also
not mentioned in the article.

~~~
BuckRogers
I read that Vanguard study when it came out, yes it's correct statistically
but I disagree with using that data to do lump sum investments. For one, the
CEO in their 2018 outlook webcast said to DCA. Even if you keep a short
timespan on your DCA (I do 26 weeks), it's a good idea for your mental health
if you happen to dump it all right before a collapse.

Sometimes it's wiser to take into account human psychology, even if academics
are out there with data to convince us otherwise.

I'm personally with the CEO of Vanguard on this one. A short entrance into the
market, especially in today's situation is probably the way to go. People can
do whatever they want, and if they put their money where their mouth is and go
in with a lump sum, then I'll respect it.

Otherwise, as someone who is bringing a lot of money myself onto the market
now, I'm DCAing.

------
throwaway613834
Will there be any way to disable or block the upcoming patches and keep the
performance for those of us who really just don't have any reason to care
about inter-process information leakage on our personal computers?

Edit: I'm (also) wondering about Windows, in case anyone knows yet.

~~~
pixl97
Just don't do this if you have PII, HIPAA, or PCI data on your computer.

~~~
stusmall
Even then and if they don't care about their own safety, they should patch for
the rest of us. Who knows how long until their unpatched system will get pwned
from some other vulnerability and end up in some botnet just spreading the
pain.

------
GuB-42
It seems like it is all thanks to this patch:
[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

If I understand well, there may be a serious bug in some x86 CPUs but nothing
is known publicly. Presumably, all current Intel CPUs are affected and none by
AMD but we can't really be sure, it is still a secret.

It is impressive how a simple, yet to be justified patch has so much
influence. It opens up new ways of manipulating the market...

~~~
markonen
But it's not just a random patch posted to LKML, it has also been reviewed and
merged to tip. That means it has been justified, just not to you.

------
chrisper
If you look here: [https://www.computerbase.de/2018-01/intel-cpu-pti-
sicherheit...](https://www.computerbase.de/2018-01/intel-cpu-pti-
sicherheitsluecke/) (Sorry it is German)

But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that
most applications do not have any performance hit with the Windows patch.

Only M.2 SSD seem to be affected.

~~~
dingo_bat
It is possible Microsoft has mitigated the issue in a way that has much lesser
performance impact. Maybe they had a highly tuned feature to enable kernel
page separation already coded but disabled. I won't be surprised if even the
Linux implementation is tuned to the absolute limit in the coming months.

~~~
chrisper
I think so too. It also seems the Linux version right now is in a "get it to
work, optimize later" state.

~~~
amluto
If you know how to materially optimize it, I'm all ears.

------
matt4077
This reminds me of a storyline from The West Wing, where a company that was
Intel in everything but the name found a bug in their chip.

As it threatened the company's existence, the President refused to consider
guaranteeing a loan because the company had been a contributor, and any help
could potentially appear as corruption.

How quaint such considerations seem today...

------
Abishek_Muthian
I'm worried about the performance impact on low end intel chips like
Atom/Celeron found in Chromebooks.30% hit will make computing on those
platforms miserable.

Talking about chromeOS, is there any speculation about the impact of bug? Does
it's hardened sand-boxing techniques put it in a better position even if KASLR
is compromised?

~~~
dannyw
The bug isn't really KASLR, it's more about reading kernel memory from
userspace through side channel attacks of speculative execution.

KASLR is/was the cover for the kernel patches, to avoid disclosing the real
bug.

~~~
svet_0
Indeed, kernel memory read seems more likely than address only read, the
memory probably needs to be cached (in L1 maybe?). Attack is a timing attack
as can be seen in this very interesting tweet -
[https://twitter.com/brainsmoke/status/948561799875502080](https://twitter.com/brainsmoke/status/948561799875502080)

------
pavel_lishin
> AMD shares surged as much as 7.2 percent to $11.77 Wednesday. Intel fell as
> much as 3.8 percent, the most since April, to $45.05. An Intel spokesman
> declined to comment.

I have no real context for this, but is 7.2% considered a "soar"? And a 3.8%
decrease seems like kind of not a lot, considering what's fucking happening
here.

~~~
hbosch
A 7.2% rise intraday is pretty big, especially for traders holding leveraged
positions. If you're comparing to crypto markets then no, but generally
speaking yes.

~~~
pavel_lishin
Thanks!

------
blattimwind
And we got a bingo
[https://news.ycombinator.com/item?id=16061364](https://news.ycombinator.com/item?id=16061364)

------
jamisteven
Literally just read here yesterday how the CEO dumped majority of his shares.
So Shiesty.
[https://news.ycombinator.com/item?id=16055851](https://news.ycombinator.com/item?id=16055851)

~~~
prewett
Don't be so quick to blame. You might have read it yesterday, but he
_reported_ it on Nov 29, which means that the transaction happened either
within two days prior or about a month, depending on if you believe the SEC's
website or NASDAQ's website. But the question isn't when he sold his shares,
the question is when did he put in the order to sell those shares. Those guys
put their buy/sell orders in months in advance because of exactly this
problem. Or maybe he had a limit order in--the beginning of November was a
2-year high, so you could easily imagine a limit order executing about then.

~~~
joncrane
Evidence shows this bug was known in November. It only blew up this week.

~~~
jacksmith21006
Probably even earlier.

------
mastazi
I am confused, as far as I know two different vulnerabilities have been
discovered, Meltdown and Spectre; while the first one affects only Intel CPUs,
the second one affects AMD and ARM as well. So how come I'm not seeing much
talk around about the latter? Is it because it is harder to exploit?

I didn't have a chance to read the 2 papers so I would appreciate a TL;DR.

I am a SW developer working with high level languages; security and OS
development are not my specific fields so while I don't need an ELI5 I would
appreciate a sufficiently "layman's terms" explanation.

~~~
mastazi
Replying to myself: most of the info can be found here

* [https://googleprojectzero.blogspot.com.au/2018/01/reading-pr...](https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html)

* [https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl...](https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/)

* [https://meltdownattack.com/](https://meltdownattack.com/)

* [https://www.amd.com/en/corporate/speculative-execution](https://www.amd.com/en/corporate/speculative-execution)

* [https://newsroom.intel.com/news/intel-responds-to-security-r...](https://newsroom.intel.com/news/intel-responds-to-security-research-findings/)

TL;DR is that mitigation for Spectre on an OS level is not very expensive in
terms of performance while Meltdown mitigation, which affects only Intel, will
have a performance penalty between 5% and 30%

------
bla2
The bottom of [https://danluu.com/cpu-bugs/](https://danluu.com/cpu-bugs/)
suggests that AMD isn't any better, so this is likely just short term.

~~~
dboreham
They don't have to be better to benefit from purchasers wanting to diversify
their plant across two rather than one CPU vendors.

------
dzink
Didn’t the Intel CEO just sell half of his shares/options? If he knew about
these issues isn’t that illegal?

~~~
chx
You can be sure there's a young hotshot with sparkling eyes at SEC who is
already typing a letter to Mr. Krzanich politely asking about the
circumstances of that sell.

At the same time, noone is doing eight figures transactions which require
reporting to the SEC without talking to a lawyer. Right? Right? They _really_
dislike insider trading, it's one of the few things where even rich people can
get imprisoned -- and the typical jail sentence has been steadily climbing up
for decades now.

~~~
cookiecaper
> They really dislike insider trading, it's one of the few things where even
> rich people can get imprisoned -- and the typical jail sentence has been
> steadily climbing up for decades now.

Insider trading, like many white-collar crimes, exists primarily for its value
as a weapon. There is nothing actually illegal about the act of selling a
stock; it's all about casting aspirations as to intent and who-knew-what-when.

In other situations, intent is usually an aggravating factor, enhancement, or
affirmative defense. It is not the thing that qualifies an otherwise 100%
legitimate act as a bad thing.

My anecdotal, unsubstantiated perspective is that insider trading is unlikely
to be an issue for anyone who hasn't made enemies, and that it may suddenly
become an issue for anyone naive enough to make enemies recklessly. cf. Martin
Shkreli, who couldn't be linked to a specific "bad trade" so was brought on
generic "securities fraud" instead.

Not playing ball with the people wielding these powers seems to be the
dangerous thing.

~~~
foldr
Intent is a key component of most crimes, isn't it?
[https://en.wikipedia.org/wiki/Mens_rea](https://en.wikipedia.org/wiki/Mens_rea)

~~~
cookiecaper
Disclaimer: I'm not a lawyer, there are definitely people who can explain this
better, and I'm probably using these terms incorrectly.

Yes, _mens rea_ is an important consideration, but it's nuanced. Check the
Model Penal Code [0], which identifies four differing types of _mens rea_ ,
including negligence and recklessness; that is, a "guilty mind" ( _mens rea_
), for criminal purposes, does not necessarily require what would be
conventionally considered bona fide malice or intent to harm.

What I meant when I said an "enhancement" or "aggravating factor" is that
usually you have an objectively asocial _actus reus_ , like theft, and should
_mens rea_ come into play, it's generally a defensive thing seeking to
exculpate the accused, as in "I didn't know it belonged to someone else" (the
affirmative defense), not to deny the act.

But with insider trading and other instances of nuanced _malum prohibitum_
[1], the usual relationship between _actus reus_ and _mens rea_ is inverted.
To make the crime, one starts with the _mens rea_ , the bad intent, and must
identify (or, if necessary, manufacture) an apparently-normal act to register
as the external offensive conduct that harmed society and warrants legal
action.

That is a scarier proposition because if your daily business involves
technical acts that can be converted into _actus reus_ , there's obviously
going to be ample opportunity for people to assign and rationalize their
preferred ideas about your thought process there and convince themselves that
you're a criminal based on their personal level of dislike or offense. If this
gets brought in court, your defense will amount to convincing the jury to
believe you instead of the prosecutor, which is a straight-up likability and
performance contest.

Whereas, with better-defined crimes, there is a physical, independent _actus
reus_ that people recognize as objectively bad and probably intentional. If
you didn't steal the thing, if they can't show that you stole the thing,
that's now the ground that you're fighting over, and that's much better for
the defendant because it's much less fickle.

Essentially it makes every defense necessarily affirmative because the conduct
is not otherwise unlawful. The government must dislike you enough to assume
bad faith first.

[0]
[https://en.wikipedia.org/wiki/Model_Penal_Code#Mens_rea_or_c...](https://en.wikipedia.org/wiki/Model_Penal_Code#Mens_rea_or_culpability)
[1]
[https://www.law.cornell.edu/wex/malum_prohibitum](https://www.law.cornell.edu/wex/malum_prohibitum)

------
TheSwordsman
I wonder what implications this will have on those who run Intel in their
gaming rigs. I'm due to refresh, and _was_ gonna invest in Intel as my CPU.
But this seems pretty damning for that.

I assume the system calls to interact with the GPU, or to do any sort of I/O,
are going to incur the performance overhead. So rendering frames,
reading/writing from the network, and loading assets from the disk could all
cause issues.

And this is just for gaming. Anyone using a cloud provider that's running on
Intel needs to worry about similar things.

What a nightmare...

~~~
a_humean
Apparently zero effect:
[https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-...](https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-
Initial-Gaming-Tests)

~~~
QShift
Well, that's for Linux. We don't exactly know what effects such patches would
have on other platforms yet. (do we?)

------
rdl
I wonder how Intel will deal with this.

If I were Intel, I'd offer free replacements for at-par performance, and
potentially tiny cash payment for upgraded performance. Assuming the marginal
cost to produce chips, especially older/slower ones, is very low, the only
real cost to them is losing out on potential upgrade sales which would have
happened organically, for a while.

However, doing this keeps Qualcomm/ARM and AMD from making massive inroads
into the market. As well, it would be a great way for Intel to accelerate
adoption of their newer technologies, causing even greater lock-in (you could
assume a much higher percentage of users will have a feature)

This all works great for socketed CPUs (still common for servers/cloud). For
embedded, where CPU is more likely non-replaceable even if socketed) CPU peak
performance probably doesn't matter as much -- maybe do a discount coupon? Or
work with equipment vendors to subsidize upgrades.

Laptops and non-technical end users (who couldn't swap their own CPU) probably
don't care as much but also don't have the ability to upgrade. A
rebate/upgrade program would work, or a substantial cash payment. Doing it as
e.g. $50 cash or $250 toward your next Intel-CPU laptop would be interesting.

Intel is rich, the market leader, incumbent across multiple segments, etc., so
they really should go overboard on their response.

~~~
asah
rofl, you don't simply upgrade chips installed in 1+B servers and laptops and
network devices and embedded systems. In fact, statistically-few devices-
containing-a-CPU are designed to _ever_ have their CPUs replaced. At the last,
you replace the motherboard, which requires coordination with the vendor.
Consider cars - good luck coordinating that recall!

~~~
rdl
Devices containing multiple security levels/distinct users, and where
performance matters the most, are generally socketed-CPU servers. For other
devices, if they're security critical and can't be addressed through software,
you can upgrade them at the board or device level early. This has already
happened in embedded devices due to the C2000 timer problem.

Assuming there is a software mitigation which has a performance impact,
sophisticated users would be capable of adding more capacity (if it's a
horizontal scale type workload), upgrading early (if they had extra capacity
for futureproofing), or spending money, potentially subsidized by Intel, to
upgrade immediately. If there's no mitigation, upgrade early, or rearchitect
application (moving away from shared security domains on single boxes, etc.)

------
rietta
Just built a new Linux workstation the day after Christmas with a 4.2 Ghz i7.
In hindsight I should have bought a AMD Ryzen! Glad the computer I built my
dad was an AMD.

~~~
bandris
The following story might comfort you somewhat. Someone had bad luck with
Ryzen:

[http://erlang.org/pipermail/erlang-
questions/2018-January/09...](http://erlang.org/pipermail/erlang-
questions/2018-January/094580.html)

------
jmull
> The security updates may slow down older machinery by as much as 30 percent,
> according to The Register.

I will eat my hat if that 30% number holds up.

------
AnIdiotOnTheNet
Honest question, does the performance hit from this patch actually hit Intel's
best processors enough to make them perform worse than AMD's best?

I don't keep up on these kinds of metrics, but I'm under the impression that
Intel still dominated CPU benchmarks berfore this issue, so if this question
is answered in the negative then I doubt it will affect Intel very much.

~~~
db48x
It depends on what your program is doing. If your program uses a lot of
syscalls, then it'll be slower. If it hardly uses them at all, then it won't
be as affected.

~~~
AnIdiotOnTheNet
Yes, but that wasn't the question.

------
throwawazqq
AMD stock price was higher in July and October. It increased a tiny bit and
does not constitute “soaring”.

~~~
take4
It's currently +10%, which absolutely is "soaring".

------
perseusprime11
What is more interesting to me is the news that came before this: Intel CEO
selling his stock. I did not read the news but I got a notification on the
phone through one of the many news apps on my phone. For a moment, I wondered
why he sold off his stock.

------
jhallenworld
After the fix, will device drivers still have the user process mapped into
their address space?

If not, then the fix may expose many driver bugs (where driver accessed user
space directly instead of through copy_from_user()), making the whole thing
even more painful.

------
tapoxi
I don't know much about CPUs, so what prevents a fix via microcode update?

~~~
dannyw
The bug seems to be revolving around speculative execution. It seems like that
is a silicon thing, not a microcode thing.

~~~
rphlx
It's likely they _could_ disable speculative execution in its entirety, either
in ucode or UEFI, but that would harm many compute-intensive workloads by
5-10% or more, so my guess is that somebody decided to push this page table
mitigation instead, taking the hit on the syscall/hypercall side as that's
perceived as "less bad overall".

------
emn13
This piece is (IMNSHO) trash. It's trying to stare into some crystal ball
guessing at the cause of market fluctuations; but there's no real evidence
they're right.

Not to mention it's pretty misleading about technical stuff, saying e.g. "Chip
design errors are exceedingly rare. More than 20 years ago, a college
professor discovered a problem with how early versions of Intel’s Pentium chip
calculated numbers."

So, they imply that chip design errors are once in a few decades kind of
things; that's just complete nonsense. Chip design errors are _common_ most
just aren't this bad.

Furthermore, they imply this stock change is anything more than temporary
volatility; given the tiny, tiny changes so far that's just premature. Perhaps
the stocks will adjust more in the future - we'll see. But as of now, this
piece is financially and technically pretty misleading.

~~~
whack
_Major_ chip design errors, of this magnitude, are exceedingly rare.
Especially in comparison to the software industry where bugs are released to
production a couple orders of magnitude more frequently. How many other Intel
hardware bugs can you point to that are comparable to the ones below?

 _" All computers with Intel chips from the past 10 years appear to be
affected... The security updates may slow down older machinery by as much as
30 percent, according to the report."_

 _" discovered a problem with how early versions of Intel’s Pentium chip
calculated numbers... Intel had to recall some chips and took a charge of more
than $400 million."_

~~~
emn13
That's what _you 're_ saying (and indeed what I said too!), but that's not
what bloomberg published. What you're saying makes sense! But _they_ didn't
qualify this by _major_. And the qualification is important to the heart of
the story, since the way they phrased it suggests that chip design is largely
reliable and thus that this is an exceptional error, when in fact errors are
common, and impact is merely exceptional. In effect: they're overstating the
signal-to-noise ratio this event implies.

Worse, they understated the noisiness of the chip error "signal" but they also
understate the noisiness of the stock value signal. And hey presto; if you
conveniently present only the data you want all of the sudden a correlation
looks really meaningful!

Furthermore, even the qualification "major" isn't really deserved quite to the
extent that bloomberg implies; specifically there have been worse chip errors
much more recently than 20 years ago (e.g. amd's somewhat similar phenom
issues). What makes this one worse isn't just the bug, it's how chips are
used: cloud computing makes this much more relevant than similar bugs not too
many years ago.

~~~
someguydave
Now you know how to weight the truth of mass media publications.

------
teekert
Perhaps a bit off topic but I have an (Asus) laptop with a recent Intel chip
running Linux (Solus) and I have no idea how I am to deal with all these CPU
bugs... Any pointers?

~~~
marcolussetti
The patch isn't out yet. Once it's merged in, your distribution will release
patches you can install on the normal way you update your distribution.

~~~
teekert
Ah, ok, so Intel Management engine patches are also distributed in the Linux
Kernel then?

------
runesoerensen
Related discussion
[https://news.ycombinator.com/item?id=16052451](https://news.ycombinator.com/item?id=16052451)

------
juanmirocks
Considering the late Intel problems, Apple is going to be even more tempted to
design its own CPUs/GPUs for the mac.

What do you think, is this realistic?

------
mlrhazi
Would the perf hits introduced by the Linux/Windows patches also be paid by
kernels of guest VMs? or just the hosts/hypervisors?

------
laythea
When pondering whether I should be grumpled about this situation or accept it
as "just how it goes", I wonder if Intel would be OK with me giving them _up
to_ 30% less money after agreeing to 100% before walking out the Intel shop
without prejudice.

~~~
matt4077
I don't know if their will be a recall/class-action lawsuit/whatever. But
clearly there is a difference between making a mistake in what must be one of
the most complicated consumer products on the one hand, and intentionally
violating the terms of an agreed-upon contract?

Tl/DR: Intent matters.

~~~
laythea
Good point and agreed. This will cost them, and clearly was a mistake.

------
nopriorarrests
Can anyone with better knowledge ELI5 to me -- to fix this bug, are cloud
providers have to patch only hypervisor machines, or guest boxes as well? And
if fix is applied to hypervisor, will performance degrade on guest boxes as
benchmark suggests? Thanks!

~~~
dingo_bat
Guest OS shouldn't be an issue, from what I understand. As long as the
hypervisor memory is separated, you're good.

------
Pica_soO
Contracts with fixed guaranteed cloud performance rates just became very
valuable.

------
johnjones4
So is this sort of issue more likely to occur on a non-RISC chip because of
added complexity? I know extremely little about microprocessor design beyond
the 101 knowledge from college so forgive my ignorance.

~~~
amaranth
I think this could occur on any CPU that doesn't have a separate TLB for
kernel mode and has speculative execution. So far it looks like it only occurs
on Intel's CPUs but I don't think that has anything to do with RISC vs CISC. I
believe Linux was at least looking at applying this change to arm64 as well
and this is likely going to lead to a design change in RISC-V to avoid having
issues like this so it can happen to RISC designs as well.

------
Vkkan2016
Patch on Azure already started rollout today on their affected VM's

------
cesarb
This article appears to be jumping the gun. It presents the defect as a fact,
but aren't we still in the "rumor" phase (other than perhaps the few who have
early access to embargoed details)?

~~~
bryanlarsen
Stocks tend to move a lot more on rumour than they do on fact.

~~~
blackflame7000
Trading would be a lot easier if you could wait till the facts come out

------
blackflame7000
Does anyone have insight on the implications this vulnerability might have on
Remote Execution. Is controlling the access to the physical machine
sufficient?

------
gagabity
Is there any real danger for desktop users? We should be allowed to skip this
patch if we dont want it, I would rather take the risk than the performance
hit.

~~~
zzzcpan
For desktop users there should not be any noticeable performance degradation.
But they are also likely the ones in the most danger, since they execute
random code in their web browsers.

~~~
blackflame7000
I might be wrong, but shouldn't browser makers be able to prevent executing
scripts from exploiting the low level memory manipulation this requires?

------
lafar6502
But is the security Bug exploitable in any realistic way?

~~~
blattimwind
[https://twitter.com/brainsmoke/status/948561799875502080](https://twitter.com/brainsmoke/status/948561799875502080)

~~~
cypherpunks01
What does that output mean? He was able to look up an address that was used in
a speculative execution or something?

~~~
blattimwind
He successfully read from kernel memory, the first two bytes from the syscall
table to be precise. The first entry is sys_read (on x86-64 anyway) and the
first field is the address. That's why he shows the full address in the next
line; the PoC exploit read the lower 2 bytes of that address.

------
dom96
Is it just me or was this post's title changed?

~~~
neospice
It's not you, it used to be shorter.

------
pashabitz
I just read yesterday that the CEO sold all his stock except for what he's
required to hold by corporate bylaws, a short while ago.

~~~
pas
it was an automated sale

------
kylehotchkiss
Does anybody know if the 30% performance reduction would apply to Macbook pros
from within the past 2 years?

~~~
Brockenstein
They run Intel CPUs made within the last ten years so would be subject to this
issue. But the performance hit is really dependent on the computing that
you're doing. It's not a guaranteed 30% or a guaranteed 5%.

Are you doing a lot of really CPU intensive tasks that make a lot of syscalls?
Most people aren't. If you are, you'll probably feel that pain. And if you're
not, you probably won't notice a difference. And if you don't know you can
either research if what you're doing typically is going to be affected, or
wait and see.

~~~
cookiecaper
> They run Intel CPUs made within the last ten years so would be subject to
> this issue.

Do we know that? There is a lot of speculation but the embargo is not lifted
yet afaik. There are obviously elements of this that are remaining
intentionally obscured pending embargo expiry (redacted comments), so it
_could_ be that a smaller contingent of chips are affected and no one is
bothering to correct the damage/limit the patch only to applicable components
so that the cat doesn't get out of the bag too soon (side benefit: so that an
extensive emergency fix like this can be widely tested before it's applied to
a relatively limited set of hardware).

Seems just as valid as any other speculation to me.

------
joering2
It must be serious when stock of this size goes 5% down now...

[https://www.google.com/search?q=intel+stock](https://www.google.com/search?q=intel+stock)

Edit: AMD 8% up:
[https://www.google.com/search?q=amd+stock](https://www.google.com/search?q=amd+stock)

------
jokoon
Is that me or there is an increase of critical security flaws over the last 5
years?

------
hellbanner
This is different from the intentional backdoor, Management Engine?

~~~
chrisper
Yes. This is far worse.

~~~
hellbanner
I see - so this is more accessible? We're all fucked, then?

~~~
chrisper
The "fear" with ME is more that governments or someone like that could spy on
us... (not really a "threat" to most people in Western Countries). But still
better to get rid of it. Not an imminent threat per se.

This bug is a true security bug that has been lurking around for 10 years...
and it could have been already abused. This is double scary because this
attack does not leave any traces behind and it allows any application to
pretty much enter God Mode (this is the worst case scenario of a security
situation (hence the name meltdown (like nuklear meltdown is the worst case
situation in a nuclear power plant)).

This bug is also bad because in certain situations the fix of this bug causes
severe peformance penatlty.

You are only fucked if you don't update your OS.

~~~
hellbanner
OS updates will fix this - but the bug remains on the chip, right? Hm, I guess
I'll check for updates =)

------
troncd
My hot take is that we will see a Mirai / qbot variant targeting consumer
laptops and VPSs very, very soon with this exploit. Could cause a lot more
trouble than baby monitors.

------
aagha
I would love an ELI5.

------
runesoerensen
Intel response [https://newsroom.intel.com/news/intel-responds-to-
security-r...](https://newsroom.intel.com/news/intel-responds-to-security-
research-findings/)

~~~
mizzack
> Intel believes these exploits do not have the potential to corrupt, modify
> or delete data.

No, you can just read data you shouldn't be able to.

> Intel is committed to product and customer security and is working closely
> with many other technology companies, including AMD, ARM Holdings and
> several operating system vendors, to develop an industry-wide approach to
> resolve this issue promptly and constructively.

Let's try to drag AMD and ARM into the mud with us.

> However, Intel is making this statement today because of the current
> inaccurate media reports.

"Fake news!"

Well you can't fault the PR folks for trying to spin it. They had to say
_something_.

~~~
ovao
I'd be curious to know which media reports Intel actually finds inaccurate.
I'm sure there are _some_ out there, but I suspect most reports aren't
inaccurate in ways that significantly deviate from the overall message that
Intel's products have a relatively serious security flaw. Making a blanket
statement that implies all the reporting is inaccurate is very disingenuous.

Dragging AMD's and ARM's names into this is completely inexplicable to me
however.

------
hungerstrike
So is today a good day to buy Intel stock?

~~~
chasd00
don't try to catch a falling knife. Let it settle, give it a week or so then
see where it is.

------
secfirstmd
I wonder what the value of this chip flaw would be to the NSA?

------
toyg
This piece should be used in journalism schools.

 _> Advanced Micro Devices Inc. surged [...] after a report that Intel Corp.,
its only remaining rival in the market for personal computer processors_

Ahh, so Intel is the only holdout against the dominant wave of AMD processors,
right?

facepalm.jpg

