Exploit mitigations
This issue will cover the mandatory and optional exploit mitigations for Redox.
As Redox is written in Rust there's memory-safety though the compiler, thus it might make sense to disable most exploit mitigations, at least by default.
But Redox is not fully safe Rust because many crates rely on less thoroughly checked unsafe, such as when heavily using FFI. Therefore, it might make more sense to enable mitigations for such programs, as well as for C/C++ programs, even though unsafe Rust is generally still safer than C/C++.
Exploit mitigations specific to C/C++ memory errors are unnecessary for safe Rust code.
Criteria
The exploit mitigations on this issue must follow some criteria.
- The mitigation is needed for microkernel-based systems?
- If the mitigation is cheap (low performance penault) and the security benefit is considerable, it can be enabled by default.
- Classify if it's a compiler, manual system-wide/some programs or x86-specific mitigation.
Mitigations
This list will filter the exploit mitigations.
- Address Space Layout Randomization - userspace
-
Kernel Address Space Layout Randomizationprobably overkill for a microkernel; seL4 for example uses-static -fno-pie -fno-pic
- Position-Independent Executables - compiler-based
- RELRO
- BIND_NOW
- SEGVGUARD (ASLR brute force protection)
- W^X (memory mappings and switching pages)
- SROP
- Trusted Path Execution
- SafeStack
- Non-Cross-DSO Control-Flow Integrity
- Retpoline - Spectre mitigation for monolithic kernels?
Implementations
This list will track the exploit mitigations implementation.
-
SMAP - x86-specific, manual system-wide -
SMEP - x86-specific, manual system-wide -
Zero-initialized userspace stack - manual system-wide -
Read-only pages where necessary - manual? -
IP ID randomization - netstack or smoltcp? manual. -
Temporary IPv6 addresses - netstack or smoltcp? manual.