Re: VMA merging updateds?

["Jarkko Sakkinen" <jarkko.sakkinen@iki.fi>]

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@kernel.org/
> > >>>>
> > >>>> 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