On 2017-03-22 10:36, Sean Christopherson wrote:
On Tue, 2017-03-21 at 22:26 -0700, Jethro Beekman wrote:
> In order to provide the ability to debug enclaves independently of their
> programming model, while supporting live attach (meaning the debugger
> might not have seen enclave creation), a debugger needs to following
> capabilities for a debugged process:
> 1) Identify enclaves
> a) Given a page, identify it as an enclave page
> b) Given an enclave page, find that enclave's base address
> c) Given a particular enclave, find the TCSes
> d) Given a particular enclave, get the attributes/miscselect
> 2) Read/write enclave memory
> 3) Find debugging symbols for enclaves
> I think (1)(a) and (1)(b) can be done using /proc/[pid]/maps, but I'd
> like confirmation. I think the following is true: If a page is in a
> memory range that is listed as mapped from the sgx device, it is an
> enclave page.
This will generally hold true for applications built with the Intel SDK, but
there is nothing that prevents an application from holding onto memory mapped to
/dev/sgx without an associated enclave. Even with the Intel SDK there will be
(very small) windows where this isn't true, e.g. between mmap and ioctl to
create the enclave.
There might even be legitimate use cases where an application maps more memory
to /dev/sgx than it currently needs, e.g. an application that launches multiple
instances of an enclave on-demand might keep multiple unused mappings available.
> From a memory range that is listed as mapped from the sgx
> device, you can compute the enclave base address as (start-offset).
(1)(b) could be especially problematic for applications that create multiple
enclaves, e.g. if several enclaves are contiguous in virtual memory.
Good points. The mmap interface, while clearly being the best interface
for creating memory mappings in userspace, is not a 100% fit for SGX.
It's not similar to other devices where there is a fixed range that a
process can map into as they see fit. Normally if you have one or more
fds to a device and map the same offset multiple times at different
addresses, you're viewing the same physical memory multiple times. This
is not the case with SGX, and it also wouldn't make sense for SGX.
It would be good to think about what the best way is to deal with this
dichotomy. The current situation is a little weird. On ECREATE, the vma
needs to be at the right start address and it needs to have the right
size. The VMA offset is ignored. Later, you can split the VMA through
e.g. calls of mprotect. This will adjust start and end addresses and
offsets logically. I suppose it's technically possible with the current
setup to map a single range and map multiple enclaves in it, it requires
a precarious sequence of mmap and mprotect calls to pull it off.
I think the easiest way to "fix" this is to add another restriction to
ECREATE: the VMA offset must be 0. Combined with the other restrictions
this will mean it's easy to identify individual enclaves in the memory
map. Alternatively we could put almost no restrictions on VMA addresses
and offsets and export all the relevant information through the proc
file. The best abstraction in the sense that it best maps what's going
on in terms of enclaves is to have a different "device" per enclave.
This way it's clear what userspace means when it maps memory at an
offset, etc. There's still the issue of the fixed linear addressing.
Another question is what needs to happen with
mmap/munmap/mremap/mprotect calls that would normally lead to VMAs being
consolidated, as well as how to handle all this with SGX2.
Jethro Beekman | Fortanix