LLVM Merges x86 LFI "Lightweight Fault Isolation" Target For In-Process Sandboxing
([LLVM] 6 Hours Ago
x86 Lightweight Fault Isolation)
- Reference: 0001645791
- News link: https://www.phoronix.com/news/LLVM-x86-LFI-Merged
- Source link:
Stanford researchers have been developing Lightweight Fault Isolation "LFI" compiler passes and targets for LLVM as a means of efficient, native code sandboxing. The AArch64 LFI target was previously upstreamed while this week the x86/x86_64 LFI target was also upstreamed for this means of in-process sandboxing.
Lightweight Fault Isolation is a compiler-based approach for efficient, in-process sandboxing to help provide performance and compatibility of existing code while helping to fend off memory safety bugs and the like for C, C++, and Assembly. LFI aims to have "minimal performance overhead and engineering effort."
LFI was born out of Stanford research while Google and others have been interested in this research for helping to provide additional memory safety to C/C++ code with minimal cost. Google in turn has also been contributing engineering resources to LFI.
Some key takeaways from last year's [1]LFI RFC :
"Lightweight Fault Isolation (LFI) aims to support low level software sandboxing with minimal extra constraints. LFI eschews platform independence, and gives the compiler and runtime maximum freedom to exploit platform specific hardware or novel optimization techniques. At the same time, LFI tries to adhere as closely as possible to the existing target ABI and binary conventions (e.g. ELF and Dwarf specifications) with a few caveats (e.g. reserve registers) to maintain compatibility with existing code and tools.
...
Our current LFI implementation supports both ARM64 and x86-64 processors. Since LFI sandboxes are in-process, sandbox context switches are just 10s of cycles, often ~100x faster or more than process-based sandboxes.
LFI’s closer to the metal approach offers a 3x-10x reduction in sandboxing overheads vs. state-of-the-art Wasm toolchains. On Spec2017, it incurs roughly 7% overhead on AArch64 vs. native code for full sandboxing, and 2% overhead when only sandboxing writes (providing integrity but not secrecy).
LFI is neutral to the system call/library interface, thus we are able to support both unmodified libraries (using the linux system call interface) and device drivers through the use of different runtimes."
Following the AArch64 LFI target having been upstreamed to LLVM, with [2]this pull request now merged for LLVM 23, the initial x86_64 LFI target is also in place.
It will be interesting to see where this LFI development leads and ultimately how much uptake it sees and how robust it proves for providing additional memory safety for existing C/C++ code.
[1] https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380
[2] https://github.com/llvm/llvm-project/pull/189569
Lightweight Fault Isolation is a compiler-based approach for efficient, in-process sandboxing to help provide performance and compatibility of existing code while helping to fend off memory safety bugs and the like for C, C++, and Assembly. LFI aims to have "minimal performance overhead and engineering effort."
LFI was born out of Stanford research while Google and others have been interested in this research for helping to provide additional memory safety to C/C++ code with minimal cost. Google in turn has also been contributing engineering resources to LFI.
Some key takeaways from last year's [1]LFI RFC :
"Lightweight Fault Isolation (LFI) aims to support low level software sandboxing with minimal extra constraints. LFI eschews platform independence, and gives the compiler and runtime maximum freedom to exploit platform specific hardware or novel optimization techniques. At the same time, LFI tries to adhere as closely as possible to the existing target ABI and binary conventions (e.g. ELF and Dwarf specifications) with a few caveats (e.g. reserve registers) to maintain compatibility with existing code and tools.
...
Our current LFI implementation supports both ARM64 and x86-64 processors. Since LFI sandboxes are in-process, sandbox context switches are just 10s of cycles, often ~100x faster or more than process-based sandboxes.
LFI’s closer to the metal approach offers a 3x-10x reduction in sandboxing overheads vs. state-of-the-art Wasm toolchains. On Spec2017, it incurs roughly 7% overhead on AArch64 vs. native code for full sandboxing, and 2% overhead when only sandboxing writes (providing integrity but not secrecy).
LFI is neutral to the system call/library interface, thus we are able to support both unmodified libraries (using the linux system call interface) and device drivers through the use of different runtimes."
Following the AArch64 LFI target having been upstreamed to LLVM, with [2]this pull request now merged for LLVM 23, the initial x86_64 LFI target is also in place.
It will be interesting to see where this LFI development leads and ultimately how much uptake it sees and how robust it proves for providing additional memory safety for existing C/C++ code.
[1] https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380
[2] https://github.com/llvm/llvm-project/pull/189569