This paper contains a remarkable amount of irrelevant background.
If you actually want to read this thing, read the very beginning and then skip to at least page 57.
There are some interesting bits that are relevant to OS authors. For example:
At first glance, it may seem elegant to have
EENTER restore the contents of the XCR0, FS, and GS registers in the current SSA, and have EXIT restore them from the current SSA. However, this approach would break the Intel architecture’s guarantees that only system soft-ware can modify XCR0, and application software can only load segment registers using selectors that index
into the GDT or LDT set up by system software (2.7). Specifically, a malicious application could modify these
privileged registers by creating an enclave that writes the
desired values to the current SSA locations backing up
the registers, and then executes EEXIT.
If that's correct (I haven't double-checked thoroughly, but it seems like it's wrong), then it's a problem. But I think the paper is just wrong.
I'd be more worried about RFLAGS in the SSA. Its exact usage is poorly documented, but some bits of RFLAGS are privileged (IF and IOPL).
I'm terrible at writing. I am trying to say that SGX cannot restore things from the SSA, and it has to use some protected area. To the best of my knowledge, they're using the non-architectural area of the TCS, which is protected from any sort of write.
If you actually want to read this thing, read the very beginning and then skip to at least page 57.
There are some interesting bits that are relevant to OS authors. For example:
At first glance, it may seem elegant to have EENTER restore the contents of the XCR0, FS, and GS registers in the current SSA, and have EXIT restore them from the current SSA. However, this approach would break the Intel architecture’s guarantees that only system soft-ware can modify XCR0, and application software can only load segment registers using selectors that index into the GDT or LDT set up by system software (2.7). Specifically, a malicious application could modify these privileged registers by creating an enclave that writes the desired values to the current SSA locations backing up the registers, and then executes EEXIT.
If that's correct (I haven't double-checked thoroughly, but it seems like it's wrong), then it's a problem. But I think the paper is just wrong.
I'd be more worried about RFLAGS in the SSA. Its exact usage is poorly documented, but some bits of RFLAGS are privileged (IF and IOPL).