More questions regarding unmap_alias() and leaking data

[kmarzouq]

Hello, I have a few more questions.

1.I have been tweaking and studying Intel SGX more and I was wondering why unmap_alias() isn't done right before transient_access() in 'foreshadow_round()' and instead run right before enclave_reload() and foreshadow()?

2. Do you have any idea what the unmap_alias() is translated to assembly?

3. I am successfully leaking data at a low 0.16% rate from an SGX protected enclave, but I am also getting unsuccessful data leaks that are not 0x00 or 0xff. Do you have any guess as to what the incorrectly extracted data is?

[jovanbulck]

hi kmarzouq,

Nice to hear you are studying Intel SGX more, replies to your questions below:

1.I have been tweaking and studying Intel SGX more and I was wondering why unmap_alias() isn't done right before transient_access() in 'foreshadow_round()' and instead run right before enclave_reload() and foreshadow()?

Mainly because you only need to do this once(!) The whole point of the "alias" mapping is to make sure that you have one virtual address mapping that is mapped properly to the physical enclave secret (used by the enclave to populate L1) and one that has the P-bit cleared (used by the attacker to trigger the Foreshadow transient-forwarding effect to leak the secret). See the paper for more details on the idea of the remapping (figure 3).

Do you have any idea what the unmap_alias() is translated to assembly?

It shouldn't matter as this is executed before the attack (in the attacker setup phase). If you want, you can easily check w objdump. In any case, it'll be translated to an mprotect libc (system call) function and a simple memory write (after SGX-Step has aquired a user-space virtual address to write to the alias PTE earlier). See the C code.

I am successfully leaking data at a low 0.16% rate from an SGX protected enclave, but I am also getting unsuccessful data leaks that are not 0x00 or 0xff. Do you have any guess as to what the incorrectly extracted data is?

Note that the PoC Foreshadow implementation provided here is highly optimized and deliberately weakened (ie non-weaponized). So my guess is that:

1. you're probably using the unoptimized non-TSX PoC implementation which has more noise. Consider using TSX or another exception suppression mechanism (eg like an RSB approach)
2. your Flush+Reload threshold is producing false alarms and thus noisy results, ie making it seem like you're leaking incorrect data. Consider using a better, more stable Flush+Reload implementation, e.g., included in cacheutils.h)
3. ultimately, depending on your CPU model and ucode version and experimental setup, it might be that you're inadvertently seeing a Microarchitectural Data Sampling (ie ZombieLoad, RIDL, Fallout) effect here and actually see stale data from the current or sibling CPU core

Hope this helps! As this is a question, and no obvious problems that need fixing in the code, I'll be closing this issue for now. Though feel free to reply for further guidance (or ack if it works) as needed (though I'll be off and unavailable to answer in the next 2 weeks)!