* Disable redzone. Our LVI mitigations clobber it.
This disables the redzone in the gcc compiled SDK, the
cargo compiled enclave, the cargo dependencies, and so forth.
BOLT is modified to fail if any function that gets a
memory indirect jmp mitigation uses the redzone.
The checker is also modified to check and fail the build if
any functions use the redzone that had a memory indirect jmp
mitigation applied.
* Disable redzone. Our LVI mitigations clobber it.
This disables the redzone in the gcc compiled SDK, the
cargo compiled enclave, the cargo dependencies, and so forth.
BOLT is modified to fail if any function that gets a
memory indirect jmp mitigation uses the redzone.
The checker is also modified to check and fail the build if
any functions use the redzone that had a memory indirect jmp
mitigation applied.
Co-authored-by: Nolan Leake <nolan@sigbus.net>
Not sure how it was ever building for me, but a warning (combined
with -Werror) broke it. Ugly hack to fix it for now, bug filed
upstream:
https://github.com/huku-/pyxed/issues/17
This change updates to a newer version of our BOLT fork that supports
mitigating LVI vulnerabilities. This required removing our memcmp
optimization, as there is no safe way to do it in the presence of LVI.
It also required disabling retpoline insertion, since they are
incompatible with the LVI ret mitigation. This is safe since our
current microcode version contains a mitigation already.
This also adds a verifier that verifies that there are no unmitigated
instructions in the enclave. This required adding Intel Xed to the
build, to analyze instructions.
After this, the enclave is around 22% lfence instructions. The
performace impact vs an unmitigated enclave is 1.2x-3.9x, though
with realistic latency added between enclaves the difference drops
to around 1.0x-2.5x, with our critical partition transfer showing
around 1.1x.
