On Fri, Aug 9, 2024 at 5:06 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * Pedro Falcato <pedro.falcato@xxxxxxxxx> [240807 17:13]: > > Delegate all can_modify checks to the proper places. Unmap checks are > > done in do_unmap (et al). > > > > This patch allows for mremap partial failure in certain cases (for > > instance, when destination VMAs aren't sealed, but the source VMA is). > > It shouldn't be too troublesome, as you'd need to go out of your way to > > do illegal operations on a VMA. > > As mseal() is supposed to be a security thing, is the illegal operation > not a concern? My 3 cents (note: I'm not a security guy): - Linux m*() operations have been allowed to partially fail for ages. POSIX only disallows this in the munmap case (which is why we need all that detached VMA logic), but not in any other case. We have a lot of other failure points in these syscalls, and would require extensive refactoring to patch this up (very likely with an inevitable performance regression, as we saw in this case). - Despite allowing for partial failure, this patch set always keeps the sealed VMAs untouched (so that invariant isn't broken). The munmap semantics remain untouched (and POSIXly correct) due to the detached VMA logic. - I personally have not heard of a single attack making use of this, and the performance hit is very measurable and exists _for every user_, despite mseal being a very niche feature (I cannot find a single user of mseal upstream, both in debian code search, github, chromium, v8, glibc, and what have you). I remember SIGKILL on a bad operation being a possibility during the mseal patch set talks, and if people are really scared of this partial stuff, I would guess that's still a possibility. There are no users after all... -- Pedro
