> Without that practical reason, I think the only two sane sealing operations
> are:
>
> - SEAL_MUNMAP: "don't allow this mapping address to go away"
>
>IOW no unmap, no shrinking, no moving mremap
>
> - SEAL_MPROTECT: "don't allow any mapping permission changes"
>
> Again, that permission c
Hi Linus,
On Tue, Oct 17, 2023 at 10:43 AM Linus Torvalds
wrote:
>
> On Tue, 17 Oct 2023 at 10:04, Linus Torvalds
> wrote:
> >
> > Honestly, there is only two kinds of sealing that makes sense:
> >
> > - you cannot change the permissions of some area
> >
> > - you cannot unmap an area
>
> Actu
On Tue, 17 Oct 2023 at 10:04, Linus Torvalds
wrote:
>
> Honestly, there is only two kinds of sealing that makes sense:
>
> - you cannot change the permissions of some area
>
> - you cannot unmap an area
Actually, I guess at least theoretically, there could be three different things:
- you can
On Tue, 17 Oct 2023 at 02:08, wrote:
>
> Note: Of all the call paths that goes into do_mmap(),
> ksys_mmap_pgoff() is the only place where
> checkSeals = MM_SEAL_MMAP. The rest has checkSeals = 0.
Again, this is all completely nonsensical.
First off, since seals only exist on existing vma's, the
From: Jeff Xu
mmap(2) can change a protection of existing VMAs.
Sealing will prevent unintended mmap(2) call.
What this patch does:
When a mmap(2) is invoked, if one of its VMAs has MM_SEAL_MMAP set
from previous mseal(2) call, the mmap(2) will fail, without any
VMAs modified.
The patch is base
