Negative Result: Reading Kernel Memory from User Mode | Hacker News Reader

Negative Result: Reading Kernel Memory from User Mode

cyber.wtf

130 pointsgbrown_5 comments

An (unfairly short) tl;dr could be that not only the memory subsystem itself can be used as a side-channel or leak, but also speculative and OoO execution itself. Speculative execution in this instance also does not consider (likely for performance reasons) certain dependencies (such as between a load setting an exception and a subsequent instruction depending on the load). While the result is still correct after settling, this introduces timing deltas.

This basically adds another set of tools to the architectural-level attack toolbox. From reading this I expect we'll see some interesting developments in the future.

From the TCSEC (1983-1990's) for security certification, a covert channel analysis was required to determine if information leaks was present in an otherwise secure architecture. It always involves a resource two processes share. Here's the basic definitions you use to assess this:

1. It's a storage channel when one process can write to it and another can read it. The temporary storage folders that are world-writable was one example. Another was TCP/IP headers. Memory that wasn't zeroed after use is another.

2. It's a timing channel when it can affect how long a process containing secrets takes to do something and that timing is visible to a process wanting the secrets. Network jitter, hard disk arms, caches, and Intel HT have all been used as timing channels. If it could be visibly timed & noise canceled out enough, then speculative and OoO execution might be another. Worth looking into.

These aren't adding tools, though. They've always been there. People just don't do covert, channel analyses. They even call requirements like that "bureaucratic, red tape with no value for security." Then, rediscover them piece by piece later while still ignoring the prior work. ;)

I think the answer to this is that the processor doesn't speculate past dependent loads, and either the MMU does its access checks before ever issuing a load to the cache hierarchy, or the access check is required to complete before the result of a load is available for further speculative instructions. It's almost certainly the later case, because even though the L1 is virtually indexed (allowing a result to be found and returned), to correctly handle aliasing, the physical tag check must also pass, and address translation has to happen for that.

Which means that basically any instruction dependent on the load has to wait until after the access check passes. No value available means that no further speculation (e.g. using that value to issue further value-dependent loads).

This cannot possibly work because the page tables are not ran between L1 and L2, they are ran parallel to L1. While VIPT caches allow you to know the cache sets without page tables, they cannot choose from the right cache way. So, every way is loaded as the TLBs are accessed and at the end, the correct way is chosen based on the result of the TLB.

For reading memory wouldn't the idea be to test N bits of Kernel Int each in a loop: for each bit in IntX, try speculative execution of bit data get the bit and compute something that switches on 1/0 but with different timings. if(bit==1){expensive execution}else{do nothing} record all timings and reconstruct the IntX bits one by one. I assume something of that sort will allow reading memory without access.

Reply on news.ycombinator.com