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

591–600 of 639 posts

Re: Reading privileged memory with a side-channel

#591

Post by ant6n »

caf wrote: post #440
bloorp wrote: post #217

Earlier quoted context omitted.

As I read through the meltdown paper, it looks really difficult to have the security we want and the performance we want at the same time. It's pretty crazy, but here's my limited understanding: There's a huge shared buffer between two threads. 256 * 4K. One thread reads a byte of kernel memory, literally any byte it wants, and it then reads one of those 4K pages from that buffer in order to cache that one memory pag…

The MELTDOWN one is the easy one (as is evident by the fact that this is the one that only seems to affect Intel CPUs). When a load is found to be illegal, an exception flag is set so that if the instruction is retired (ie. the speculated execution is found to be the actual path taken), a page fault exception can be raised. To prevent MELTDOWN, at the same time that the flag is raised you can set the result of the lo…

Maybe separate BTBs. Or maybe disable branch target prediction when in kernel mode (but then some VM process may still observe some other process running inside a different VM via a side channel).

Re: Reading privileged memory with a side-channel

#592

Post by wvenable »

craigyk wrote: post #587
DougN7 wrote: post #585

Earlier quoted context omitted.

Great explanation - thank you. One thing I don’t understand is how this can be exploited from javascript. Does it have timing primitives so fine it can tell the difference between a memory lookup served from memory va from cache?

Yes it does because javascript execution has had to become very fast. Fast means you can run a very tight loop that updates a counter to create a fairly high-resolution clock.

What I don't understand is how the branch predictor is even exploitable from JavaScript -- it doesn't have pointers. How can it "request" arbitrary memory locations and time the results?

Re: Reading privileged memory with a side-channel

#594

Post by jerrycruncher »

jeremyjh wrote: post #421
jerrycruncher wrote: post #391

Earlier quoted context omitted.

"Turn of the century"? JS was used for little more than swapping images on mouseover and changing/"animating" title bar text back then. The "you will see absolutely nothing or a ream of {{blah}} text" without js enabled really only became prevalent in the last 5-or-so years. Even in the halcyon days of jQuery usage you could get around quite comfortably without js, as js was still being used to augment webpages rathe…

It wasn't common practice, but fully Javascript rendered applications were a thing as early as 2001. That was when my company developed the first one that I know of. It was a godawful ugly pig but it worked. Most sites did nothing like that, but they did use Javascript and would break in various ways without it. At that time, there were a lot of people admonishing web developers to test their applications with Javasc…

I'm not denying that the technology was sort of there (especially/only if you were writing a corporate app that targeted one and only one browser, probably as a replacement for an in-house VB/WinForms app). My point, which you mostly reinforced, was that it was not at all common for a user opting not to enable javascript to see a completely broken public-facing site until relatively recently.

Re: Reading privileged memory with a side-channel

#595

Post by j_coder »

koverstreet wrote: post #498
j_coder wrote: post #198

Isn't possible for the kernel to patch all clflush instructions when the software is loaded to keep a circular list of all evicted addresses that would be evicted again on the interrupt that happens when the protected address is read? This way the the timing attack would not be possible.

self modifying code (which exists) would take a massive performance hit. any time a page is marked +X, the kernel would have to mark it -W, and then on page fault the kernel would have to check if userspace was changing something to a clflush instruction. oh, and x86 has variable length instructions - the same byte stream can decode as different instructions depending on where you start - so i doubt it's possible at…

You are right.

The best approach is to evict all user space pages from cache when an invalid page access happens if the page fault was caused by the software trying to read/write kernel space pages.

Massive performance hit but only to misbehaved software. Normal software will not have the performance hit of the current solution.

Kernel could even switch to unmapped kernel pages solution if too many read/write attempts.

Re: Reading privileged memory with a side-channel

#596

Post by hyperion2010 »

wvenable wrote: post #592
craigyk wrote: post #587

Earlier quoted context omitted.

Yes it does because javascript execution has had to become very fast. Fast means you can run a very tight loop that updates a counter to create a fairly high-resolution clock.

What I don't understand is how the branch predictor is even exploitable from JavaScript -- it doesn't have pointers. How can it "request" arbitrary memory locations and time the results?

It has byte arrays and indexing on those which is equivalent to having pointers. See page 6 and 7 of the Spectre paper.

Re: Reading privileged memory with a side-channel

#597

Post by rasz »

ant6n wrote: post #584
rasz wrote: post #373

Earlier quoted context omitted.

Keep a small pool of cache lines exclusive to speculative execution, discard when non taken, rename affected cache lines (like register renaming so no copy) when taken.

Also, separate BTB for each process and privilege level.

Yes, this would have a bonus effect of actually gaining IPC in multi process loads.

Re: Reading privileged memory with a side-channel

#598

Post by lma21 »

314 wrote: post #537
hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown: A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room. An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of…

What is the analogy behind being able to go into the restricted room?

Re: Reading privileged memory with a side-channel

#599

Post by feelin_googley »

In 1-2 words, IMO, the problem is "over-optimisation".

It is perhaps beneficial to be using an easily portable OS that can be run on older computers, and a variety of architectures.

Sometimes older computers are resilient against some of todays attacks to the extent those attacks make assumptions about the hardware and software in use. (Same is true for software.)

When optimization reaches a point where it exposes one to attacks like the ones being discussed here, then maybe the question arises whether the optimization is actually a "design defect".

What is the solution?

IMO, having choice is at least part of any solution.

If every user is effectively "forced" to use the same hardware and the same software, perhaps from a single source or small number of sources, then that is beneficial for those sources but, IMO, counter to a real solution for users. Lack of viable alternatives is not beneficial to users.

Re: Reading privileged memory with a side-channel

#600

Post by foota »

lma21 wrote: post #598
314 wrote: post #537

Earlier quoted context omitted.

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown: A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room. An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of…

What is the analogy behind being able to go into the restricted room?

You can call into the kernel.

edit: s/call into/trigger a syscall/

Post reply on HN