
Notes from the Intelpocalypse - discreditable
https://lwn.net/SubscriberLink/742702/e23889188fce9f7f/
======
userbinator
_For the owners of vast numbers of systems that cannot be updated, the
consequences will be worse: they will remain vulnerable to a set of
vulnerabilities with known exploits._

Fortunately, chances are that those systems are stable, isolated environments
which won't be running any new and untrusted code either. That means they will
just remain vulnerable in the same way that everyone knows their houses can
always be broken into by a determined-enough attacker; to try to achieve 100%
security, to close all the side-channels, may be impossible and have plenty of
other negative effects.

Sometimes, just knowing is enough because it leads to more informed risk
analysis and decisions. That saying about "known knowns, known unknowns, and
unknown unknowns" comes to mind.

~~~
VikingCoder
But if a system had known exploits that let you execute arbitrary code in user
space, now there's a path to do way worse damage.

It's like it's a multiplicative effect.

------
dzdt
I wonder if it would be possible to peg the kernel to one processor core (or a
subset of the cores) and userspace to the remainder of the cores. As I
understand it, all of the memory caches that are being exploited to leak
information are per-core, so that would give a blanket guard against
kernel->userspace leaks via cache timing.

~~~
j_s
This is the first time I've seen this suggestion; it is something that could
be done relatively easily for systems that otherwise have no
updates/mitigations.

If performance is better some variant of this (auto-scaling dedicated cores)
may even become the default solution rather than all the other workarounds!
Bare metal hypervisors should get their own core(s) too.

Is anyone already doing this? (Qubes, etc.)

~~~
terminalcommand
I remember seeing this suggestion earlier. If I'm not mistaken a commentor
stated that a) this would come with a huge performance penalty b) there would
be synchronization problems in multithreaded scenarios.

Don't take my word for it though, I might have understood it wrong. I imagine
concurrent/parallel execution involving system calls could maybe suffer from
synchronization issues if processes/threads run on different physical cores
with separate caches?

------
Game_Ender
This is the best succinct explanation of the vulnerabilities I have seen to
date.

~~~
Athas
It is. I encourage everyone to buy a subscription to LWN (it's cheap) to
support this kind of high-quality technical reporting.

------
mcross
This is a great writeup.

This article is labelled as subscriber-only content, yet I am not a subscriber
and can see it fine by following this link. Is it as simple as having the
right URL to get to LWN subscriber-only content, or is there some other reason
it can be accessed by non-subscribers?

~~~
servilio
As subscriber you can get a link to share an article, and the posted link is
one of those. Also, subscriber-only content is made public after 7 days.

------
kindfellow92
This post seems to indicate that there is no kernel-level workaround for
variant 1, that contradicts AMD’s statement:
[https://www.amd.com/en/corporate/speculative-
execution](https://www.amd.com/en/corporate/speculative-execution)

LWN seems right on this one, that makes me question AMD’s honesty and
knowledge of the issue.

~~~
evilantnie
I'm not 100% sure here, but I believe this is the specific kernel level fix
that also addresses variant 1
[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

~~~
kindfellow92
No KPTI does not address variant 1.

------
crimsonalucard
So is this article implying that only code executed on branch predictions is
readable? What about normally executed code? What are the exact differences?
How is normally executed code protected and how is branch predicted code not
protected? Any experts care to chime in?

~~~
guelo
Not sure what you mean by normally executed code. Speculative execution
happens in normal everyday conditional code such as if/switch statements, and
most loops unless the compiler unrolls them.

~~~
crimsonalucard
By normal I mean code that wasn't predicted. Predicted code execution is
"abnormal" because it might not contribute to the final result.

My question is why is predicted code exploitable and why is unpredicted code
not exploitable? Both are executed, both have values written to registers,
what's going on?

Apologies for the noobness of this question.

~~~
netsharc
To use a really stupid analogy, imagine a cook in an Mafia-involved
restaurant, and you're a cop (you're the adversary). There's a whiteboard in
the boss' office with a number you want to know.

So you come there every day and say, "Hey, if the lights at (some address) are
on, I want a cheese pizza, otherwise I want pasta.". In the beginning he sends
his boy to check the light at that address, and the boy takes 20 minutes to go
and check, and all that time he has to wait before he can make you the pizza.
After a while the boy always says "The lights are on", so after a while the
cook would still send the boy, but he would anticipate the answer "the lights
are on" and he would start a making pizza. Once in a while (maybe once every 6
months) the boy would return saying the lights are off, so after 20 minutes of
making the pizza, he would throw away the pizza and make you pasta.

After doing this a lot, you say, "Hey, if the lights at (some address) are on,
I want a pizza with the topping from the box numbered according to the number
written on your boss' whiteboard. Otherwise, I want pasta.". You know the
lights will be off, but he starts making pizza with some topping you can't
tell, but you notice he got a box from the fridge to put it next to his pizza-
making table. The boy returns, he throws away the pizza and makes you pasta.
Then you ask him, "Hey, I have another order, can I get a pizza with a topping
from box 1?". If he goes to the fridge to get that box, then you know the box
he picked up earlier (while he was guessing that the boy would say the lights
are on) was not box 1, so you ask for another pizza with topping from box 2,
etc. But if he doesn't go the fridge, you know he picked up that box
previously (because he predicted the boy will tell him the lights will be on),
and that's how you figure out what number is written on the boss' whiteboard:
when the cook doesn't go to the fridge, it's because the box with that number
is already on his table.

The whiteboard is the secret memory area, taking the box from the fridge is
reading from some RAM address to cache (if it's already in cache, no need to
read from RAM), and I hope the speculative execution is clear.

This analogy describes (very roughly) one of the exploits in Spectre.

------
j_s
IIRC, the GCE security white paper mentioned alarms triggered by ROWHAMMER,
another hardware design defect. Is it possible to reliably detect any of this
year's new attacks?

------
cmurf
See the comments. FSMark with mitigation showed a 50% performance loss. So
that immediately makes me wonder about any file system intensive operation,
like databases, getting hit far worse than the 5-30% hit that's been floated
thus far.

