Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enclave creation failure #34

Closed
akkapakasaikiran opened this issue Nov 28, 2020 · 14 comments
Closed

Enclave creation failure #34

akkapakasaikiran opened this issue Nov 28, 2020 · 14 comments

Comments

@akkapakasaikiran
Copy link

Hey, we're currently trying to build the 'foreshadow' app but when we run the makefile we get this error:

[main.c] Creating enclave...
Error calling enclave at main.c:153 (rv=0x2006)
Makefile:48: recipe for target 'run' failed
make: *** [run] Aborted

We followed the instructions from the README.md of sgx-step and then executed make run in app/foreshadow.
This is a slight time-critical issue, @jovanbulck we'd appreciate it a lot if you could help us out. Thanks!

@jovanbulck
Copy link
Owner

hm, this is an issue with the linux-sgx SGX-SDK. Most probably either your SGX driver is not properly installed, or SGX is not properly enabled on your system, or (most likely) the AESM service has crashed and needs to be restarted.

Top of my head, try this:

$ dmesg | tail
$ sudo service aesmd status
$ sudo service aesmd stop
$ sudo serivce aesmd start
$ sudo service aesmd status

If that doesn't work, you might want to check the SDK and driver are of compatible versions and you don't have the sgx-sdk Ubuntu packages installed?

@jovanbulck
Copy link
Owner

see also here for the error code you get:

https://github.com/intel/linux-sgx/blob/d10c025eb0bfe0c53e524a486f2d17307d0f1206/common/inc/sgx_error.h#L64

    SGX_ERROR_NO_DEVICE          = SGX_MK_ERROR(0x2006),      /* Can't open SGX device */

Did you install the SGX driver using ./install_SGX_driver.sh or following the instructions in the linux-sgx-driver git submodule? Do you have /dev/isgx/, did you see an error in dmesg?

@akkapakasaikiran
Copy link
Author

akkapakasaikiran commented Nov 28, 2020

Thanks for the prompt response.

dmesg | tail resulted in:
[ 3746.515848] pcieport 0000:00:1c.4: AER: device [8086:9d14] error status/mask=00001000/00002000
[ 3746.515851] pcieport 0000:00:1c.4: AER: [12] Timeout
[ 3749.505861] pcieport 0000:00:1c.4: AER: Multiple Corrected error received: 0000:00:1c.4
[ 3749.505872] pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[ 3749.505877] pcieport 0000:00:1c.4: AER: device [8086:9d14] error status/mask=00001000/00002000
[ 3749.505880] pcieport 0000:00:1c.4: AER: [12] Timeout
[ 3749.898508] pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
[ 3749.898518] pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[ 3749.898523] pcieport 0000:00:1c.4: AER: device [8086:9d14] error status/mask=00001000/00002000
[ 3749.898526] pcieport 0000:00:1c.4: AER: [12] Timeout

We tried restarting aesmd, didn't help.

We installed SGX driver using ./install_SGX_driver.sh, which resulted in "SGX SDK succesfully installed!".

We do not have /dev/isgx.

@jovanbulck
Copy link
Owner

We do not have /dev/isgx.

Hm that's the problem. This means you don't have a working SGX driver running. Are you even sure your machine supports SGX? See eg https://github.com/ayeks/SGX-hardware

We installed SGX driver using ./install_SGX_driver.sh, which resulted in "SGX SDK succesfully installed!".

This is the output of the install_sdk.sh script. The driver should normally output "SGX driver succesfully installed". But even if it outputs this text, it doesn't mean everything is always okay as there's no error checking in the script.

dmesg | tail resulted in:

There's nothing SGX related here it seems. To see if there's any error messages from the SGX driver or so, try (with reference output on my machine):

$ dmesg | grep sgx
[    3.561339] intel_sgx: loading out-of-tree module taints kernel.
[    3.561355] intel_sgx: module verification failed: signature and/or required key missing - tainting kernel
[    3.561499] sgx: sgx: The launch control MSRs are not writable
[    3.606442] intel_sgx: Intel SGX Driver v2.6.0
[    3.606455] intel_sgx INT0E0C:00: EPC bank 0x70200000-0x75f80000
[    3.607523] intel_sgx: second initialization call skipped
[    3.608106] sgx: sgx: The launch control MSRs are not writable
[    4.500319] sgx: sgx: The launch control MSRs are not writable
[    4.544762] sgx: sgx: The launch control MSRs are not writable
[31238.029520] [sgx-step] listening on /dev/sgx-step

@akkapakasaikiran
Copy link
Author

akkapakasaikiran commented Nov 28, 2020

This is the output of the install_sdk.sh script. The driver should normally output "SGX driver succesfully installed". But even if it outputs this text, it doesn't mean everything is always okay as there's no error checking in the script.

Really sorry, my bad.

We do not have /dev/isgx.

Hm that's the problem. This means you don't have a working SGX driver running. Are you even sure your machine supports SGX? See eg https://github.com/ayeks/SGX-hardware

My device is a Dell XPS 13 9360 (processor: Intel® Core™ i5-8250U) and it does support SGX (ayeks/SGX-hardware#16). The issue was that by default SGX is disabled in the BIOS, so on enabling it there, this problem was solved and /dev/isgx was generated. Thanks! After building and loading /dev/sgx-step, dmesg | tail returned this (is device is already opened an issue?).

$ dmesg | tail
[ 1766.781351] R10: 0000000000000008 R11: 0000000000000246 R12: 00007f6d60bc0d80
[ 1766.781352] R13: 0000000000000004 R14: 00007fff0b9bba70 R15: 00007fff0b9bc050
[ 2243.592640] BUG: Bad rss-counter state mm:000000002a3e11f9 type:MM_SWAPENTS val:-1
[ 2772.959598] [sgx-step] error: Device is already opened
[ 2796.141432] [sgx-step] error: Device is already opened
[ 2961.363567] [sgx-step] error: Device is already opened
[ 3255.909216] rfkill: input handler enabled
[ 3266.662708] rfkill: input handler disabled
[ 4913.610742] [sgx-step] kernel module unloaded
[ 4916.125537] [sgx-step] listening on /dev/sgx-step

But make run then terminated with an Illegal instruction error which turned out to be a fault in rtm_begin() (in foreshadow_round() in libsgxstep/foreshadow.c.). I checked CPUID (as suggested by https://stackoverflow.com/questions/59209381/assembler-xbegin-raise-illegal-instruction) to find that my processor does not support RTM and thus I can't use the TSX support. USE_TSX was by default set to 1 in both app/foreshadow/main.c and libsgxstep/foreshadow.c. When I disabled USE_TSX (in both the files), foreshadow fails ([FAIL] Foreshadow missed 63 bytes out of 64 :/) and just returns -1.

I realize the original issue has been solved, so thank you for that. But is there a workaround for my CPU not supporting RTM, or am I doomed?

@jovanbulck
Copy link
Owner

Hi akkapakasaikiran,

Glad to hear your original issue got solved and you can run SGX enclaves on your system! Some further guidance below:

After building and loading /dev/sgx-step, dmesg | tail returned this (is device is already opened an issue?).

The "Device is already opened" dmesg error is thrown by the sgx-step driver if you try to open the driver several times w/o closing (at the moment only one sgx-step app is supported at a time), but I figure it's no problem as you seem to have figured it out :)

In your dmesg output you do seem to have a kernel panic crash, prob because of the illegal instruction crash and the device is not properly closed etc. Make sure to reboot your machine when you see kernel panics in dmesg. Also make sure to pass the required kernel boot command line arguments as described in the README.

USE_TSX was by default set to 1 in both app/foreshadow/main.c and libsgxstep/foreshadow.c. When I disabled USE_TSX (in both the files), foreshadow fails ([FAIL] Foreshadow missed 63 bytes out of 64 :/) and just returns -1.
I realize the original issue has been solved, so thank you for that. But is there a workaround for my CPU not supporting RTM, or am I doomed?

Yes, the Foreshadow app is unoptimized and uses TSX by default, but it also supports an elementary PoC mode w/o TSX. 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 if your CPU is vulnerable to Foreshadow and has not been patched with recent microcode that flushes L1D cache on enclave entry. See also issue #13 .

Your i5-8250U Kaby Lake R CPU should be vulnerable to Foreshadow, I think. You can disable microcode updates from Linux boot with the dis_ucode_ldr kernel parameter, as described in the README. However, if the microcode has already been patched in the BIOS, you cannot disable or downgrade it anymore. If you want, you can also have a look at our more recent work on LVI (lviattack.eu app/lvi), which revives Foreshadow (among others) even when ucode flushes L1D on enclave entry.

Hope this helps!

@akkapakasaikiran
Copy link
Author

Yes, the Foreshadow app is unoptimized and uses TSX by default, but it also supports an elementary PoC mode w/o TSX. 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 if your CPU is vulnerable to Foreshadow and has not been patched with recent microcode that flushes L1D cache on enclave entry. See also issue #13 .
Your i5-8250U Kaby Lake R CPU should be vulnerable to Foreshadow, I think. You can disable microcode updates from Linux boot with the dis_ucode_ldr kernel parameter, as described in the README. However, if the microcode has already been patched in the BIOS, you cannot disable or downgrade it anymore. If you want, you can also have a look at our more recent work on LVI (lviattack.eu app/lvi), which revives Foreshadow (among others) even when ucode flushes L1D on enclave entry.

I see. I had a look at issue #13. For me, dmesg | grep microcode returns nothing while cat /proc/cpuinfo returns cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds in the bugs line, so I guess this means the CPU is not resistant to Foreshadow (l1tf).

The line I added in /etc/default/grub was GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nox2apic iomem=relaxed no_timer_check nosmep nosmap clearcpuid=514 isolcpus=1 nmi_watchdog=0 dis_ucode_ldr". I guess this disables the booting microcode updates, but how do I check if "the microcode has already been patched in the BIOS"?

I am attaching some runs of make run. The outputs are quite erratic (lots of 0x00s on initial runs but 0xFFs if make run is executed immediately after a previous run, and random reads occasionally) but foreshadow fails consistently. I ran it many times but couldn't find any leakage.

We are doing this in the context of a project to understand Foreshadow and show a demo. We are trying to find devices which support TSX, but could you suggest (relatively easy) alternate approaches to show that Foreshadow works, maybe even other PoCs if you don't mind.

I guess you can close this issue though.

Thanks!

[main.c] verifying and destroying enclave secret..
 ** shadow[ 0]=0xff; enclave[ 0]=0x49 ** shadow[ 1]=0x00; enclave[ 1]=0xb2
 ** shadow[ 2]=0x00; enclave[ 2]=0x94 ** shadow[ 3]=0xff; enclave[ 3]=0x87
 ** shadow[ 4]=0xff; enclave[ 4]=0xdc ** shadow[ 5]=0x00; enclave[ 5]=0x9e
 ** shadow[ 6]=0x00; enclave[ 6]=0x78 ** shadow[ 7]=0x00; enclave[ 7]=0x55
 ** shadow[ 8]=0x00; enclave[ 8]=0xfd ** shadow[ 9]=0x00; enclave[ 9]=0x89
 ** shadow[10]=0x00; enclave[10]=0x8d ** shadow[11]=0x00; enclave[11]=0x7d
 ** shadow[12]=0x00; enclave[12]=0xcc ** shadow[13]=0x00; enclave[13]=0xe3
 ** shadow[14]=0x00; enclave[14]=0x22 ** shadow[15]=0x00; enclave[15]=0x2d
 ** shadow[16]=0x00; enclave[16]=0x69 ** shadow[17]=0x00; enclave[17]=0x18
 ** shadow[18]=0x00; enclave[18]=0xa1 ** shadow[19]=0x00; enclave[19]=0x79
 ** shadow[20]=0x00; enclave[20]=0x82 ** shadow[21]=0x00; enclave[21]=0xb8
 ** shadow[22]=0x00; enclave[22]=0xc4 ** shadow[23]=0x00; enclave[23]=0x37
 ** shadow[24]=0x00; enclave[24]=0xfb ** shadow[25]=0x00; enclave[25]=0x77
 ** shadow[26]=0x00; enclave[26]=0x26 ** shadow[27]=0x00; enclave[27]=0xea
 ** shadow[28]=0x00; enclave[28]=0x46 ** shadow[29]=0x00; enclave[29]=0xb0
 ** shadow[30]=0x00; enclave[30]=0x18 ** shadow[31]=0x00; enclave[31]=0xa9
 ** shadow[32]=0x00; enclave[32]=0x6d ** shadow[33]=0x00; enclave[33]=0x81
 ** shadow[34]=0xff; enclave[34]=0xaa ** shadow[35]=0xff; enclave[35]=0x20
 ** shadow[36]=0xff; enclave[36]=0x44 ** shadow[37]=0x00; enclave[37]=0x6f
 ** shadow[38]=0x00; enclave[38]=0x4d ** shadow[39]=0x00; enclave[39]=0x68
 ** shadow[40]=0x00; enclave[40]=0xe4 ** shadow[41]=0x00; enclave[41]=0xa9
 ** shadow[42]=0x00; enclave[42]=0xd6 ** shadow[43]=0x00; enclave[43]=0xc5
 ** shadow[44]=0x00; enclave[44]=0x5f ** shadow[45]=0x00; enclave[45]=0xf2
 ** shadow[46]=0x00; enclave[46]=0x4f ** shadow[47]=0xff; enclave[47]=0x52
 ** shadow[48]=0xff; enclave[48]=0x61 ** shadow[49]=0xff; enclave[49]=0x6a
 ** shadow[50]=0xff; enclave[50]=0x25 ** shadow[51]=0x00; enclave[51]=0xa5
 ** shadow[52]=0x00; enclave[52]=0x6e ** shadow[53]=0x00; enclave[53]=0xfd
 ** shadow[54]=0xff; enclave[54]=0x1a ** shadow[55]=0x00; enclave[55]=0x9e
    shadow[56]=0x00; enclave[56]=0x00 ** shadow[57]=0x00; enclave[57]=0x3f
 ** shadow[58]=0x00; enclave[58]=0x30 ** shadow[59]=0x00; enclave[59]=0xed
 ** shadow[60]=0x00; enclave[60]=0x88 ** shadow[61]=0x00; enclave[61]=0x47
 ** shadow[62]=0x00; enclave[62]=0x52 ** shadow[63]=0x00; enclave[63]=0xd7
[foreshadow.c] [FAIL] Foreshadow missed 63 bytes out of 64 :/

[main.c] verifying and destroying enclave secret..
 ** shadow[ 0]=0xff; enclave[ 0]=0xa1 ** shadow[ 1]=0xff; enclave[ 1]=0xee
 ** shadow[ 2]=0xff; enclave[ 2]=0xea ** shadow[ 3]=0xff; enclave[ 3]=0xc0
 ** shadow[ 4]=0xff; enclave[ 4]=0x82 ** shadow[ 5]=0x1f; enclave[ 5]=0x74
 ** shadow[ 6]=0x00; enclave[ 6]=0x76 ** shadow[ 7]=0x44; enclave[ 7]=0xe1
 ** shadow[ 8]=0x00; enclave[ 8]=0xc4 ** shadow[ 9]=0x11; enclave[ 9]=0x96
 ** shadow[10]=0x00; enclave[10]=0xd0 ** shadow[11]=0x41; enclave[11]=0x79
 ** shadow[12]=0x93; enclave[12]=0x72 ** shadow[13]=0x05; enclave[13]=0x0f
 ** shadow[14]=0x1c; enclave[14]=0xa8 ** shadow[15]=0x00; enclave[15]=0xee
 ** shadow[16]=0x06; enclave[16]=0x27 ** shadow[17]=0x7b; enclave[17]=0xb0
 ** shadow[18]=0x00; enclave[18]=0x8b ** shadow[19]=0x3f; enclave[19]=0x74
 ** shadow[20]=0xe3; enclave[20]=0x64 ** shadow[21]=0xff; enclave[21]=0x2b
 ** shadow[22]=0x48; enclave[22]=0x90 ** shadow[23]=0x55; enclave[23]=0x1c
 ** shadow[24]=0x00; enclave[24]=0x27 ** shadow[25]=0xa2; enclave[25]=0x84
 ** shadow[26]=0xbb; enclave[26]=0xcf ** shadow[27]=0xff; enclave[27]=0xae
 ** shadow[28]=0xe2; enclave[28]=0x98 ** shadow[29]=0x41; enclave[29]=0x39
 ** shadow[30]=0xe2; enclave[30]=0x2c ** shadow[31]=0x23; enclave[31]=0x4e
 ** shadow[32]=0x16; enclave[32]=0x74 ** shadow[33]=0xdd; enclave[33]=0xf3
 ** shadow[34]=0x27; enclave[34]=0x82 ** shadow[35]=0x41; enclave[35]=0x43
 ** shadow[36]=0x22; enclave[36]=0x88 ** shadow[37]=0xdb; enclave[37]=0x42
 ** shadow[38]=0xff; enclave[38]=0x29 ** shadow[39]=0x2a; enclave[39]=0x6f
 ** shadow[40]=0xff; enclave[40]=0xb2 ** shadow[41]=0xff; enclave[41]=0xe4
 ** shadow[42]=0x39; enclave[42]=0xf8 ** shadow[43]=0x43; enclave[43]=0x56
 ** shadow[44]=0xca; enclave[44]=0x74 ** shadow[45]=0xa4; enclave[45]=0x1f
 ** shadow[46]=0x3f; enclave[46]=0x1a ** shadow[47]=0xff; enclave[47]=0x43
 ** shadow[48]=0x44; enclave[48]=0x8d ** shadow[49]=0x9e; enclave[49]=0xdd
 ** shadow[50]=0x14; enclave[50]=0xc5 ** shadow[51]=0x99; enclave[51]=0x18
 ** shadow[52]=0x8f; enclave[52]=0x69 ** shadow[53]=0x1c; enclave[53]=0xca
 ** shadow[54]=0xd5; enclave[54]=0x1b    shadow[55]=0xff; enclave[55]=0xff
 ** shadow[56]=0x27; enclave[56]=0x44 ** shadow[57]=0x23; enclave[57]=0xb3
 ** shadow[58]=0x0e; enclave[58]=0x71 ** shadow[59]=0x73; enclave[59]=0x5f
 ** shadow[60]=0x5a; enclave[60]=0x93 ** shadow[61]=0x40; enclave[61]=0x89
 ** shadow[62]=0xd5; enclave[62]=0x97 ** shadow[63]=0x40; enclave[63]=0x88
[foreshadow.c] [FAIL] Foreshadow missed 63 bytes out of 64 :/

[main.c] verifying and destroying enclave secret..
 ** shadow[ 0]=0xff; enclave[ 0]=0x28 ** shadow[ 1]=0xff; enclave[ 1]=0x2b
 ** shadow[ 2]=0xff; enclave[ 2]=0x85 ** shadow[ 3]=0xff; enclave[ 3]=0xfd
 ** shadow[ 4]=0xff; enclave[ 4]=0xb2 ** shadow[ 5]=0xff; enclave[ 5]=0x9d
 ** shadow[ 6]=0xff; enclave[ 6]=0x56 ** shadow[ 7]=0xff; enclave[ 7]=0x74
 ** shadow[ 8]=0xff; enclave[ 8]=0xc0 ** shadow[ 9]=0xff; enclave[ 9]=0x3e
 ** shadow[10]=0xff; enclave[10]=0x23 ** shadow[11]=0xff; enclave[11]=0x95
 ** shadow[12]=0xff; enclave[12]=0x7f ** shadow[13]=0x00; enclave[13]=0x19
 ** shadow[14]=0xff; enclave[14]=0x27 ** shadow[15]=0xff; enclave[15]=0x40
 ** shadow[16]=0xff; enclave[16]=0xeb ** shadow[17]=0xff; enclave[17]=0x3b
 ** shadow[18]=0xff; enclave[18]=0x18 ** shadow[19]=0xff; enclave[19]=0x3e
 ** shadow[20]=0xff; enclave[20]=0x12 ** shadow[21]=0xff; enclave[21]=0x95
 ** shadow[22]=0xff; enclave[22]=0xb9 ** shadow[23]=0xff; enclave[23]=0xd1
 ** shadow[24]=0xff; enclave[24]=0x76 ** shadow[25]=0xff; enclave[25]=0x0d
 ** shadow[26]=0xff; enclave[26]=0x23 ** shadow[27]=0xff; enclave[27]=0xa0
 ** shadow[28]=0xff; enclave[28]=0x6c ** shadow[29]=0xff; enclave[29]=0x78
 ** shadow[30]=0xff; enclave[30]=0x75 ** shadow[31]=0xff; enclave[31]=0x2f
 ** shadow[32]=0xff; enclave[32]=0x23 ** shadow[33]=0xff; enclave[33]=0xc7
 ** shadow[34]=0xff; enclave[34]=0x88 ** shadow[35]=0xff; enclave[35]=0x24
 ** shadow[36]=0xff; enclave[36]=0x24 ** shadow[37]=0xff; enclave[37]=0xc0
 ** shadow[38]=0xff; enclave[38]=0x6a ** shadow[39]=0xff; enclave[39]=0x64
 ** shadow[40]=0xff; enclave[40]=0x28 ** shadow[41]=0xff; enclave[41]=0xd3
 ** shadow[42]=0xff; enclave[42]=0x10 ** shadow[43]=0xff; enclave[43]=0x27
 ** shadow[44]=0xff; enclave[44]=0x93    shadow[45]=0xff; enclave[45]=0xff
 ** shadow[46]=0xff; enclave[46]=0x55 ** shadow[47]=0xff; enclave[47]=0x5e
 ** shadow[48]=0xff; enclave[48]=0xc6 ** shadow[49]=0xff; enclave[49]=0x2b
 ** shadow[50]=0xff; enclave[50]=0xa6 ** shadow[51]=0xff; enclave[51]=0x4c
 ** shadow[52]=0xff; enclave[52]=0x61 ** shadow[53]=0xff; enclave[53]=0x79
 ** shadow[54]=0xff; enclave[54]=0xeb ** shadow[55]=0xff; enclave[55]=0xb6
 ** shadow[56]=0xff; enclave[56]=0x02 ** shadow[57]=0xff; enclave[57]=0xf3
 ** shadow[58]=0xff; enclave[58]=0x08 ** shadow[59]=0xff; enclave[59]=0x45
 ** shadow[60]=0xff; enclave[60]=0x15 ** shadow[61]=0xff; enclave[61]=0x77
 ** shadow[62]=0xff; enclave[62]=0x88 ** shadow[63]=0xff; enclave[63]=0x3f
[foreshadow.c] [FAIL] Foreshadow missed 63 bytes out of 64 :/

@jovanbulck
Copy link
Owner

I see. I had a look at issue #13. For me, dmesg | grep microcode returns nothing while cat /proc/cpuinfo returns cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds in the bugs line, so I guess this means the CPU is not resistant to Foreshadow (l1tf).

Yes your CPU is indeed vulnerable to Foreshadow.

I guess this disables the booting microcode updates, but how do I check if "the microcode has already been patched in the BIOS"?

Yes, boot-time ucode updates are disabled this way. You can check the current ucode level of the CPU by means of cat /proc/cpuinfo | grep microcode.

I am attaching some runs of make run. The outputs are quite erratic (lots of 0x00s on initial runs but 0xFFs if make run is executed immediately after a previous run, and random reads occasionally) but foreshadow fails consistently. I ran it many times but couldn't find any leakage.

Yes, this seems to indicate your microcode is flushing L1D on enclave exit so there's no leakage. Regarding the noise, erratice outputs, this Foreshadow app is a bit hacky and esp the Flush+Reload channel is not optimized, which can lead to errors in the output (esp when using the signal handler non-TSX approach).

We are doing this in the context of a project to understand Foreshadow and show a demo. We are trying to find devices which support TSX, but could you suggest (relatively easy) alternate approaches to show that Foreshadow works, maybe even other PoCs if you don't mind.

Cool project! TSX can generally help for exception-based transient-execution attacks like Foreshadow, but it's not necessary and will not fix your ucode problem here. My advice: first get Foreshadow to work outside of SGX, then the microcode will not flush L1D cache and it should work. This should be simple: e.g., replace the enclave ecall with a normal function call just as a proof-of-concept.

Alternatively, for a bit cleaner and non-SGX Foreshadow proof-of-concept, have a look at our overview paper and website (https://transient.fail/). The corresponding Foreshadow (aka "Meltdown-P") PoC is here:

https://github.com/IAIK/transientfail/tree/master/pocs/meltdown/P

I guess you can close this issue though.

Okay, closing as this is not an issue in SGX-Step, but feel free to follow-up or let know how it goes ^^

@akkapakasaikiran
Copy link
Author

Cool project! TSX can generally help for exception-based transient-execution attacks like Foreshadow, but it's not necessary and will not fix your ucode problem here. My advice: first get Foreshadow to work outside of SGX, then the microcode will not flush L1D cache and it should work. This should be simple: e.g., replace the enclave ecall with a normal function call just as a proof-of-concept.

Alternatively, for a bit cleaner and non-SGX Foreshadow proof-of-concept, have a look at our overview paper and website (https://transient.fail/).

Thanks a lot!
I cloned into https://github.com/IAIK/transientfail, as a non-SGX PoC will suffice for now. However, I ran into the following error on executing poc_x86 of meltdown-P. I assumed an upper-level make (of the poc folder) would load the kernel module (I guess it is the module folder in poc/libpte). So how to resolve this?

[-]Error: Could not open PTEditor device: /dev/pteditor
Could not initialize ptedit (did you load the kernel module?)

@jovanbulck
Copy link
Owner

hm, in pocs/libpte/module try make; sudo insmod pteditor.ko I think

@akkapakasaikiran
Copy link
Author

akkapakasaikiran commented Dec 1, 2020

Hi, jovanbulck.
Sorry got tied up in some other work.

hm, in pocs/libpte/module try make; sudo insmod pteditor.ko I think

That worked!

Now when I did ./poc_x86 I got no output.

[*] Flush+Reload Threshold: 262
Output legend:
  'S'.....Works
Meltdown-P done!

I tried printing out end - start in the flush_reload function in cache.c and analyzed the values. The minimum time diffs were 320-350 (much more than the detected CACHE_MISS) whereas the mode of the data is around 420. I tried stress -i 1 -d 1 and taskset 0x2 ./poc_x86 as suggested by the README. On setting CACHE_MISS above 360 I'm getting random output.

It feels like flush-and-reload isn't working only. What may I be doing wrong? Should I open an issue in transientfail (rather than commenting here)?

Thanks.

@jovanbulck
Copy link
Owner

HI akkapakasaikiran,

It feels like flush-and-reload isn't working only. What may I be doing wrong? Should I open an issue in transientfail (rather than commenting here)?

Yes, best to open an issue in the transientfail repo for issues in that project.

Meanwhile I quickly hacked together a PoC to demonstrate Foreshadow w/o entering the enclave, as I suggested earlier:

My advice: first get Foreshadow to work outside of SGX, then the microcode will not flush L1D cache and it should work. This should be simple: e.g., replace the enclave ecall with a normal function call just as a proof-of-concept.

You can see it here (set SIM_ENCLAVE to 1):

56ec2ad

As I said, the F+R implementation in libsgxstep is unoptimized and you may get some noise, but after a few runs you should clearly see FS working ^^

Hope it helps! Let me know how it turns out for you.

@akkapakasaikiran
Copy link
Author

jovanbulck,

It works like a charm! [foreshadow.c] [FAIL] Foreshadow missed 7 bytes out of 64 :/ is not a failure for us, and simulating the enclave should be enough for our demo.

I can't thank you enough. Really really grateful for all the help you've provided over the past few days. To think you went ahead and added a commit for our issue is heartwarming.

Thanks a lot!
Saikiran

@jovanbulck
Copy link
Owner

Glad to hear it worked out! Happy hacking :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants