Closed bainianbuhe closed 3 weeks ago
After checking the assembly code, I guess in the last SIGTRAP, the process has left the Enclave using enclu, so it's normal that the aep_cb_func is not triggered
Hi bainianbuhe,
Not sure what's exactly your setup here: are you trying to get app/bench
working with SIGTRAP instead of timer interrupts? Please note that SIGTRAP support was added to app/memcp
to ease rapid prototyping only, i.e., it uses x86 #DB traps which will not work on production enclaves. The SIGTRAP is only intended to more easily test your attack logic, which should then also work with "proper" timer-based single-stepping as a drop-in replacement.
Atm the app/bench is not configured to work with SIGTRAP, so not sure what exactly you added and what behavior you expect. It's true that the last step after enclu[EEXIT] will be out of the enclave, as you observed above.
Let me know if this can be closed?
Hi bainianbuhe,
Not sure what's exactly your setup here: are you trying to get
app/bench
working with SIGTRAP instead of timer interrupts? Please note that SIGTRAP support was added toapp/memcp
to ease rapid prototyping only, i.e., it uses x86 #DB traps which will not work on production enclaves. The SIGTRAP is only intended to more easily test your attack logic, which should then also work with "proper" timer-based single-stepping as a drop-in replacement.Atm the app/bench is not configured to work with SIGTRAP, so not sure what exactly you added and what behavior you expect. It's true that the last step after enclu[EEXIT] will be out of the enclave, as you observed above.
Let me know if this can be closed?
Thank you for your reply! It seems I misunderstood how the bench works. Actually if I simply try the NUM=200 STRLEN=1 make parse command under the unmodified bench folder the program will be terminated by SIGTRAP, which leads me to think I should catch and handle the SIGTRAP signal. So what else should I do to make the bench run in the right way? Is SIGTRAP expected to appear in the unmodified bench program?
hm, normally app/bench should not raise SIGTRAP
I reviewed the code and it seems like you indeed ran into a bug where the aep_trampoline.S
assembly code incorrectly reads out the sgx_step_do_trap
variable and always enables the traps:
of course misses a mov
instruction to actually read out the memory location -- my bad! :facepalm:
Thank you for reporting the bug, I will fix this shortly on the master
branch
@bainianbuhe please pull the latest master with the commit above and let me know if this fixes it for you (on a clean /app/bench
without modifications)? Feel free to re-open this issues if further discussion is needed!
These are some results of running bench with NUM=100 STRLEN=1 make parse, I copied and pasted some codes from memcmp to handle SIGTRAP to make it not terminated by SIGTRAP, not sure if that's the right way.
Although the result is approximately right,(11+1)*100=1200, I notice that the value of RIP in ctx is not what I expected in the last SIGTRAP handling process(I think it should be the address of AEP, 0x5557c1c28551 in this case), and after the handling process, aep_cb_func is not triggered like the former SIGTRAPS
By the way,even in the former SIGTRAPS,the context RIP is 1 greater than AEP, however, in the first and only SIGSEGV, the RIP is just equal to AEP,not sure if that's normal.
not sure why, thanks in advance
register_signal_handler(SIGSEGV);
case SIGTRAP: /* ensure RFLAGS.TF is clear to disable debug single-stepping */ ucontext_t *uc = (ucontext_t *)ctx; uc->uc_mcontext.gregs[REG_EFL] &= ~0x100;