Meltdown: Reading Kernel Memory from User Space

Meltdown: Reading Kernel Memory from User Space. Moritz Lipp and colleagues published this research at USENIX Security in 2018. They investigated how a user-mode load that should fail could nevertheless use supervisor-only data briefly before the processor raised the fault. That fleeting access became an observable cache trace: the transient byte selected a cache line that remained observable after rollback, while isolating kernel page tables blocked access to ordinary kernel and physical mappings in their tests.

Start with transient execution. A processor may execute an instruction and later discard its visible result because the instruction should not have completed. That rollback cleans up the state software is meant to see, but it may leave an internal hardware effect, such as a cached location. Meltdown is the condition in which data forbidden by a privilege or exception check influences that internal state before the fault takes effect. The attacker cannot keep the forbidden load’s normal result, but can use the remaining cache evidence to work out what the value was.

The research question was whether the processor’s eventual access denial arrived too late to protect the data. More specifically, could attacker-controlled instructions name a protected address, transiently use its byte, and convert that momentary use into something observable after rollback? Meltdown did not depend on training a branch predictor or finding a useful instruction sequence inside victim software. The attacker’s own instructions selected the target, making the privilege-check behavior itself the object of the experiment.

The attack begins with a user-mode load from a supervisor-only address. On an affected processor, the forbidden byte can be forwarded transiently before the fault is raised. That byte then selects a line in a probe array, changing the cache. When the processor discards the forbidden computation, the selected cache line remains observable, allowing the attacker to infer the byte indirectly. The researchers exercised this mechanism across multiple processor generations and operating systems, then used controlled browser, memory, and container case studies to examine what information could be recovered.

The experiments demonstrated kernel or physical-memory disclosure on tested Linux and Windows systems. In a controlled Firefox case study, the researchers recovered saved-password material from physical memory. Controlled Docker, LXC, and OpenVZ tests also showed that their container boundaries did not stop leakage through the shared kernel. Performance could be substantial under favorable conditions: one detailed cached-data evaluation reached 582 KB/s. These are demonstrations on evaluated configurations, not measurements of how often exposed systems were attacked in the wild.

The speed measurements depended heavily on where the target data was available. Data already resident in the L3 cache was recovered at about 12.4 KB/s. In an optimized uncached case, the rate was 3.2 KB/s, and uncached recovery overall was much slower. The faster cached result therefore should not be treated as a universal extraction rate; the evaluated conditions materially affected throughput.

The hardware findings are bounded by the processors tested. The researchers did not reproduce the attack on their tested AMD processors or on most tested Arm cores, so the results do not support a vendor-wide claim about every processor. Their cloud testing deliberately avoided unrelated tenant data and therefore did not establish cross-customer exploitation. Page-table isolation also leaves a minimal set of entry and transition pages mapped. Poorly designed remnants could still expose pointers or other information, even though ordinary kernel and physical mappings were inaccessible in the researchers’ tests.

For operating-system and platform teams, the demonstrated mitigation is KAISER-style page-table isolation. It prevented access to ordinary kernel and physical mappings in the researchers’ tests. Teams should also review the minimal entry and transition pages that remain mapped for pointers or other sensitive information. Container security teams should not treat a shared-kernel boundary as sufficient protection against this leakage, given the controlled Docker, LXC, and OpenVZ results.

Lipp and colleagues connected a forbidden transient load to cache evidence that remained observable after rollback, then demonstrated disclosure on tested systems and in controlled memory case studies. The evidence supports removing ordinary kernel mappings from user-mode page tables and scrutinizing the few transition pages left behind. It does not establish that every processor is vulnerable or that the cloud tests achieved cross-customer compromise.