EAUG and read vs write behavior
by Axlexic
Hi,
I’m finding some strange behavior from SGXv2 driver between read and write of an unmapped page inside the enclave. I was under the assumption that if a page is within the ELRANGE, and the SGXv2 enclave tried to dereference a pointer, the kernel will map that page using EAUG to the enclave, and generate a SIGBUS so that the exception handler can accept it.
This seems to work if the first operation is a write to an unmapped pointer, but if the first operation is a read, the kernel generates a SIGSEGV with the EXINFO.ERRCD.SGX bit set to 1 inside the exception handler. This I assume means that the kernel didn’t map the page even though it was within the enclave range.
Furthermore, if I execute EMODPE inside the exception handler, the process hangs indefinitely without returning any error code or signal.
So, my question is:
What is the rationale for only returning SIGBUS in case of write but SIGSEGV in case of read. I have read this paper from Intel http://caslab.csl.yale.edu/workshops/hasp2016/HASP16-17.pdf <http://caslab.csl.yale.edu/workshops/hasp2016/HASP16-17.pdf> and I’m not convinced that the heuristic described on page 6 to only implicitly map pages when the first operation is write is a general enough heuristic for a general purpose kernel driver. If the page is within enclave range, the kernel should just map it and let the enclave deal with the consequences. (Note that the enclave doesn’t trust the kernel to do the right thing, so trying to add all this heuristic makes things more complicated.)
For example, if one wants to build an MMAP(MAP_SHARED) like abstraction inside the enclave, where pages are copied from outside the enclave on demand (i.e., when the user dereference a pointer inside the enclave, the exception handler copies one page from outside the enclave and sets the page permission appropriately after copying the page) cannot be supported with the current driver.
I’m not sure what is the excepted behavior of EMODPE if the page is not mapped. At the very least the kernel should generate an invalid instruction signal, but it currently just hangs.
I’m using Intel® NUC Kit NUC7CJYH for testing.
Thanks
Yogesh
4 years, 5 months