Foreshadow app doesn't read correctly about sgx-step

[jovanbulck]

Hmm, looks like most probably your CPU has microcode patches that mitigate Foreshadow (or you have a very recent CPU that has Foreshadow-resistant silicon). The easiest way to make sure you're running unpatched microcode, is to reboot with the dis_ucode_ldr Linux kernel option (as documented in the README). You can check the output of "dmesg | grep microcode" and "cat /proc/cpuinfo"

[barshuker]

i tried rebooting after adding the 'dis_ucode_ldr' option but the results remain the same.

• the "dmesg | grep microcode" command doesn't provide any output now (it did before adding the option..)

• the output of 'cat /proc/cpuinfo' can be seen in the screenshot (it gave about the same information about each core)

[barshuker]

i just checked the CPU package I own and it seems to have an in-silicon mitigation for FORESHADOW.
does that mean that it's not possible to implement the attack on this hardware?

[jovanbulck]

yes, this CPU is Foreshadow-resistant in silicon :-) See also here for an overview table:

https://en.wikipedia.org/wiki/Whiskey_Lake_(microarchitecture)#Spectre_and_Meltdown_mitigations_in_modern_Intel_CPU_architectures

[jovanbulck]

If you want to reproduce Foreshadow-SGX, you'll need access to a Skylake or Kaby Lake processor. Since you have a FS-resistant CPU, I'll close this issue.

[barshuker]

I understand.
if i wish to run this attack on a computer which doesn't support TSX, is there a code for this option?

[jovanbulck]

okay, the PoC code does currently only support TSX. But it should be straightforward to modify the code to register an exception handler instead (using for instance the signal function: https://github.com/jovanbulck/sgx-step/blob/master/app/aep-redirect/main.c#L77)

[barshuker]

thank you very much for your help,
I will try that.
Bar.

[barshuker]

i tried removing the following line
https://github.com/jovanbulck/sgx-step/blob/master/libsgxstep/foreshadow.c#L78

and add the line you suggested, but i see that it already exists in
https://github.com/jovanbulck/sgx-step/blob/master/app/foreshadow/main.c#L92

but the program gets a signal SIGKILL when reaching 'transient_access' (in foreshadow.c), and therefore doesn't reach the exception handler.

[jovanbulck]

Yes, you will have to manually circumvent PTE inversion mitigations applied in recent Linux kernels. The problem now is that the kernel panics and kills the application since it detects that you manually modified the PTE before. The solution is to first call mprotect (resulting in an inverted PTE) and then manually modify the PTE back, and the other way around when handling the fault.

I just pushed a mwe to illustrate the concept (make sure to set USE_TSX=0 in main.c and foreshadow.c):

c43669f

Be aware: this is a highly unoptimized proof-of-concept, only showcasing the general concept and suffering from a relatively low success rate. However, after running the PoC a few times, you should see leakage.

[barshuker]

i replaced the new files and used USE_TSX=0, but the only values i get are 0xFF and 0x00 (i tried to run it many times and increased the number of retries but the results are the same)

[jovanbulck]

Hi, I see, 0xff is from the abort page semantics (after restoring page access rights). Consistently reading 0x00 seems to indicate your CPU and/or ucode is FS-resistant. So make sure this is not the case. The current POC also suffers from noise when entering/exiting the enclave, so you could instead first adopt it to read a non-enclave unmapped (ie non-present) page instead to show the attack.

…

On May 2, 2019 11:39:04 AM GMT+02:00, barshuker ***@***.***> wrote: i replaced the new files and used USE_TSX=0, but the only values i get are 0xFF and 0x00 (i tried to run it many times and increased the number of retries but the results are the same) -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #13 (comment)