On Tue, Apr 16, 2024 at 4:59 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > * jeffxu@xxxxxxxxxxxx <jeffxu@xxxxxxxxxxxx> [240415 12:35]: > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > > > The new mseal() is an syscall on 64 bit CPU, and with > > following signature: > > > > int mseal(void addr, size_t len, unsigned long flags) > > addr/len: memory range. > > flags: reserved. [...] > No per-vma change is checked prior to entering a per-vma modification > loop today. This means that mseal() differs in behaviour in "up-front > failure" vs "partial change failure" that exists in every other > function. > > I'm not saying it's wrong or that it's right - I'm just wondering what > the direction is here. Either we should do as much up-front as > possible or keep with tradition and have (partial) success where > possible. FWIW, in the current version, I think ENOMEM can happen both in the up-front check (for calling the syscall on unmapped ranges) as well as in the later loop (for VMA splitting failure). I think no matter what we do, a process that gets an error other than ENOSYS from mseal() will probably not get much actionable information from the return value... no matter whether sealing worked partly or not at all, the process will have the same choice between either exiting (if it treats sealing failure as a fatal error for security reasons) or continuing as if the sealing had worked.
