I started to look into this old issue with mm subsystem and SGX, i.e.
can we make SGX VMA's to merge together?
This demonstrates the problem pretty well:
https://lore.kernel.org/linux-sgx/884c7ea454cf2eb0ba2e95f7c25bd42018824f97.camel@xxxxxxxxxx/
It was result of brk() syscall being applied a few times.
Briging some context here. This can be fixed in the run-time by book
keeping the ranges and doing unmapping/mapping. I guess this goes
beyond what mm should support?
I thought to plain check this as it has been two years since my last
query on topic (if we could improve either the driver or mm somehow).
In the past I've substituted kernel's mm merge code with user space
replacement:
https://github.com/enarx/mmledger/blob/main/src/lib.rs
It's essentially a reimplementation of al stuff that goes into
mm/mmap.c's vma_merge(). I cannot recall anymore whether merges
which map over existing ranges were working correctly, i.e. was
the issue only concerning adjacent VMA's.
What I'm looking here is that can we make some cosntraints that
if satisfied by the pfnmap code, it could leverage the code from
vma_merge(). Perhaps by making explicit call to vma_merge()?
I get that implicit use moves too much responsibility to the mm
subsystem.
Hi Jarkko,
Just want to understand more on the background:
Are you seeing any real problem due to needing a lot of mmap()s to the
same enclave, or it is just a problem that doesn't look nice and you
want to resolve?
I mean, this problem doesn't seem to be SGX-specific but a common one
for VMAs with VM_PFNMAP (any bit in VM_SPECIAL), e.g., from random
device drivers with mmap() support. We will need a good justification
if we want to make any core-mm change, if any, for this.
It requires essentially replicating core mm in user space.
It's a manageable problem but feels silly since logic in merging
is mostly 1:1. It's not a problem for me personally as I'm not
making any money from SGX (more so to Intel).
I.e. in the case when you want do a syscall shim. You fix it up by
maintaining reflected version of the VMA database in the user space
and remapping everything based on that for every possible mm-call.
I've implemented such feature in the past for Enarx so it is entirely
possible.
Just want to understand the problem/use case better:
I _think_ I got what the "syscall shim" is. But can you elaborate why
is this "syscall shim" related to the "kernel unable to merge contiguous
VMAs for the same enclave"? Assuming the kernel can actually merge
enclave VMAs, how does it help on the "syscall shim"?
