Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

521–530 of 639 posts

Re: Reading privileged memory with a side-channel

#521

Post by JdeBP »

kuschku wrote: post #366
hinkley wrote: post #307

Earlier quoted context omitted.

I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize mov…

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.

I suggest some reading first, starting with (but not limited to):

* http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382)

* https://news.ycombinator.com/item?id=10483467

Re: Reading privileged memory with a side-channel

#523

Post by agumonkey »

nlh wrote: post #222

"Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at" Does anyone have any color/details on how this came to be? A major fundamental flaw exists that affects all chips for ~10 years, and multiple inde…

Considering it includes most cpus from the last decade (or even last two), shouldn't they delay it a little bit longer so that not only cloud businesses but also more mainstream companies get the time to deploy patches and tests ?

Re: Reading privileged memory with a side-channel

#524

Post by rtpg »

valleyer wrote: post #460
asveikau wrote: post #432

Earlier quoted context omitted.

> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. It seems like keeping untrusted code in a separate address space would be a suitable workaround? A lot of comments here seem to be implying that meltdown-style reading of separate address spaces is possible via…

No, the Spectre paper discusses cross-process attacks too. First, you use BTB poisoning to coerce the victim process to branch-mispredict to code of your choice (a "gadget"). You can get that code to load memory of your choice, which can be the code of shared libraries (which are usually loaded only once into physical memory for all processes). Then you can do timing attacks using the last-level cache to determine wh…

This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit.

We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires specific entry points for the software you're trying to attack.

I'd like to be proven wrong on this, but it _feels_ like this is more of a software thing like other timing bugs. In theory you can write software that isn't vulnerable

EDIT: my reading of the "JS Spectre implementation" is "JIT code runs in the process of the browser + you can write JS code to read the process's own memory". I can imagine messiness with extensions (1Password in particular).

Re: Reading privileged memory with a side-channel

#525

Post by contrarian_ »

bonzini wrote: post #465
InclinedPlane wrote: post #245

Earlier quoted context omitted.

This is so incredibly bad. Spectre is basically unpatchable . We can do better than we are now with patches but it's all just turd polishing, essentially. A proper fix will require new CPU hardware. And as a kicker? Leaks are basically undetectable.

New CPU microcode is enough, though at a performance price. On pre-Zen AMD there is also a chicken bit to disable indirect branch prediction. (It feels good to be finally able to speak about this freely!!!) I don't know for which processors Intel and AMD plan to release microcode updates.

> New CPU microcode is enough

What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?

Re: Reading privileged memory with a side-channel

#526

Post by contrarian_ »

ytpete wrote: post #370
londons_explore wrote: post #333

Earlier quoted context omitted.

I can't really see how it would be fixable even with new hardware. Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least. Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lo…

Couldn't you do something like have a separate chunk of "speculative cache" which you only commit to the main cache once the speculatively-executed instructions are retired? Sounds complex, sure - but it seems like that would give you the performance benefits of speculative execution while still being able to roll back (or prevent in the first place) any cache-state side effects when branches were mispredicted. Could…

No, that would not be enough. CPUs speculatively execute across multiple branches. Even if you had a separate speculative cache for every code path, you could still build a side-channel from the amount of contention. [1]

[1] https://eprint.iacr.org/2016/613.pdf

> Both hardware thread systems (SMT and TMT) expose contention within the execution core. In SMT, the threads effectively compete in real time for access to functional units, the L1 cache, and speculation resources (such as the BTB). This is similar to the real-time sharing that occurs between separate cores, but includes all levels of the architecture. [...] SMT has been exploited in known attacks (Sections 4.2.1 and 4.3.1)

Re: Reading privileged memory with a side-channel

#527

Post by mike_hearn »

boulos wrote: post #443
rarudduck wrote: post #317

Azure's response: https://azure.microsoft.com/en-us/blog/securing-azure-custom... This part is interesting considering the performance concerns: "The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some…

Disclosure: I work on Google Cloud. If you run a multitenant workload on a linux system (say you're a PaaS or even just hosting a bunch of WordPress side by side) you should update your kernel as soon as is reasonable. While VM to VM attacks are patched, I'm sure lots of folks are running untrusted code side by side and need to self patch. This is why our docs point this out for say GKE: we can't be sure you're runni…

No offence intended as I'm sure it's a bit of a madhouse there right now, but is your statement really correct? I read the Spectre paper quite carefully and it appears to be unpatchable. Although the Meltdown paper is the one that conclusively demonstrated user->kernel and vm->vm reads with a PoC, and Spectre "only" demonstrated user->user reads, the Spectre paper clearly shows that any read type should be possible as long as the right sort of gadgets can be found. There seems no particular reason why cross-VM reads shouldn't be possible using the Spectre techniques and the paper says as much here:

For example, if a processor prevents speculative execution of instructions in user processes from accessing kernel memory, the attack will still work.

and

Kernel mode testing has not been performed, but the combination of address truncation/hashing in the history matching and trainability via jumps to illegal destinations suggest that attacks against kernel mode may be possible. The effect on other kinds of jumps, such as interrupts and interrupt returns, is also unknown

There doesn't seem to be any reason to believe VM to VM attacks are either patched nor patchable.

My question to you, which I realise you may be unable to answer - how much does truly dedicated hardware on GCE cost? No co-tenants at all except maybe Google controlled code. Do you even offer it at all? I wasn't able to find much discussion based on a 10 second search.

Re: Reading privileged memory with a side-channel

#528

Post by Symmetry »

Symmetry wrote: post #266
blattimwind wrote: post #123

Earlier quoted context omitted.

"Which systems are affected?" – "All systems." – "Come again?"

If you're using an in order processor, a Nexus 9 tablet say, then you should be safe.

I wasn't thinking straight last night. Basically all in order application processors use speculative execution.

Re: Reading privileged memory with a side-channel

#529

Post by Symmetry »

kuschku wrote: post #366
hinkley wrote: post #307

Earlier quoted context omitted.

I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize mov…

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.

The performance differential is a concern with classical microkernel designs but not really with modern ones. The process isolation is useful when dealing with Meltdown but not with Spectre.

Re: Reading privileged memory with a side-channel

#530

Post by mike_hearn »

rtpg wrote: post #478
taurath wrote: post #135

Earlier quoted context omitted.

After reading that thread, I sort of wonder if this is the catalyst for the next tech bust. Prices on the basic building block of the modern tech industry (a server shard) going up 30%, or even more as shared/virtual services must be decommissioned for isolation? Surely it’s an alarmist thing to think and I don’t think it’s likely, but if you asked me yesterday the likeihood of an underlying security vulnerability ef…

would be interesting to look at public companies where server costs going up 20% would kill their profit margins.

I don't think this is likely anywhere.

The only sorts of companies where server costs could increase hugely due to a sudden need for hardware isolation are those where they're running tiny or incredibly bursty workloads. Big companies like Netflix that use tons of cores can just binpack their work all together on the same hardware so their jobs only share hardware with other jobs controlled by the same company. Effectively, cloud providers will start offering sub-clouds into which only your own jobs will be scheduled.

This is actually how cloud tech has worked for many years internally. I worked at Google for a long time and their cluster control system (Borg) had a concept called "allocs" which were basically scheduling sub-domains. You could schedule an alloc to reserve some resources, and then schedule jobs into the alloc which would share those resources. Allocs were often used to avoid performance-related interference from shared jobs, e.g. when a batch job kept hogging the CPU caches and slowing down latency sensitive servers. I suppose these days VMs and containers do a similar job, though I think the Borg approach was nicer and more efficient.

I guess this sort of per-firm isolation will become common and most companies costs won't change a huge amount. The people it'll hit will be small mom-and-pop personal servers, but they're unlikely to care about side channel attacks anyway. So I wouldn't sell stock in cloud providers just yet.

Post reply on HN