Confused-deputy attack on sm_isr.s

[jovanbulck]

Should not use untrusted stack to do reti to interrrupted context. should probably move that to a untrusted_isr_reti stub outside the enclave or so:

 47     ; Switch the stack.
 48     mov r1, &__sm_sp
 49     mov &__sm_irq_sp, r1
 50     reti

[fritzalder]

Also, the &__sm_sp should not be blindly overwritten as it is used as a marker for OCALLs now.

[fritzalder]

I opened #39 to address the __sm_sp issue.

I also did not address the above issue in the PR yet. In my opinion, the return address on the stack can be trusted as it was placed by hardware. So one solution can also be to store the return address somewhere inside the enclave before branching to the ISR handler (that may perform an OCALL leading to the value not being trustworthy anymore).

[jovanbulck]

I opened #39 to address the __sm_sp issue.

merged, thanks!

I also did not address the above issue in the PR yet. In my opinion, the return address on the stack can be trusted as it was placed by hardware. So one solution can also be to store the return address somewhere inside the enclave before branching to the ISR handler (that may perform an OCALL leading to the value not being trustworthy anymore).

yes but this is a slippery slope, the value that's pushed to untrusted memory, where it may be modified by OCALLs or interrupts as you said, but also by eg untrusted DMA accesses.

So the value should be inherently untrusted. We can of course still load it inside the enclave and then properly check it lies outside, as we do with the normal ecall return address, but then we can also not use reti cause there might be a time-of-check-time-of-use

All by all the cleanest solution IMO still is to do the reti in an untrusted trampoline stub at a fixed address outside the enclave