Efficiently mitigating transient execution attacks using the unmapped speculation contract

© 2020 Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2020. All rights reserved. Today's kernels pay a performance penalty for mitigations-such as KPTI, retpoline, return stack stuffing, speculation barriers-to protect against transient execution s...

Full description

Bibliographic Details
Main Authors: Behrens, J, Cao, A, Skeggs, C, Belay, A, Frans Kaashoek, M, Zeldovich, N
Other Authors: Massachusetts Institute of Technology. Computer Science and Artificial Intelligence Laboratory
Format: Article
Language:English
Published: 2021
Online Access:https://hdl.handle.net/1721.1/137797
Description
Summary:© 2020 Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2020. All rights reserved. Today's kernels pay a performance penalty for mitigations-such as KPTI, retpoline, return stack stuffing, speculation barriers-to protect against transient execution side-channel attacks such as Meltdown [21] and Spectre [16]. To address this performance penalty, this paper articulates the unmapped speculation contract, an observation that memory that isn't mapped in a page table cannot be leaked through transient execution. To demonstrate the value of this contract, the paper presents WARD, a new kernel design that maintains a separate kernel page table for every process. This page table contains mappings for kernel memory that is safe to expose to that process. Because a process doesn't map data of other processes, this design allows for many system calls to execute without any mitigation overhead. When a process needs access to sensitive data, WARD switches to a kernel page table that provides access to all of memory and executes with all mitigations. An evaluation of the WARD design implemented in the sv6 research kernel [8] shows that LEBench [24] can execute many system calls without mitigations. For some hardware generations, this results in performance improvement ranging from a few percent (huge page fault) to several factors (getpid), compared to a standard design with mitigations.