qn Thu Sep 26, 2024 at 3:33 AM EEST, Jarkko Sakkinen wrote: > On Thu Sep 26, 2024 at 3:07 AM EEST, Kai Huang wrote: > > > > > > On 23/09/2024 7:48 pm, Jarkko Sakkinen wrote: > > > On Sun Sep 22, 2024 at 7:57 PM EEST, Jarkko Sakkinen wrote: > > >>> On Sun Sep 22, 2024 at 7:27 PM EEST, Jarkko Sakkinen wrote: > > >>>> Hi > > >>>> > > >>>> 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. BR, Jarkko
