search

keystone-enclave / keystone-sdk

SDK for Keystone Enclave - ABI/SBI libraries and sample apps
Other
44 stars 22 forks source link

Missing sanitisation of FPU rounding mode and exception flags on enclave entry/exit #72

Open david-oswald opened 3 years ago

david-oswald commented 3 years ago

Not quite sure where to open this issue, I put it here - if you think it should go somewhere else feel free to close this issue and put it where it belongs.

The initial idea for this issue comes from one of our recent papers: https://jovanbulck.github.io/files/acsac20-fpu.pdf where we reported similar issues in several SGX runtimes (including MS OE and Intel SDK).

The basic problem is that the global RISC-V FPU rounding control register frm is apparently not sanitised on enclave entry. This means that an untrusted attacker can change the rounding mode outside the enclave and - depending on the setting - the enclave will give different outputs for floating point computations.

See here for a (hacky) diff that - when applied to master - demonstrates this with the hello-native QEMU example:

poc_fpu_poisoning.txt

Basically this performs a floating-point computation (2.1 * 3.4) in the enclave with different rounding modes set from the untrusted host through fesetround(). The output is something like this:

# insmod keystone-driver.ko
[   12.225487] keystone_driver: loading out-of-tree module taints kernel.
[   12.231693] keystone_enclave: keystone enclave v1.0.0
# cd hello-native/
# ./hello-native.ke
Verifying archive integrity... All good.
Uncompressing Keystone Enclave Package
Run with fesetround(FE_UPWARD)
Enclave said: 7.14000000000000056843418861
Run with fesetround(FE_DOWNWARD)
Enclave said: 7.13999999999999968025576890

This issue could be mitigated by setting a fixed frm on enclave entry, and restoring the previous frm on exit. This could probably either happen in the SM or the runtime, depending on what you think is best.

david-oswald commented 3 years ago

Similarly, it seems that the FPU exception flags are not cleared on enclave exit, hence the untrusted host can determine whether any FPU overflow/underflow exceptions have occurred - this can be used as a controlled channel in certain situations to extract enclave secrets (see the paper). PoC here:

poc_exceptions.txt

Finally, I'm not quite sure but it seems to me that the FPU registers (f0 - f31) are not cleared by the SM, which of course would lead to leakage as well.