
CPU hardware vulnerable to side-channel attacks - contrarian_
https://www.kb.cert.org/vuls/id/584653
======
userbinator
Side-channel attacks are notoriously difficult to prevent:

[https://en.wikipedia.org/wiki/Tempest_(codename)](https://en.wikipedia.org/wiki/Tempest_\(codename\))

I suspect these sorts of attacks will exist as long as people try to share
running untrusted code on the same hardware.

~~~
Klathmon
It's not just untrusted code, it's all code.

"Trusted code" is one exploit away from being untrusted code. And solving that
requires not accepting untrusted input, which makes most general purpose
computing useless.

Has there been any research into solving this problem at the hardware level?
I'm imagining something like having hundreds or thousands of distinct
processors on a PC all isolated each running only one process.

It sounds extreme, but over time I've basically learned to treat
"optimization" as a synonym for "introduces side channel attacks", and without
something that can protect against a large majority of these kinds of
exploits, computers are only going to get less secure.

~~~
TrevorJ
Even with distinct processors, there would still be something in charge of who
gets to use what hardware resource. I suspect that would be where the attack
vector would shift.

~~~
Klathmon
At least _some_ of those resources can only deal with encrypted data to reduce
the amount of leakage to acceptable levels.

Or maybe we can contain the problem by having a kernel that manages access to
all resources, but keeps individual processes on nearly separate hardware.

As you can probably tell, I have no idea what I'm talking about here, but the
more of these big side channel attacks that come out, the more I'm feeling
that there is no way to securely share a machine among multiple processes
without just giving up and letting them all have access to one another.

------
jstewartmobile
I wish desktop chips would trade a little performance for more simplicity and
robustness. Even at half-speed, they are still pretty damn fast, and a lot of
the bleeding-edge stuff was pushed over to the GPU a long time ago.

The economics are also a little off. If this were something like ARM64, the
eventual replacement chip would be a few bucks instead of a few hundred. In
that situation, I wouldn't get too upset about it. It would be like, "Oh well,
I guess I have an excuse to upgrade my CPU now."

~~~
interfixus
Hear! In them olden days of yore, writing x86 assembly, I had a decent mental
model of what my code was doing when.

I no longer do.

~~~
jstewartmobile
" _These days I spend more time optimizing code for ARM chips than for Intel
chips. The real reason for this isn 't any sort of assessment of current or
future importance. The real reason is that ARM publishes the detailed pipeline
documentation that I need, so squeezing out every last cycle for ARM is fun,
while Intel hides the pipeline documentation, so squeezing out every last
cycle for Intel is painful._"

[https://blog.cr.yp.to/20140517-insns.html](https://blog.cr.yp.to/20140517-insns.html)

------
kardos
On one hand, great news for Intel: everyone needs a new chip. On the other,
terrible news for Intel: AMD's offerings are pretty competitive these days.
It'll be interesting to see how this plays out.

~~~
jl6
Do Intel even sell any non-vulnerable CPUs?

~~~
Narishma
First couple of generations of Atoms, before they went out-of-order.

------
reacweb
Maybe the CPU is the wrong place to perform sophisticated optimizations. IMHO,
the CPU should be far more simple and the intelligence should be in the
compiler.

~~~
chrisseaton
This has been tried several times and it just doesn't look like it works in
practice. Delay slots, Itanium, etc.

The CPU is a bit like a JIT in that it can see how the program is really
running and optimise for those conditions, which the AOT compiler cannot. Your
AOT compiler may not know you're going to take a branch more times than not,
but your CPU may be able to work that out at runtime. And then tomorrow you
may never take the same branch and it'll work that out as well for the same
code.

~~~
std_throwaway
The compiler only knows about the program and maybe statistical information
about the data.

The CPU knows about the actual data currently being processed.

Therefore, the CPU can do more by using branch prediction and speculative
execution. It is more expensive in terms of energy per computation but so far
it was worth it. The CPU can also optimize old code on-the-fly.

------
ashark
I can't figure out whether this means that OS-level mitigation of the problem
doesn't prevent all avenues for exploitation. The headline implies it (and
probably made it to the front page based on that implication) but TFA doesn't
make it clear whether that's true.

~~~
contrarian_
Any branch on attacker-controlled data can be speculatively bypassed. You
would have to at the very least recompile all applications to attempt to
mitigate the two Spectre variants discussed so far.

Unless there is some way to turn off speculation entirely, but that would hurt
performance _badly_.

~~~
orblivion
So why are the OSes bothering to patch anything?

~~~
contrarian_
There are (at least) two separate things going on. Meltdown, the flaw
exclusive to Intel and some ARM CPUs, is very easy to exploit and is the one
being patched by OS vendors.

Spectre is a whole other can of worms, on the one hand it's more tricky to
exploit, on the other hand there might not be an easy fix and people are
speculating (no pun intended) that it will have to be dealt with in hardware.

~~~
justrobert
Spectre works in javascript due to how aggressive the JIT is.

Chrome and Firefox are already working on solutions as you cannot exploit the
JIT if it generates code that ruins your timing as far as I'm aware.

So that solves the problem for most people, but all other environments that
allow execution of untrusted code also need to be updated.

------
gaius
In the old days this would be no biggie as every non-trivial site would have
at least half a dozen different kinds of Unix workstations anyway. SPARC,
MIPS, PA-RISC, AXP, m68k, POWER...

~~~
mtanski
In the good old days everybody just used HTTP, FTP and telnet and NIS. Old
archs also has other bugs we forgot about / never discovered.

~~~
gaius
The point being: monocultures are fragile.

~~~
mtanski
Spectre impacts current iterations of: x86, ARM and Power. It's most likely
impacts other archs that have variants of CPUs with out-of-order execution.

~~~
gaius
Spectre is harder to exploit - it’s the Intel-specific one that’s the biggie.

------
y0ghur7_xxx
so i bought my cpu a few months ago. will intel replace it for free?

~~~
nikanj
After 15 years of class action appeals, you’ll get a voucher for $15 off of a
retail-packaged processor.

~~~
QAPereo
Meanwhile the lawyers and original plaintiffs will be able to buy their own
sex islands...

~~~
nasredin
... with sex dolls... with Intel Inside stickers on them?!

;)

------
noja
this is our golden opportunity to switch to something less privacy evading and
bug-ridden.

(and it will incidentally also prove that the market really doesn't work very
well, because most people will _still buy intel_ )

~~~
krylon
The problem is that there are not many alternatives.

AMD claims their current CPUs are not affected, but they still have the PSP,
AMD's equivalent to Intel's ME. I suppose it has not been probed as thoroughly
as ME because of Intel's bigger market share.

ARM CPUs are - according to Intel - also vulnerable, which disqualifies almost
all other competitors.

I had hoped that the Longsoon chips would amount to something; I vaguely
remember Richard Stallman used a notebook with Longsoon processor, but none of
the vendors I checked at the time had even heard of it. And if you are
paranoid enough, a Longsoon-based system might just replace the NSA with their
chinese equivalent.

The only viable alternative from a technology point of view that I am aware of
is the Talos Raptor workstation. Unfortunately, it is rather expensive. Okay,
for a high-end workstation, the price is not unusual. But compared to the
price of a regular office PC, it is very expensive.

~~~
reirob
I'm also looking at Raptor Hardware and I would love to hear the experience
from somebody that uses it.

As well, I am not sure that POWER9 is immune to these attacks. And then, well,
you still cannot buy their products, as far as I understand it from their page
[1].

Does anybody know more about the Raptor systems?

[1]: [https://raptorcs.com/](https://raptorcs.com/)

------
m3kw9
Anyone know the implications to the security of the crypto currencies? Are
they highly prone to theft now?

~~~
brndnmtthws
Not if you use a hardware wallet (Ledger or TREZOR). If you're using a web
(Coinbase) or desktop wallet, you might be at risk. In reality, it's pretty
unlikely to be exploited.

Someone could steal your login credentials for any web service, but the risk
is mitigated if you use 2FA, or some sort of IP whitelisting.

~~~
anonemouse145
What happens when you use that wallet by plugging it into the computer, or by
entering its information on a computer to perform a transaction?

People say "Hardware wallet" like it's a magic incantation.

~~~
brndnmtthws
If you use a hardware wallet, the private keys only exist on the device, and
therefore cannot be stolen using this attack vector. The Ledger uses a secure
element, which is an entirely separate MCU, and (as far as we know) can't be
'hacked' by any script kiddies.

However, if you for some reason decided to store the wallet seed on your
computer, it's no longer secure.

~~~
domenukk
An attacker can still use the hardware wallet to transfer money as long as
it's plugged in. To prevent this you need external hardware with a display and
external input (that cannot be reflashed through usb (!)).

~~~
brndnmtthws
Wrong. The hardware wallet requires physical access to sign transactions with
the private key (you have to press the button to acknowledge the transaction).

------
darkmx0z
disable high resolution clocks for non-sudo programs?

