| Message ID | 20240122152905.2220849-1-jeffxu@chromium.org |
|---|---|
| Headers | show |
| Series | Introduce mseal() | expand |
* Theo de Raadt <deraadt@openbsd.org> [240122 17:35]: > Jeff Xu <jeffxu@chromium.org> wrote: > > > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <deraadt@openbsd.org> wrote: > > > > > > Regarding these pieces > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > the map sealed since creation. > > > > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my > > > research I found basically zero circumstances when you userland does > > > that. The most common circumstance is you create a RW mapping, fill it, > > > and then change to a more restrictve mapping, and lock it. > > > > > > There are a few regions in the addressspace that can be locked while RW. > > > For instance, the stack. But the kernel does that, not userland. I > > > found regions where the kernel wants to do this to the address space, > > > but there is no need to export useless functionality to userland. > > > > > I have a feeling that most apps that need to use mmap() in their code > > are likely using RW mappings. Adding sealing to mmap() could stop > > those mappings from being executable. Of course, those apps would > > need to change their code. We can't do it for them. > > I don't have a feeling about it. > > I spent a year engineering a complete system which exercises the maximum > amount of memory you can lock. > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > drafts, and saw it turning into a dangerous anti-pattern. > > > Also, I believe adding this to mmap() has no downsides, only > > performance gain, as Pedro Falcato pointed out in [1]. > > > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/ > > Are you joking? You don't have any code doing that today. More feelings? The 'no downside" is to combining two calls together; mmap() & mseal(), at least that is how I read the linked discussion. The common case (since there are no users today) of just calling mmap()/munmap() will have the downside. There will be a performance impact once you have can_modify_mm() doing more than just returning true. Certainly, the impact will be larger in munmap where multiple VMAs may need to be checked (assuming that's the plan?). This will require a new and earlier walk of the vma tree while holding the mmap_lock. Since you are checking (potentially multiple) VMAs for something, I don't think there is a way around holding the lock. I'm not saying the cost will be large, but it will be a positive non-zero number. Thanks, Liam
* jeffxu@chromium.org <jeffxu@chromium.org> [240122 10:29]: > From: Jeff Xu <jeffxu@chromium.org> > > 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. > > mseal() blocks following operations for the given memory range. > > 1> Unmapping, moving to another location, and shrinking the size, > via munmap() and mremap(), can leave an empty space, therefore can > be replaced with a VMA with a new set of attributes. > > 2> Moving or expanding a different VMA into the current location, > via mremap(). > > 3> Modifying a VMA via mmap(MAP_FIXED). > > 4> Size expansion, via mremap(), does not appear to pose any specific > risks to sealed VMAs. It is included anyway because the use case is > unclear. In any case, users can rely on merging to expand a sealed VMA. > > 5> mprotect() and pkey_mprotect(). > > 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous > memory, when users don't have write permission to the memory. Those > behaviors can alter region contents by discarding pages, effectively a > memset(0) for anonymous memory. > > In addition: mmap() has two related changes. > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > the map sealed since creation. > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > the map as sealable. A map created without MAP_SEALABLE will not support > sealing, i.e. mseal() will fail. > > Applications that don't care about sealing will expect their behavior > unchanged. For those that need sealing support, opt-in by adding > MAP_SEALABLE in mmap(). > > I would like to formally acknowledge the valuable contributions > received during the RFC process, which were instrumental > in shaping this patch: > > Jann Horn: raising awareness and providing valuable insights on the > destructive madvise operations. > Linus Torvalds: assisting in defining system call signature and scope. > Pedro Falcato: suggesting sealing in the mmap(). > Theo de Raadt: sharing the experiences and insights gained from > implementing mimmutable() in OpenBSD. > > Finally, the idea that inspired this patch comes from Stephen Röttger’s > work in Chrome V8 CFI. > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > --- > include/linux/mm.h | 48 ++++ > include/linux/syscalls.h | 1 + > include/uapi/asm-generic/mman-common.h | 8 + > mm/Makefile | 4 + > mm/madvise.c | 12 + > mm/mmap.c | 27 ++ > mm/mprotect.c | 10 + > mm/mremap.c | 31 +++ > mm/mseal.c | 343 +++++++++++++++++++++++++ > 9 files changed, 484 insertions(+) > create mode 100644 mm/mseal.c > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index f5a97dec5169..bdd9a53e9291 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h None of this can live in mm/internal.h ? > @@ -328,6 +328,14 @@ extern unsigned int kobjsize(const void *objp); > #define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5) > #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */ > > +#ifdef CONFIG_64BIT > +/* VM is sealable, in vm_flags */ > +#define VM_SEALABLE _BITUL(63) > + > +/* VM is sealed, in vm_flags */ > +#define VM_SEALED _BITUL(62) > +#endif > + > #ifdef CONFIG_ARCH_HAS_PKEYS > # define VM_PKEY_SHIFT VM_HIGH_ARCH_BIT_0 > # define VM_PKEY_BIT0 VM_HIGH_ARCH_0 /* A protection key is a 4-bit value */ > @@ -4182,4 +4190,44 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn) > return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE); > } > > +#ifdef CONFIG_64BIT > +static inline int can_do_mseal(unsigned long flags) > +{ > + if (flags) > + return -EINVAL; > + > + return 0; > +} > + > +bool can_modify_mm(struct mm_struct *mm, unsigned long start, > + unsigned long end); > +bool can_modify_mm_madv(struct mm_struct *mm, unsigned long start, > + unsigned long end, int behavior); > +unsigned long get_mmap_seals(unsigned long prot, > + unsigned long flags); > +#else > +static inline int can_do_mseal(unsigned long flags) > +{ > + return -EPERM; > +} > + > +static inline bool can_modify_mm(struct mm_struct *mm, unsigned long start, > + unsigned long end) > +{ > + return true; > +} > + > +static inline bool can_modify_mm_madv(struct mm_struct *mm, unsigned long start, > + unsigned long end, int behavior) > +{ > + return true; > +} > + > +static inline unsigned long get_mmap_seals(unsigned long prot, > + unsigned long flags) > +{ > + return 0; > +} > +#endif > + > #endif /* _LINUX_MM_H */ ... > diff --git a/mm/mmap.c b/mm/mmap.c > index b78e83d351d2..32bc2179aed0 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1213,6 +1213,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > { > struct mm_struct *mm = current->mm; > int pkey = 0; > + unsigned long vm_seals; > > *populate = 0; > > @@ -1233,6 +1234,8 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > if (flags & MAP_FIXED_NOREPLACE) > flags |= MAP_FIXED; > > + vm_seals = get_mmap_seals(prot, flags); > + > if (!(flags & MAP_FIXED)) > addr = round_hint_to_min(addr); > > @@ -1261,6 +1264,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > return -EEXIST; > } > > + /* > + * Check if the address range is sealed for do_mmap(). > + * can_modify_mm assumes we have acquired the lock on MM. > + */ > + if (!can_modify_mm(mm, addr, addr + len)) > + return -EPERM; > + This is called after get_unmapped_area(), so this area is either going to be MAP_FIXED and return the "hint" addr or it's going to be empty. You can probably avoid walking the VMAs in the non-FIXED case. This would remove the overhead of your check in the most common case. > if (prot == PROT_EXEC) { > pkey = execute_only_pkey(mm); > if (pkey < 0) > @@ -1376,6 +1386,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > vm_flags |= VM_NORESERVE; > } > > + vm_flags |= vm_seals; > addr = mmap_region(file, addr, len, vm_flags, pgoff, uf); > if (!IS_ERR_VALUE(addr) && > ((vm_flags & VM_LOCKED) || > @@ -2679,6 +2690,14 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, > if (end == start) > return -EINVAL; > > + /* > + * Check if memory is sealed before arch_unmap. > + * Prevent unmapping a sealed VMA. > + * can_modify_mm assumes we have acquired the lock on MM. > + */ > + if (!can_modify_mm(mm, start, end)) > + return -EPERM; > + This function is currently called from mmap_region(), so we are going to run this check twice as you have it; once in do_mmap() then again in mma_region() -> do_vmi_munmap(). This effectively doubles your impact to MAP_FIXED calls. > /* arch_unmap() might do unmaps itself. */ > arch_unmap(mm, start, end); > > @@ -3102,6 +3121,14 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, > { > struct mm_struct *mm = vma->vm_mm; > > + /* > + * Check if memory is sealed before arch_unmap. > + * Prevent unmapping a sealed VMA. > + * can_modify_mm assumes we have acquired the lock on MM. > + */ > + if (!can_modify_mm(mm, start, end)) > + return -EPERM; > + I am sure you've looked at the callers, from what I found there are two: The brk call uses this function, so it may check more than one VMA in that path. Will the brk VMAs potentially be msealed? I guess someone could do that? The other place this is use is in ipc/shm.c whhere the start/end is just the vma start/end, so we only really need to check that one vma. Is there a way to avoid walking the tree for the single known VMA? Does it make sense to deny mseal writing to brk VMAs? > arch_unmap(mm, start, end); > return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock); > } ... Ah, I see them now. Yes, this is what I expected to see. Does this not have any impact on mmap/munmap benchmarks? > +bool can_modify_mm(struct mm_struct *mm, unsigned long start, unsigned long end) > +{ > + struct vm_area_struct *vma; > + > + VMA_ITERATOR(vmi, mm, start); > + > + /* going through each vma to check. */ > + for_each_vma_range(vmi, vma, end) { > + if (!can_modify_vma(vma)) > + return false; > + } > + > + /* Allow by default. */ > + return true; > +} > + > +/* > + * Check if the vmas of a memory range are allowed to be modified by madvise. > + * the memory ranger can have a gap (unallocated memory). > + * return true, if it is allowed. > + */ > +bool can_modify_mm_madv(struct mm_struct *mm, unsigned long start, unsigned long end, > + int behavior) > +{ > + struct vm_area_struct *vma; > + > + VMA_ITERATOR(vmi, mm, start); > + > + if (!is_madv_discard(behavior)) > + return true; > + > + /* going through each vma to check. */ > + for_each_vma_range(vmi, vma, end) > + if (is_ro_anon(vma) && !can_modify_vma(vma)) > + return false; > + > + /* Allow by default. */ > + return true; > +} > + ... > +static int check_mm_seal(unsigned long start, unsigned long end) > +{ > + struct vm_area_struct *vma; > + unsigned long nstart = start; > + > + VMA_ITERATOR(vmi, current->mm, start); > + > + /* going through each vma to check. */ > + for_each_vma_range(vmi, vma, end) { > + if (vma->vm_start > nstart) > + /* unallocated memory found. */ > + return -ENOMEM; Ah, another potential user for a contiguous iterator of VMAs. > + > + if (!can_add_vma_seal(vma)) > + return -EACCES; > + > + if (vma->vm_end >= end) > + return 0; > + > + nstart = vma->vm_end; > + } > + > + return -ENOMEM; > +} > + > +/* > + * Apply sealing. > + */ > +static int apply_mm_seal(unsigned long start, unsigned long end) > +{ > + unsigned long nstart; > + struct vm_area_struct *vma, *prev; > + > + VMA_ITERATOR(vmi, current->mm, start); > + > + vma = vma_iter_load(&vmi); > + /* > + * Note: check_mm_seal should already checked ENOMEM case. > + * so vma should not be null, same for the other ENOMEM cases. The start to end is contiguous, right? > + */ > + prev = vma_prev(&vmi); > + if (start > vma->vm_start) > + prev = vma; > + > + nstart = start; > + for_each_vma_range(vmi, vma, end) { > + int error; > + unsigned long tmp; > + vm_flags_t newflags; > + > + newflags = vma->vm_flags | VM_SEALED; > + tmp = vma->vm_end; > + if (tmp > end) > + tmp = end; > + error = mseal_fixup(&vmi, vma, &prev, nstart, tmp, newflags); > + if (error) > + return error; > + tmp = vma_iter_end(&vmi); > + nstart = tmp; You set tmp before using it unconditionally to vma->vm_end above, so you can set nstart = vma_iter_end(&vmi) here. But, also we know the VMAs are contiguous from your check_mm_seal() call, so we know nstart == vma->vm_start on the next loop. ...
Liam R. Howlett <Liam.Howlett@Oracle.com> wrote: > * Theo de Raadt <deraadt@openbsd.org> [240122 17:35]: > > Jeff Xu <jeffxu@chromium.org> wrote: > > > > > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <deraadt@openbsd.org> wrote: > > > > > > > > Regarding these pieces > > > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > > the map sealed since creation. > > > > > > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my > > > > research I found basically zero circumstances when you userland does > > > > that. The most common circumstance is you create a RW mapping, fill it, > > > > and then change to a more restrictve mapping, and lock it. > > > > > > > > There are a few regions in the addressspace that can be locked while RW. > > > > For instance, the stack. But the kernel does that, not userland. I > > > > found regions where the kernel wants to do this to the address space, > > > > but there is no need to export useless functionality to userland. > > > > > > > I have a feeling that most apps that need to use mmap() in their code > > > are likely using RW mappings. Adding sealing to mmap() could stop > > > those mappings from being executable. Of course, those apps would > > > need to change their code. We can't do it for them. > > > > I don't have a feeling about it. > > > > I spent a year engineering a complete system which exercises the maximum > > amount of memory you can lock. > > > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > > drafts, and saw it turning into a dangerous anti-pattern. > > > > > Also, I believe adding this to mmap() has no downsides, only > > > performance gain, as Pedro Falcato pointed out in [1]. > > > > > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/ > > > > Are you joking? You don't have any code doing that today. More feelings? > > The 'no downside" is to combining two calls together; mmap() & mseal(), > at least that is how I read the linked discussion. > > The common case (since there are no users today) of just calling > mmap()/munmap() will have the downside. > > There will be a performance impact once you have can_modify_mm() doing > more than just returning true. Certainly, the impact will be larger > in munmap where multiple VMAs may need to be checked (assuming that's > the plan?). > > This will require a new and earlier walk of the vma tree while holding > the mmap_lock. Since you are checking (potentially multiple) VMAs for > something, I don't think there is a way around holding the lock. > > I'm not saying the cost will be large, but it will be a positive > non-zero number. For future glibc changes, I predict you will have zero cases where you can call mmap+immutable or mprotect+immutable, I say so, because I ended up having none. You always have to fill the memory. (At first glance you might think it works for a new DSO's BSS, but RELRO overlaps it, and since RELRO mprotect happens quite late, the permission locking is quite delayed relative to the allocation). I think chrome also won't lock memory at allocation. I suspect the generic allocator is quite seperate from the code using the allocation, which knows which objects can have their permissions locked and which objects can't. In OpenBSD, the only cases where we could set immutable at the same time as creating the mapping was in execve, for a new process's stack regions, and that is kernel code, not the userland exposed system call APIs. This change could skip adding PROT_MSEAL today, and add it later when there are facts the need. It's the same with MAP_MSEALABLE. I don't get it. So now there are 3 memory types: - cannot be sealed, ever - not yet sealed - sealed What purpose does the first type serve? Please explain the use case. Today, processes have control over their entire address space. What is the purpose of "permissions cannot be locked". Please supply an example. If I am wrong, I'd like to know where I went wrong.
On Tue, Jan 23, 2024 at 10:15 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote: > > * jeffxu@chromium.org <jeffxu@chromium.org> [240122 10:29]: > > From: Jeff Xu <jeffxu@chromium.org> > > > > 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. > > > > mseal() blocks following operations for the given memory range. > > > > 1> Unmapping, moving to another location, and shrinking the size, > > via munmap() and mremap(), can leave an empty space, therefore can > > be replaced with a VMA with a new set of attributes. > > > > 2> Moving or expanding a different VMA into the current location, > > via mremap(). > > > > 3> Modifying a VMA via mmap(MAP_FIXED). > > > > 4> Size expansion, via mremap(), does not appear to pose any specific > > risks to sealed VMAs. It is included anyway because the use case is > > unclear. In any case, users can rely on merging to expand a sealed VMA. > > > > 5> mprotect() and pkey_mprotect(). > > > > 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous > > memory, when users don't have write permission to the memory. Those > > behaviors can alter region contents by discarding pages, effectively a > > memset(0) for anonymous memory. > > > > In addition: mmap() has two related changes. > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > the map sealed since creation. > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > > the map as sealable. A map created without MAP_SEALABLE will not support > > sealing, i.e. mseal() will fail. > > > > Applications that don't care about sealing will expect their behavior > > unchanged. For those that need sealing support, opt-in by adding > > MAP_SEALABLE in mmap(). > > > > I would like to formally acknowledge the valuable contributions > > received during the RFC process, which were instrumental > > in shaping this patch: > > > > Jann Horn: raising awareness and providing valuable insights on the > > destructive madvise operations. > > Linus Torvalds: assisting in defining system call signature and scope. > > Pedro Falcato: suggesting sealing in the mmap(). > > Theo de Raadt: sharing the experiences and insights gained from > > implementing mimmutable() in OpenBSD. > > > > Finally, the idea that inspired this patch comes from Stephen Röttger’s > > work in Chrome V8 CFI. > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > --- > > include/linux/mm.h | 48 ++++ > > include/linux/syscalls.h | 1 + > > include/uapi/asm-generic/mman-common.h | 8 + > > mm/Makefile | 4 + > > mm/madvise.c | 12 + > > mm/mmap.c | 27 ++ > > mm/mprotect.c | 10 + > > mm/mremap.c | 31 +++ > > mm/mseal.c | 343 +++++++++++++++++++++++++ > > 9 files changed, 484 insertions(+) > > create mode 100644 mm/mseal.c > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index f5a97dec5169..bdd9a53e9291 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > None of this can live in mm/internal.h ? > Will move. Thanks. > > @@ -328,6 +328,14 @@ extern unsigned int kobjsize(const void *objp); > > #define VM_HIGH_ARCH_5 BIT(VM_HIGH_ARCH_BIT_5) > > #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */ > > > > +#ifdef CONFIG_64BIT > > +/* VM is sealable, in vm_flags */ > > +#define VM_SEALABLE _BITUL(63) > > + > > +/* VM is sealed, in vm_flags */ > > +#define VM_SEALED _BITUL(62) > > +#endif > > + > > #ifdef CONFIG_ARCH_HAS_PKEYS > > # define VM_PKEY_SHIFT VM_HIGH_ARCH_BIT_0 > > # define VM_PKEY_BIT0 VM_HIGH_ARCH_0 /* A protection key is a 4-bit value */ > > @@ -4182,4 +4190,44 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn) > > return range_contains_unaccepted_memory(paddr, paddr + PAGE_SIZE); > > } > > > > +#ifdef CONFIG_64BIT > > +static inline int can_do_mseal(unsigned long flags) > > +{ > > + if (flags) > > + return -EINVAL; > > + > > + return 0; > > +} > > + > > +bool can_modify_mm(struct mm_struct *mm, unsigned long start, > > + unsigned long end); > > +bool can_modify_mm_madv(struct mm_struct *mm, unsigned long start, > > + unsigned long end, int behavior); > > +unsigned long get_mmap_seals(unsigned long prot, > > + unsigned long flags); > > +#else > > +static inline int can_do_mseal(unsigned long flags) > > +{ > > + return -EPERM; > > +} > > + > > +static inline bool can_modify_mm(struct mm_struct *mm, unsigned long start, > > + unsigned long end) > > +{ > > + return true; > > +} > > + > > +static inline bool can_modify_mm_madv(struct mm_struct *mm, unsigned long start, > > + unsigned long end, int behavior) > > +{ > > + return true; > > +} > > + > > +static inline unsigned long get_mmap_seals(unsigned long prot, > > + unsigned long flags) > > +{ > > + return 0; > > +} > > +#endif > > + > > #endif /* _LINUX_MM_H */ > > ... > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index b78e83d351d2..32bc2179aed0 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1213,6 +1213,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > { > > struct mm_struct *mm = current->mm; > > int pkey = 0; > > + unsigned long vm_seals; > > > > *populate = 0; > > > > @@ -1233,6 +1234,8 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > if (flags & MAP_FIXED_NOREPLACE) > > flags |= MAP_FIXED; > > > > + vm_seals = get_mmap_seals(prot, flags); > > + > > if (!(flags & MAP_FIXED)) > > addr = round_hint_to_min(addr); > > > > @@ -1261,6 +1264,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > return -EEXIST; > > } > > > > + /* > > + * Check if the address range is sealed for do_mmap(). > > + * can_modify_mm assumes we have acquired the lock on MM. > > + */ > > + if (!can_modify_mm(mm, addr, addr + len)) > > + return -EPERM; > > + > > This is called after get_unmapped_area(), so this area is either going > to be MAP_FIXED and return the "hint" addr or it's going to be empty. > You can probably avoid walking the VMAs in the non-FIXED case. This > would remove the overhead of your check in the most common case. > Thanks for flagging this! I wasn't entirely sure about get_unmapped_area() after reading the code, It calls a few variants of arch_get_unmapped_area_xxx() functions. e.g. it seems like the generic_get_unmapped_area_topdown is returning a non-null address even when MAP_FIXED is set to false ---------------------------------------------------------------------------- generic_get_unmapped_area_topdown ( ... if (flags & MAP_FIXED) <-- MAP_FIXED case. return addr; /* requesting a specific address */ if (addr) { <-- note not MAP_FIXED addr = PAGE_ALIGN(addr); vma = find_vma_prev(mm, addr, &prev); if (mmap_end - len >= addr && addr >= mmap_min_addr && (!vma || addr + len <= vm_start_gap(vma)) && (!prev || addr >= vm_end_gap(prev))) return addr; <--- note return not null addr here. } ---------------------------------------------------------------------------- I thought also about adding a check for addr != null instead, i.e. if (addr && !can_modify_mm(mm, addr, addr + len)) return -EPERM; } But using MAP_FIXED to allocate memory at address 0 is legit, e.g. allocating a PROT_NONE | PROT_SEAL at address 0. Another factor to consider is: what will be the cost of passing an empty address into can_modify_mm() ? the search will be 0 to len. > > if (prot == PROT_EXEC) { > > pkey = execute_only_pkey(mm); > > if (pkey < 0) > > @@ -1376,6 +1386,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > vm_flags |= VM_NORESERVE; > > } > > > > + vm_flags |= vm_seals; > > addr = mmap_region(file, addr, len, vm_flags, pgoff, uf); > > if (!IS_ERR_VALUE(addr) && > > ((vm_flags & VM_LOCKED) || > > @@ -2679,6 +2690,14 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, > > if (end == start) > > return -EINVAL; > > > > + /* > > + * Check if memory is sealed before arch_unmap. > > + * Prevent unmapping a sealed VMA. > > + * can_modify_mm assumes we have acquired the lock on MM. > > + */ > > + if (!can_modify_mm(mm, start, end)) > > + return -EPERM; > > + > > This function is currently called from mmap_region(), so we are going to > run this check twice as you have it; once in do_mmap() then again in > mma_region() -> do_vmi_munmap(). This effectively doubles your impact > to MAP_FIXED calls. > Yes. To address this would require a new flag in the do_vmi_munmap(), after passing the first check in mmap(), we could set the flag as false, so do_vmi_munmap() would not check it again. However, this approach was attempted in v1 and V2 of the patch [1] [2], and was strongly opposed by Linus. It was considered as too random and decreased the readability. Below is my text in V2: [3] "When handing the mmap/munmap/mremap/mmap, once the code passed can_modify_mm(), it means the memory area is not sealed, if the code continues to call the other utility functions, we don't need to check the seal again. This is the case for mremap(), the seal of src address and dest address (when applicable) are checked first, later when the code calls do_vmi_munmap(), it no longer needs to check the seal again." Considering this is the MAP_FIXED case, and maybe that is not used that often in practice, I think this is acceptable performance-wise, unless you know another solution to help this. [1] https://lore.kernel.org/lkml/20231016143828.647848-6-jeffxu@chromium.org/ [2] https://lore.kernel.org/lkml/20231017090815.1067790-6-jeffxu@chromium.org/ [3] https://lore.kernel.org/lkml/CALmYWFux2m=9189Gs0o8-xhPNW4dnFvtqj7ptcT5QvzxVgfvYQ@mail.gmail.com/ > > /* arch_unmap() might do unmaps itself. */ > > arch_unmap(mm, start, end); > > > > @@ -3102,6 +3121,14 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, > > { > > struct mm_struct *mm = vma->vm_mm; > > > > + /* > > + * Check if memory is sealed before arch_unmap. > > + * Prevent unmapping a sealed VMA. > > + * can_modify_mm assumes we have acquired the lock on MM. > > + */ > > + if (!can_modify_mm(mm, start, end)) > > + return -EPERM; > > + > > I am sure you've looked at the callers, from what I found there are two: > > The brk call uses this function, so it may check more than one VMA in > that path. Will the brk VMAs potentially be msealed? I guess someone > could do that? > > The other place this is use is in ipc/shm.c whhere the start/end is just > the vma start/end, so we only really need to check that one vma. > Yes. Those two cases were looked at, and was the main reason that MAP_SEALABLE is introduced as part of mmap(). As in the open discussion of the V3/V4 patch: [4] [5] [4] https://lore.kernel.org/linux-mm/20231212231706.2680890-1-jeffxu@chromium.org/T/ [5] https://lore.kernel.org/linux-mm/20240104185138.169307-3-jeffxu@chromium.org/T/ Copied here for ease of reading: --------------------------------------------------------------------------------------------- During the development of V3, I had new questions and thoughts and wished to discuss. 1> shm/aio
On Mon, Jan 22, 2024 at 2:34 PM Theo de Raadt <deraadt@openbsd.org> wrote: > > Jeff Xu <jeffxu@chromium.org> wrote: > > > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <deraadt@openbsd.org> wrote: > > > > > > Regarding these pieces > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > the map sealed since creation. > > > > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my > > > research I found basically zero circumstances when you userland does > > > that. The most common circumstance is you create a RW mapping, fill it, > > > and then change to a more restrictve mapping, and lock it. > > > > > > There are a few regions in the addressspace that can be locked while RW. > > > For instance, the stack. But the kernel does that, not userland. I > > > found regions where the kernel wants to do this to the address space, > > > but there is no need to export useless functionality to userland. > > > > > I have a feeling that most apps that need to use mmap() in their code > > are likely using RW mappings. Adding sealing to mmap() could stop > > those mappings from being executable. Of course, those apps would > > need to change their code. We can't do it for them. > > I don't have a feeling about it. > > I spent a year engineering a complete system which exercises the maximum > amount of memory you can lock. > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > drafts, and saw it turning into a dangerous anti-pattern. > I'm sorry, I have never looked at one line of openBSD code, prototype or not, nor did I install openBSD before. Because of this situation on my side, I failed to understand why you have such a strong opinion on PROC_SEAL in mmap() in linux kernel, based on your own OpenBSD's experience ? For PROT_SEAL in mmap(), I see it as a good and reasonable suggestion raised during the RFC process, and incorporate it into the patch set, there is nothing more and nothing less. If openBSD doesn't want it, that is fine to me, it is not that I'm trying to force this into openBSD's kernel, I understand it is a different code base. > > Also, I believe adding this to mmap() has no downsides, only > > performance gain, as Pedro Falcato pointed out in [1]. > > > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/ > > Are you joking? You don't have any code doing that today. More feelings? > > OpenBSD userland has zero places it can use mmap() MAP_IMMUTABLE. > > It has two places where it has mprotect() + mimmutable() adjacent to each > other, two codepaths for late mprotect() of RELRO, and then make the RELRO > immutable. > > I think this idea is a premature optimization, and intentionally incompatible. > > Like I say, I had a similar MAP_ flag for mprotect() and mmap() in my > development trees, and I recognized it was pointless, distracting developers > into the wrong patterns, and I threw it out. > > > > OpenBSD now uses this for a high percent of the address space. It might > > > be worth re-reading a description of the split of responsibility regarding > > > who locks different types of memory in a process; > > > - kernel (the majority, based upon what ELF layout tell us), > > > - shared library linker (the next majority, dealing with shared > > > library mappings and left-overs not determinable at kernel time), > > > - libc (a small minority, mostly regarding forced mutable objects) > > > - and the applications themselves (only 1 application today) > > > > > > https://lwn.net/Articles/915662/ > > > > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > > > > the map as sealable. A map created without MAP_SEALABLE will not support > > > > sealing, i.e. mseal() will fail. > > > > > > We definately won't be doing this. We allow a process to lock any and all > > > it's memory that isn't locked already, even if it means it is shooting > > > itself in the foot. > > > > > > I think you are going to severely hurt the power of this mechanism, > > > because you won't be able to lock memory that has been allocated by a > > > different callsite not under your source-code control which lacks the > > > MAP_SEALABLE flag. (Which is extremely common with the system-parts of > > > a process, meaning not just libc but kernel allocated objects). > > > > > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3]. > > > > I acknowledge that additional coordination would be required if > > mapping were to be allocated by one software component and sealed in > > another. However, this is feasible. > > > > Considering the side effect of not having this flag (as discussed in > > V3/V4) and the significant implications of altering the lifetime of > > the mapping (since unmapping would not be possible), I believe it is > > reasonable to expect developers to exercise additional care and > > caution when utilizing memory sealing. > > > > [2] https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromium.org/ > > [3] https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org/ > > I disagree *strongly*. Developers need to exercise additional care on > memory, period. Memory sealing issues is the least of their worries. > > (Except for handling RELRO, but only the ld.so developers will lose > their hair). > > > OK, so mseal and mimmutable are very different. > > mimmutable can be used by any developer on the address space easily. > > mseal requires control of the whole stack between allocation and consumption. > > I'm sorry, but I don't think you understand how dangerous this MAP_SEALABLE > proposal is because of the difficulties it will create for use. > > The immutable memory management we have today in OpenBSD would completely > impossible with such a flag. Seperation between allocator (that doesn't know > what is going to happen), and consumer (that does know), is completely common > in the systems environment (meaning the interaction between DSO, libc, other > libraries, and the underside of applications). > > This is not not like an application where you can simply sprinkle the flag > into the mmap() calls that cause you problems. That mmap() call is now in > someone else's code, and you CANNOT gain security advantage unless you > convince them to gain an understanding of what that flag means -- and it is > a flag that other Linux variants don't have, not even in their #include > files. > I respect your reasoning with OpenBSD, but do you have a real example that this will be problematic for linux ? In my opinion, the extra communication part with mmap()'s owner has its pros and cons. The cons is what you mentioned: extra time for convincing and approval. The pro is that there won't be unexpected behavior from the code owner point of view, once this communication process is completed. It can reduce the possibility of introducing bugs. So far, I do not have enough information to say this is a bad idea. if you can provide a real example in the context of linux, e.g. DSO and libc you mentioned with details, that will be helpful.
On Tue, Jan 23, 2024 at 10:58 AM Theo de Raadt <deraadt@openbsd.org> wrote: > > It's the same with MAP_MSEALABLE. I don't get it. So now there are 3 > memory types: > - cannot be sealed, ever > - not yet sealed > - sealed > > What purpose does the first type serve? Please explain the use case. > > Today, processes have control over their entire address space. > > What is the purpose of "permissions cannot be locked". Please supply > an example. If I am wrong, I'd like to know where I went wrong. > The linux example is in the V3 and V4 cover letter [1] [2] of the open discussion section. [1] https://lore.kernel.org/linux-mm/20231212231706.2680890-1-jeffxu@chromium.org/T/ [2] https://lore.kernel.org/linux-mm/20240104185138.169307-3-jeffxu@chromium.org/T/ Copied below for ease of reading. ----------------------------------------------------------------------------------------- During the development of V3, I had new questions and thoughts and wished to discuss. 1> shm/aio
Jeff Xu <jeffxu@chromium.org> wrote: > > I don't have a feeling about it. > > > > I spent a year engineering a complete system which exercises the maximum > > amount of memory you can lock. > > > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > > drafts, and saw it turning into a dangerous anti-pattern. > > > I'm sorry, I have never looked at one line of openBSD code, prototype > or not, nor did I install openBSD before. That is really disingeneous. It is obvious to everyone that mseal is a derivative of the mimmutable mechanism, the raw idea stems directly from this and you didn't need to stay at a Holiday Express Inn. > Because of this situation on my side, I failed to understand why you > have such a strong opinion on PROC_SEAL in mmap() in linux kernel, > based on your own OpenBSD's experience ? Portable and compatible interfaces are good. Historically, incompatible interfaces are less good. > For PROT_SEAL in mmap(), I see it as a good and reasonable suggestion > raised during the RFC process, and incorporate it into the patch set, > there is nothing more and nothing less. Yet, you and those who suggested it don't have a single line of userland code ready which will use this. > If openBSD doesn't want it, that is fine to me, it is not that I'm > trying to force this into openBSD's kernel, I understand it is a > different code base. This has nothing to do with code base. It is about attempting to decrease differences between systems; this approach which has always been valuable. Divergence has always been painful. > > > > OpenBSD now uses this for a high percent of the address space. It might > > > > be worth re-reading a description of the split of responsibility regarding > > > > who locks different types of memory in a process; > > > > - kernel (the majority, based upon what ELF layout tell us), > > > > - shared library linker (the next majority, dealing with shared > > > > library mappings and left-overs not determinable at kernel time), > > > > - libc (a small minority, mostly regarding forced mutable objects) > > > > - and the applications themselves (only 1 application today) > > > > > > > > https://lwn.net/Articles/915662/ > > > > > > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > > > > > the map as sealable. A map created without MAP_SEALABLE will not support > > > > > sealing, i.e. mseal() will fail. > > > > > > > > We definately won't be doing this. We allow a process to lock any and all > > > > it's memory that isn't locked already, even if it means it is shooting > > > > itself in the foot. > > > > > > > > I think you are going to severely hurt the power of this mechanism, > > > > because you won't be able to lock memory that has been allocated by a > > > > different callsite not under your source-code control which lacks the > > > > MAP_SEALABLE flag. (Which is extremely common with the system-parts of > > > > a process, meaning not just libc but kernel allocated objects). > > > > > > > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3]. > > > > > > I acknowledge that additional coordination would be required if > > > mapping were to be allocated by one software component and sealed in > > > another. However, this is feasible. > > > > > > Considering the side effect of not having this flag (as discussed in > > > V3/V4) and the significant implications of altering the lifetime of > > > the mapping (since unmapping would not be possible), I believe it is > > > reasonable to expect developers to exercise additional care and > > > caution when utilizing memory sealing. > > > > > > [2] https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromium.org/ > > > [3] https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org/ > > > > I disagree *strongly*. Developers need to exercise additional care on > > memory, period. Memory sealing issues is the least of their worries. > > > > (Except for handling RELRO, but only the ld.so developers will lose > > their hair). > > > > > > OK, so mseal and mimmutable are very different. > > > > mimmutable can be used by any developer on the address space easily. > > > > mseal requires control of the whole stack between allocation and consumption. > > > > I'm sorry, but I don't think you understand how dangerous this MAP_SEALABLE > > proposal is because of the difficulties it will create for use. > > > > The immutable memory management we have today in OpenBSD would completely > > impossible with such a flag. Seperation between allocator (that doesn't know > > what is going to happen), and consumer (that does know), is completely common > > in the systems environment (meaning the interaction between DSO, libc, other > > libraries, and the underside of applications). > > > > This is not not like an application where you can simply sprinkle the flag > > into the mmap() calls that cause you problems. That mmap() call is now in > > someone else's code, and you CANNOT gain security advantage unless you > > convince them to gain an understanding of what that flag means -- and it is > > a flag that other Linux variants don't have, not even in their #include > > files. > > > I respect your reasoning with OpenBSD, but do you have a real example > that this will be problematic for linux ? See below. > In my opinion, the extra communication part with mmap()'s owner has > its pros and cons. See below. > The cons is what you mentioned: extra time for convincing and approval. No, it is much worse than that. See below. > The pro is that there won't be unexpected behavior from the code owner > point of view, once this communication process is completed. It can > reduce the possibility of introducing bugs. > > So far, I do not have enough information to say this is a bad idea. > if you can provide a real example in the context of linux, e.g. DSO > and libc you mentioned with details, that will be helpful. Does the kernel map the main program's text segment, data segment, bss segment, and stack with MAP_SEALABLE or without MAP_SEALABLE? Once it is mapped, userland starts running. If those objects don't have MAP_SEALABLE, then ld.so and libc cannot perform locking of those mappings. And ld.so or libc must do some of those lockings later, some of these map lockings cannot be performed in the kernel because userland makes data modifications and permission modifications before proceeding into main(). This is unavoidable, because of RELRO; binaries with text relocation; binaries with W|X mappings; it is probably required for IFUNC setup; and I strongly suspect there are additional circumstances which require this, *just for glibc* to use the mechanism. If the kernel does map those regions with MAP_SEALABLE, then it seems the most important parts of the address space are going to have MAP_SEALABLE anyways. So what were you trying to defend against? So why are you doing this MAP_SEALABLE dance? It makes no sense. I'm sorry, but it is you who must justify these strange semantics which you are introducing -- to change a mechanism previously engineered and fully deployed in another operating system. To me, not being able to justify these behavious seems to be based on intentional ignorance. "Not Invented Here", is what I see. You say glibc will use this. I call bollocks. I see a specific behaviour which will prevent use by glibc. I designed my mechanism with libc specifically considered -- it was a whole system environment. You work on chrome. You don't work on glibc. The glibc people aren't publically talking about this. From my perspective, this is looking really dumb.
* Jeff Xu <jeffxu@chromium.org> [240124 12:50]: > On Tue, Jan 23, 2024 at 10:15 AM Liam R. Howlett > <Liam.Howlett@oracle.com> wrote: > > > > * jeffxu@chromium.org <jeffxu@chromium.org> [240122 10:29]: > > > From: Jeff Xu <jeffxu@chromium.org> > > > > > > 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. > > > > > > mseal() blocks following operations for the given memory range. > > > > > > 1> Unmapping, moving to another location, and shrinking the size, > > > via munmap() and mremap(), can leave an empty space, therefore can > > > be replaced with a VMA with a new set of attributes. > > > > > > 2> Moving or expanding a different VMA into the current location, > > > via mremap(). > > > > > > 3> Modifying a VMA via mmap(MAP_FIXED). > > > > > > 4> Size expansion, via mremap(), does not appear to pose any specific > > > risks to sealed VMAs. It is included anyway because the use case is > > > unclear. In any case, users can rely on merging to expand a sealed VMA. > > > > > > 5> mprotect() and pkey_mprotect(). > > > > > > 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous > > > memory, when users don't have write permission to the memory. Those > > > behaviors can alter region contents by discarding pages, effectively a > > > memset(0) for anonymous memory. > > > > > > In addition: mmap() has two related changes. > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > the map sealed since creation. > > > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > > > the map as sealable. A map created without MAP_SEALABLE will not support > > > sealing, i.e. mseal() will fail. > > > > > > Applications that don't care about sealing will expect their behavior > > > unchanged. For those that need sealing support, opt-in by adding > > > MAP_SEALABLE in mmap(). > > > > > > I would like to formally acknowledge the valuable contributions > > > received during the RFC process, which were instrumental > > > in shaping this patch: > > > > > > Jann Horn: raising awareness and providing valuable insights on the > > > destructive madvise operations. > > > Linus Torvalds: assisting in defining system call signature and scope. > > > Pedro Falcato: suggesting sealing in the mmap(). > > > Theo de Raadt: sharing the experiences and insights gained from > > > implementing mimmutable() in OpenBSD. > > > > > > Finally, the idea that inspired this patch comes from Stephen Röttger’s > > > work in Chrome V8 CFI. > > > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > --- > > > include/linux/mm.h | 48 ++++ > > > include/linux/syscalls.h | 1 + > > > include/uapi/asm-generic/mman-common.h | 8 + > > > mm/Makefile | 4 + > > > mm/madvise.c | 12 + > > > mm/mmap.c | 27 ++ > > > mm/mprotect.c | 10 + > > > mm/mremap.c | 31 +++ > > > mm/mseal.c | 343 +++++++++++++++++++++++++ > > > 9 files changed, 484 insertions(+) > > > create mode 100644 mm/mseal.c > > > ... > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > index b78e83d351d2..32bc2179aed0 100644 > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -1213,6 +1213,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > { > > > struct mm_struct *mm = current->mm; > > > int pkey = 0; > > > + unsigned long vm_seals; > > > > > > *populate = 0; > > > > > > @@ -1233,6 +1234,8 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > if (flags & MAP_FIXED_NOREPLACE) > > > flags |= MAP_FIXED; > > > > > > + vm_seals = get_mmap_seals(prot, flags); > > > + > > > if (!(flags & MAP_FIXED)) > > > addr = round_hint_to_min(addr); > > > > > > @@ -1261,6 +1264,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > return -EEXIST; > > > } > > > > > > + /* > > > + * Check if the address range is sealed for do_mmap(). > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > + */ > > > + if (!can_modify_mm(mm, addr, addr + len)) > > > + return -EPERM; > > > + > > > > This is called after get_unmapped_area(), so this area is either going > > to be MAP_FIXED and return the "hint" addr or it's going to be empty. > > You can probably avoid walking the VMAs in the non-FIXED case. This > > would remove the overhead of your check in the most common case. > > > > Thanks for flagging this! > > I wasn't entirely sure about get_unmapped_area() after reading the > code, It calls a few variants of arch_get_unmapped_area_xxx() > functions. > > e.g. it seems like the generic_get_unmapped_area_topdown is returning > a non-null address even when MAP_FIXED is set to false > > ---------------------------------------------------------------------------- > generic_get_unmapped_area_topdown ( > ... > if (flags & MAP_FIXED) <-- MAP_FIXED case. > return addr; > > /* requesting a specific address */ > if (addr) { <-- note not MAP_FIXED > addr = PAGE_ALIGN(addr); > vma = find_vma_prev(mm, addr, &prev); > if (mmap_end - len >= addr && addr >= mmap_min_addr && > (!vma || addr + len <= vm_start_gap(vma)) && > (!prev || addr >= vm_end_gap(prev))) > return addr; <--- note return not null addr here. > } Sorry, I was not clear. Either MAP_FIXED will just return the addr, or the addr that is returned has no VMA (the memory area is empty). This function finds a gap to place your data and the gap is (at least) as big as you want (usually oversized, but that doesn't matter here). The mmap_lock is held, so we know it's going to remain empty. So there are two scenarios: 1. MAP_FIXED which may or may not have a VMA over the range 2. An address which has no VMA over the range Anyways, this is probably not needed, because of what I say later. > > ---------------------------------------------------------------------------- > I thought also about adding a check for addr != null instead, i.e. > if (addr && !can_modify_mm(mm, addr, addr + len)) > return -EPERM; > } > > But using MAP_FIXED to allocate memory at address 0 is legit, e.g. > allocating a PROT_NONE | PROT_SEAL at address 0. > > Another factor to consider is: what will be the cost of passing an > empty address into can_modify_mm() ? the search will be 0 to len. Almost always zero VMAs to check, it's not worth optimising. The maple tree will walk to the first range and it'll be 0 to some very large number, most likely. > > > > if (prot == PROT_EXEC) { > > > pkey = execute_only_pkey(mm); > > > if (pkey < 0) > > > @@ -1376,6 +1386,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > vm_flags |= VM_NORESERVE; > > > } > > > > > > + vm_flags |= vm_seals; > > > addr = mmap_region(file, addr, len, vm_flags, pgoff, uf); > > > if (!IS_ERR_VALUE(addr) && > > > ((vm_flags & VM_LOCKED) || > > > @@ -2679,6 +2690,14 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, > > > if (end == start) > > > return -EINVAL; > > > > > > + /* > > > + * Check if memory is sealed before arch_unmap. > > > + * Prevent unmapping a sealed VMA. > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > + */ > > > + if (!can_modify_mm(mm, start, end)) > > > + return -EPERM; > > > + > > > > This function is currently called from mmap_region(), so we are going to > > run this check twice as you have it; once in do_mmap() then again in > > mma_region() -> do_vmi_munmap(). This effectively doubles your impact > > to MAP_FIXED calls. > > > Yes. To address this would require a new flag in the do_vmi_munmap(), > after passing the first check in mmap(), we could set the flag as false, > so do_vmi_munmap() would not check it again. > > However, this approach was attempted in v1 and V2 of the patch [1] [2], > and was strongly opposed by Linus. It was considered as too random and > decreased the readability. Oh yes, I recall that now. He was not pleased. > > Below is my text in V2: [3] > > "When handing the mmap/munmap/mremap/mmap, once the code passed > can_modify_mm(), it means the memory area is not sealed, if the code > continues to call the other utility functions, we don't need to check > the seal again. This is the case for mremap(), the seal of src address > and dest address (when applicable) are checked first, later when the > code calls do_vmi_munmap(), it no longer needs to check the seal > again." > > Considering this is the MAP_FIXED case, and maybe that is not used > that often in practice, I think this is acceptable performance-wise, > unless you know another solution to help this. Okay, sure, I haven't been yelled at on the ML for a few weeks. Here goes: do_mmap() will call get_unmapped_area(), which will return an empty area (no need to check mseal, I hope - or we have larger issues here) or a MAP_FIXED address. do_mmap() will pass the address along to mmap_region() mmap_region() will then call do_vmi_munmap() - which will either remove the VMA(s) in the way, or do nothing... or error. mmap_region() will return -ENOMEM in the case of an error returned from do_vmi_munmap() today. Change that to return the error code, and let do_vmi_munmap() do the mseal check. If mseal check fails then the error is propagated the same way -ENOMEM is propagated today. This relies on the fact that we only really need to check the mseal status of existing VMAs and we can only really map over existing VMAs by first munmapping them. It does move your error return to much later in the call stack, but it removes duplicate work and less code. Considering this should be a rare event, I don't think that's of concern. > > [1] https://lore.kernel.org/lkml/20231016143828.647848-6-jeffxu@chromium.org/ > [2] https://lore.kernel.org/lkml/20231017090815.1067790-6-jeffxu@chromium.org/ > [3] https://lore.kernel.org/lkml/CALmYWFux2m=9189Gs0o8-xhPNW4dnFvtqj7ptcT5QvzxVgfvYQ@mail.gmail.com/ > > > > > /* arch_unmap() might do unmaps itself. */ > > > arch_unmap(mm, start, end); > > > > > > @@ -3102,6 +3121,14 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > { > > > struct mm_struct *mm = vma->vm_mm; > > > > > > + /* > > > + * Check if memory is sealed before arch_unmap. > > > + * Prevent unmapping a sealed VMA. > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > + */ > > > + if (!can_modify_mm(mm, start, end)) > > > + return -EPERM; > > > + > > > > I am sure you've looked at the callers, from what I found there are two: > > > > The brk call uses this function, so it may check more than one VMA in > > that path. Will the brk VMAs potentially be msealed? I guess someone > > could do that? > > > > The other place this is use is in ipc/shm.c whhere the start/end is just > > the vma start/end, so we only really need to check that one vma. > > > Yes. Those two cases were looked at, and was the main reason that > MAP_SEALABLE is introduced as part of mmap(). > > As in the open discussion of the V3/V4 patch: [4] [5] > > [4] https://lore.kernel.org/linux-mm/20231212231706.2680890-1-jeffxu@chromium.org/T/ > [5] https://lore.kernel.org/linux-mm/20240104185138.169307-3-jeffxu@chromium.org/T/ > > Copied here for ease of reading: > --------------------------------------------------------------------------------------------- > > During the development of V3, I had new questions and thoughts and > wished to discuss. > > 1> shm/aio > From reading the code, it seems to me that aio/shm can mmap/munmap > maps on behalf of userspace, e.g. ksys_shmdt() in shm.c. The lifetime > of those mapping are not tied to the lifetime of the process. If those > memories are sealed from userspace, then unmap will fail. This isn’t a > huge problem, since the memory will eventually be freed at exit or > exec. However, it feels like the solution is not complete, because of > the leaks in VMA address space during the lifetime of the process. > > 2> Brk (heap/stack) > Currently, userspace applications can seal parts of the heap by > calling malloc() and mseal(). This raises the question of what the > expected behavior is when sealing the heap is attempted. > > let's assume following calls from user space: > > ptr = malloc(size); > mprotect(ptr, size, RO); > mseal(ptr, size, SEAL_PROT_PKEY); > free(ptr); > > Technically, before mseal() is added, the user can change the > protection of the heap by calling mprotect(RO). As long as the user > changes the protection back to RW before free(), the memory can be > reused. > > Adding mseal() into picture, however, the heap is then sealed > partially, user can still free it, but the memory remains to be RO, > and the result of brk-shrink is nondeterministic, depending on if > munmap() will try to free the sealed memory.(brk uses munmap to shrink > the heap). > > 3> Above two cases led to the third topic: > There one option to address the problem mentioned above. > Option 1: A “MAP_SEALABLE” flag in mmap(). > If a map is created without this flag, the mseal() operation will > fail. Applications that are not concerned with sealing will expect > their behavior to be unchanged. For those that are concerned, adding a > flag at mmap time to opt in is not difficult. For the short term, this > solves problems 1 and 2 above. The memory in shm/aio/brk will not have > the MAP_SEALABLE flag at mmap(), and the same is true for the heap. > > If we choose not to go with path, all mapping will by default > sealable. We could document above mentioned limitations so devs are > more careful at the time to choose what memory to seal. I think > deny of service through mseal() by attacker is probably not a concern, > if attackers have access to mseal() and unsealed memory, then they can > also do other harmful thing to the memory, such as munmap, etc. > > 4> > I think it might be possible to seal the stack or other special > mappings created at runtime (vdso, vsyscall, vvar). This means we can > enforce and seal W^X for certain types of application. For instance, > the stack is typically used in read-write mode, but in some cases, it > can become executable. To defend against unintented addition of > executable bit to stack, we could let the application to seal it. > > Sealing the heap (for adding X) requires special handling, since the > heap can shrink, and shrink is implemented through munmap(). > > Indeed, it might be possible that all virtual memory accessible to user > space, regardless of its usage pattern, could be sealed. However, this > would require additional research and development work. > > ----------------------------------------------------------------------------------------------------- > > > > Is there a way to avoid walking the tree for the single known VMA? > Are you thinking about a hash table to record brk VMA ? or a dedicated > tree for sealed VMAs? possible. code will be a lot more though. No, instead of calling a loop to walk the tree to find the same VMA, just check the single VMA. ipc/shm.c: do_vma_munmap(&vmi, vma, vma->vm_start, vma->vm_end... So if you just check the single VMA then we don't need to worry about re-walking. I think this is a moot point if my outline above works. > > > Does > > it make sense to deny mseal writing to brk VMAs? > > > Yes. It makes sense. Since brk memory doesn't have MAP_SEALABLE at > this moment, mseal will fail even if someone tries to seal it. > Sealing brk memory would require more research and design. > > > > > > arch_unmap(mm, start, end); > > > return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock); > > > } > > > > ... > > > > > > Ah, I see them now. Yes, this is what I expected to see. Does this not > > have any impact on mmap/munmap benchmarks? > > > Thanks for bringing this topic! I'm kind of hoping for performance related > questions. > > I haven't done any benchmarks, due to lack of knowledge on how those > tests are usually performed. > > For mseal(), since it will be called only in a few places (libc/elf > loading), I'm expecting no real world impact, and that can be > measured when we have implementations in place in libc and > elf-loading. > > The hot path could be on mmap() and munmap(), as you pointed out. > > mmap() was discussed above (adding a check for FIXED ) That can probably be dropped as discussed above. > > munmap(), There is a cost in calling can_modify_mm(). I thought about > calling can_modify_vma in do_vmi_align_munmap, but there are two reasons: > > a. it skips arch_unmap, and arch_unmap can unmap the memory. > b. Current logic of checking sealing is: if one of VMAs between start to end is > sealed, mprotect/mmap/munmap will fail without any of VMAs being modified. > This means we will need additional walking over the VMA tree. Certainly, but it comes at a cost. I was just surprised with the statement that there is no negative from the previous discussion, as I replied to the cover letter. > > > +/* > > > + * Apply sealing. > > > + */ > > > +static int apply_mm_seal(unsigned long start, unsigned long end) > > > +{ > > > + unsigned long nstart; > > > + struct vm_area_struct *vma, *prev; > > > + > > > + VMA_ITERATOR(vmi, current->mm, start); > > > + > > > + vma = vma_iter_load(&vmi); > > > + /* > > > + * Note: check_mm_seal should already checked ENOMEM case. > > > + * so vma should not be null, same for the other ENOMEM cases. > > > > The start to end is contiguous, right? > Yes. check_mm_seal makes sure the start to end is contiguous. > > > > > > + */ > > > + prev = vma_prev(&vmi); > > > + if (start > vma->vm_start) > > > + prev = vma; > > > + > > > + nstart = start; > > > + for_each_vma_range(vmi, vma, end) { > > > + int error; > > > + unsigned long tmp; > > > + vm_flags_t newflags; > > > + > > > + newflags = vma->vm_flags | VM_SEALED; > > > + tmp = vma->vm_end; > > > + if (tmp > end) > > > + tmp = end; > > > + error = mseal_fixup(&vmi, vma, &prev, nstart, tmp, newflags); > > > + if (error) > > > + return error; > > > > > + tmp = vma_iter_end(&vmi); > > > + nstart = tmp; > > > > You set tmp before using it unconditionally to vma->vm_end above, so you > > can set nstart = vma_iter_end(&vmi) here. But, also we know the > > VMAs are contiguous from your check_mm_seal() call, so we know nstart == > > vma->vm_start on the next loop. > The code is almost the same as in mlock.c, except that we know the > VMAs are contiguous, so we don't check for some of the ENOMEM cases. > There might be ways to improve this code. For ease of code review, I > choose a consistency (same as mlock) for now. Yes, I thought that was the case. tmp is updated in that code to ensure we have reached the end of the range without a gap at the end. Since you already checked that the VMAs are contiguous, the last tmp update in your loop is not needed. Thanks, Liam
Liam R. Howlett <Liam.Howlett@Oracle.com> wrote: > > Adding mseal() into picture, however, the heap is then sealed > > partially, user can still free it, but the memory remains to be RO, > > and the result of brk-shrink is nondeterministic, depending on if > > munmap() will try to free the sealed memory.(brk uses munmap to shrink > > the heap). "You are holding it wrong". > > [...]. We could document above mentioned limitations so devs are > > more careful at the time to choose what memory to seal. You mean like they need to be careful what memory they map, careful what memory they unmap, careful what they do with mprotect, careful about not writing or reading out of bounds, etc. They need to be careful about everything. Programmers have complete control over the address space in a program. This is Linux we are talking about, it still doesn't have strict policy on W | X memory, but misuse of mseal is suddenly a developer crisis? Why is this memory attribute different, and how does it actually help? When they use mseal on objects with unproven future, the program will crash later, beautifully demonstrating that they held it wrong. Then they can fix their abusive incorrect code. This discussion about the malloc heap is ridiculous. Obviously it is programmer error to lock the permissions on memory you will free for reuse. But you can't fix this problem with malloc(), without breaking other extremely common circumstances where the allocation of memory and PERMANENT-USE-WITHOUT-RELEASE of such memory are seperated over a memory boundary, unless you start telling all open source library authors to always use MAP_SEALABLE in their mmap() calls.
Theo de Raadt <deraadt@openbsd.org> wrote: > This discussion about the malloc heap is ridiculous. Obviously it is > programmer error to lock the permissions on memory you will free for > reuse. But you can't fix this problem with malloc(), without breaking > other extremely common circumstances where the allocation of memory > and PERMANENT-USE-WITHOUT-RELEASE of such memory are seperated over a > memory boundary, unless you start telling all open source library authors ^^^^^^^^^^^^^^^ library boundary, sorry > to always use MAP_SEALABLE in their mmap() calls. Example: 1. libcrypto (or some other library) has some ways to allocate memory and provide it to an application. 2. Even if this is using malloc(), heap allocations over a pagesize are page-aligned, so even then following assumptions are sound. 3. I have an application which uses that memory, but will never release the memory until program termination 4. The library interface is public and used by many programs, so the library author has a choice of using MAP_SEALABLE or not using MAP_SEALABLE Due to your choice, my application cannot make lock the memory permissions unless that library author chooses MAP_SEALABLE If they choose to use MAP_SEALABLE, all programs get this memory you consider less safe. Exactly what is being gained here?
On Wed, Jan 24, 2024 at 12:06 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote: > > * Jeff Xu <jeffxu@chromium.org> [240124 12:50]: > > On Tue, Jan 23, 2024 at 10:15 AM Liam R. Howlett > > <Liam.Howlett@oracle.com> wrote: > > > > > > * jeffxu@chromium.org <jeffxu@chromium.org> [240122 10:29]: > > > > From: Jeff Xu <jeffxu@chromium.org> > > > > > > > > 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. > > > > > > > > mseal() blocks following operations for the given memory range. > > > > > > > > 1> Unmapping, moving to another location, and shrinking the size, > > > > via munmap() and mremap(), can leave an empty space, therefore can > > > > be replaced with a VMA with a new set of attributes. > > > > > > > > 2> Moving or expanding a different VMA into the current location, > > > > via mremap(). > > > > > > > > 3> Modifying a VMA via mmap(MAP_FIXED). > > > > > > > > 4> Size expansion, via mremap(), does not appear to pose any specific > > > > risks to sealed VMAs. It is included anyway because the use case is > > > > unclear. In any case, users can rely on merging to expand a sealed VMA. > > > > > > > > 5> mprotect() and pkey_mprotect(). > > > > > > > > 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous > > > > memory, when users don't have write permission to the memory. Those > > > > behaviors can alter region contents by discarding pages, effectively a > > > > memset(0) for anonymous memory. > > > > > > > > In addition: mmap() has two related changes. > > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > the map sealed since creation. > > > > > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks > > > > the map as sealable. A map created without MAP_SEALABLE will not support > > > > sealing, i.e. mseal() will fail. > > > > > > > > Applications that don't care about sealing will expect their behavior > > > > unchanged. For those that need sealing support, opt-in by adding > > > > MAP_SEALABLE in mmap(). > > > > > > > > I would like to formally acknowledge the valuable contributions > > > > received during the RFC process, which were instrumental > > > > in shaping this patch: > > > > > > > > Jann Horn: raising awareness and providing valuable insights on the > > > > destructive madvise operations. > > > > Linus Torvalds: assisting in defining system call signature and scope. > > > > Pedro Falcato: suggesting sealing in the mmap(). > > > > Theo de Raadt: sharing the experiences and insights gained from > > > > implementing mimmutable() in OpenBSD. > > > > > > > > Finally, the idea that inspired this patch comes from Stephen Röttger’s > > > > work in Chrome V8 CFI. > > > > > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > > --- > > > > include/linux/mm.h | 48 ++++ > > > > include/linux/syscalls.h | 1 + > > > > include/uapi/asm-generic/mman-common.h | 8 + > > > > mm/Makefile | 4 + > > > > mm/madvise.c | 12 + > > > > mm/mmap.c | 27 ++ > > > > mm/mprotect.c | 10 + > > > > mm/mremap.c | 31 +++ > > > > mm/mseal.c | 343 +++++++++++++++++++++++++ > > > > 9 files changed, 484 insertions(+) > > > > create mode 100644 mm/mseal.c > > > > > > ... > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > > index b78e83d351d2..32bc2179aed0 100644 > > > > --- a/mm/mmap.c > > > > +++ b/mm/mmap.c > > > > @@ -1213,6 +1213,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > > { > > > > struct mm_struct *mm = current->mm; > > > > int pkey = 0; > > > > + unsigned long vm_seals; > > > > > > > > *populate = 0; > > > > > > > > @@ -1233,6 +1234,8 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > > if (flags & MAP_FIXED_NOREPLACE) > > > > flags |= MAP_FIXED; > > > > > > > > + vm_seals = get_mmap_seals(prot, flags); > > > > + > > > > if (!(flags & MAP_FIXED)) > > > > addr = round_hint_to_min(addr); > > > > > > > > @@ -1261,6 +1264,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > > return -EEXIST; > > > > } > > > > > > > > + /* > > > > + * Check if the address range is sealed for do_mmap(). > > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > > + */ > > > > + if (!can_modify_mm(mm, addr, addr + len)) > > > > + return -EPERM; > > > > + > > > > > > This is called after get_unmapped_area(), so this area is either going > > > to be MAP_FIXED and return the "hint" addr or it's going to be empty. > > > You can probably avoid walking the VMAs in the non-FIXED case. This > > > would remove the overhead of your check in the most common case. > > > > > > > Thanks for flagging this! > > > > I wasn't entirely sure about get_unmapped_area() after reading the > > code, It calls a few variants of arch_get_unmapped_area_xxx() > > functions. > > > > e.g. it seems like the generic_get_unmapped_area_topdown is returning > > a non-null address even when MAP_FIXED is set to false > > > > ---------------------------------------------------------------------------- > > generic_get_unmapped_area_topdown ( > > ... > > if (flags & MAP_FIXED) <-- MAP_FIXED case. > > return addr; > > > > /* requesting a specific address */ > > if (addr) { <-- note not MAP_FIXED > > addr = PAGE_ALIGN(addr); > > vma = find_vma_prev(mm, addr, &prev); > > if (mmap_end - len >= addr && addr >= mmap_min_addr && > > (!vma || addr + len <= vm_start_gap(vma)) && > > (!prev || addr >= vm_end_gap(prev))) > > return addr; <--- note return not null addr here. > > } > > Sorry, I was not clear. Either MAP_FIXED will just return the addr, or > the addr that is returned has no VMA (the memory area is empty). This > function finds a gap to place your data and the gap is (at least) as big > as you want (usually oversized, but that doesn't matter here). The > mmap_lock is held, so we know it's going to remain empty. > > So there are two scenarios: > 1. MAP_FIXED which may or may not have a VMA over the range > 2. An address which has no VMA over the range > > Anyways, this is probably not needed, because of what I say later. > > > > > ---------------------------------------------------------------------------- > > I thought also about adding a check for addr != null instead, i.e. > > if (addr && !can_modify_mm(mm, addr, addr + len)) > > return -EPERM; > > } > > > > But using MAP_FIXED to allocate memory at address 0 is legit, e.g. > > allocating a PROT_NONE | PROT_SEAL at address 0. > > > > Another factor to consider is: what will be the cost of passing an > > empty address into can_modify_mm() ? the search will be 0 to len. > > Almost always zero VMAs to check, it's not worth optimising. The maple > tree will walk to the first range and it'll be 0 to some very large > number, most likely. > Got you. > > > > > > if (prot == PROT_EXEC) { > > > > pkey = execute_only_pkey(mm); > > > > if (pkey < 0) > > > > @@ -1376,6 +1386,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > > > vm_flags |= VM_NORESERVE; > > > > } > > > > > > > > + vm_flags |= vm_seals; > > > > addr = mmap_region(file, addr, len, vm_flags, pgoff, uf); > > > > if (!IS_ERR_VALUE(addr) && > > > > ((vm_flags & VM_LOCKED) || > > > > @@ -2679,6 +2690,14 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, > > > > if (end == start) > > > > return -EINVAL; > > > > > > > > + /* > > > > + * Check if memory is sealed before arch_unmap. > > > > + * Prevent unmapping a sealed VMA. > > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > > + */ > > > > + if (!can_modify_mm(mm, start, end)) > > > > + return -EPERM; > > > > + > > > > > > This function is currently called from mmap_region(), so we are going to > > > run this check twice as you have it; once in do_mmap() then again in > > > mma_region() -> do_vmi_munmap(). This effectively doubles your impact > > > to MAP_FIXED calls. > > > > > Yes. To address this would require a new flag in the do_vmi_munmap(), > > after passing the first check in mmap(), we could set the flag as false, > > so do_vmi_munmap() would not check it again. > > > > However, this approach was attempted in v1 and V2 of the patch [1] [2], > > and was strongly opposed by Linus. It was considered as too random and > > decreased the readability. > > Oh yes, I recall that now. He was not pleased. > > > > > Below is my text in V2: [3] > > > > "When handing the mmap/munmap/mremap/mmap, once the code passed > > can_modify_mm(), it means the memory area is not sealed, if the code > > continues to call the other utility functions, we don't need to check > > the seal again. This is the case for mremap(), the seal of src address > > and dest address (when applicable) are checked first, later when the > > code calls do_vmi_munmap(), it no longer needs to check the seal > > again." > > > > Considering this is the MAP_FIXED case, and maybe that is not used > > that often in practice, I think this is acceptable performance-wise, > > unless you know another solution to help this. > > Okay, sure, I haven't been yelled at on the ML for a few weeks. Here > goes: > > do_mmap() will call get_unmapped_area(), which will return an empty area > (no need to check mseal, I hope - or we have larger issues here) or a > MAP_FIXED address. > > do_mmap() will pass the address along to mmap_region() > > mmap_region() will then call do_vmi_munmap() - which will either remove > the VMA(s) in the way, or do nothing... or error. > > mmap_region() will return -ENOMEM in the case of an error returned from > do_vmi_munmap() today. Change that to return the error code, and let > do_vmi_munmap() do the mseal check. If mseal check fails then the error > is propagated the same way -ENOMEM is propagated today. > > This relies on the fact that we only really need to check the mseal > status of existing VMAs and we can only really map over existing VMAs by > first munmapping them. > > It does move your error return to much later in the call stack, but it > removes duplicate work and less code. Considering this should be a rare > event, I don't think that's of concern. > I think that is a great idea, I will try to implement it and get back to you on this. > > > > [1] https://lore.kernel.org/lkml/20231016143828.647848-6-jeffxu@chromium.org/ > > [2] https://lore.kernel.org/lkml/20231017090815.1067790-6-jeffxu@chromium.org/ > > [3] https://lore.kernel.org/lkml/CALmYWFux2m=9189Gs0o8-xhPNW4dnFvtqj7ptcT5QvzxVgfvYQ@mail.gmail.com/ > > > > > > > > /* arch_unmap() might do unmaps itself. */ > > > > arch_unmap(mm, start, end); > > > > > > > > @@ -3102,6 +3121,14 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > > { > > > > struct mm_struct *mm = vma->vm_mm; > > > > > > > > + /* > > > > + * Check if memory is sealed before arch_unmap. > > > > + * Prevent unmapping a sealed VMA. > > > > + * can_modify_mm assumes we have acquired the lock on MM. > > > > + */ > > > > + if (!can_modify_mm(mm, start, end)) > > > > + return -EPERM; > > > > + > > > > > > I am sure you've looked at the callers, from what I found there are two: > > > > > > The brk call uses this function, so it may check more than one VMA in > > > that path. Will the brk VMAs potentially be msealed? I guess someone > > > could do that? > > > > > > The other place this is use is in ipc/shm.c whhere the start/end is just > > > the vma start/end, so we only really need to check that one vma. > > > > > Yes. Those two cases were looked at, and was the main reason that > > MAP_SEALABLE is introduced as part of mmap(). > > > > As in the open discussion of the V3/V4 patch: [4] [5] > > > > [4] https://lore.kernel.org/linux-mm/20231212231706.2680890-1-jeffxu@chromium.org/T/ > > [5] https://lore.kernel.org/linux-mm/20240104185138.169307-3-jeffxu@chromium.org/T/ > > > > Copied here for ease of reading: > > --------------------------------------------------------------------------------------------- > > > > During the development of V3, I had new questions and thoughts and > > wished to discuss. > > > > 1> shm/aio > > From reading the code, it seems to me that aio/shm can mmap/munmap > > maps on behalf of userspace, e.g. ksys_shmdt() in shm.c. The lifetime > > of those mapping are not tied to the lifetime of the process. If those > > memories are sealed from userspace, then unmap will fail. This isn’t a > > huge problem, since the memory will eventually be freed at exit or > > exec. However, it feels like the solution is not complete, because of > > the leaks in VMA address space during the lifetime of the process. > > > > 2> Brk (heap/stack) > > Currently, userspace applications can seal parts of the heap by > > calling malloc() and mseal(). This raises the question of what the > > expected behavior is when sealing the heap is attempted. > > > > let's assume following calls from user space: > > > > ptr = malloc(size); > > mprotect(ptr, size, RO); > > mseal(ptr, size, SEAL_PROT_PKEY); > > free(ptr); > > > > Technically, before mseal() is added, the user can change the > > protection of the heap by calling mprotect(RO). As long as the user > > changes the protection back to RW before free(), the memory can be > > reused. > > > > Adding mseal() into picture, however, the heap is then sealed > > partially, user can still free it, but the memory remains to be RO, > > and the result of brk-shrink is nondeterministic, depending on if > > munmap() will try to free the sealed memory.(brk uses munmap to shrink > > the heap). > > > > 3> Above two cases led to the third topic: > > There one option to address the problem mentioned above. > > Option 1: A “MAP_SEALABLE” flag in mmap(). > > If a map is created without this flag, the mseal() operation will > > fail. Applications that are not concerned with sealing will expect > > their behavior to be unchanged. For those that are concerned, adding a > > flag at mmap time to opt in is not difficult. For the short term, this > > solves problems 1 and 2 above. The memory in shm/aio/brk will not have > > the MAP_SEALABLE flag at mmap(), and the same is true for the heap. > > > > If we choose not to go with path, all mapping will by default > > sealable. We could document above mentioned limitations so devs are > > more careful at the time to choose what memory to seal. I think > > deny of service through mseal() by attacker is probably not a concern, > > if attackers have access to mseal() and unsealed memory, then they can > > also do other harmful thing to the memory, such as munmap, etc. > > > > 4> > > I think it might be possible to seal the stack or other special > > mappings created at runtime (vdso, vsyscall, vvar). This means we can > > enforce and seal W^X for certain types of application. For instance, > > the stack is typically used in read-write mode, but in some cases, it > > can become executable. To defend against unintented addition of > > executable bit to stack, we could let the application to seal it. > > > > Sealing the heap (for adding X) requires special handling, since the > > heap can shrink, and shrink is implemented through munmap(). > > > > Indeed, it might be possible that all virtual memory accessible to user > > space, regardless of its usage pattern, could be sealed. However, this > > would require additional research and development work. > > > > ----------------------------------------------------------------------------------------------------- > > > > > > > Is there a way to avoid walking the tree for the single known VMA? > > Are you thinking about a hash table to record brk VMA ? or a dedicated > > tree for sealed VMAs? possible. code will be a lot more though. > > No, instead of calling a loop to walk the tree to find the same VMA, > just check the single VMA. > > ipc/shm.c: do_vma_munmap(&vmi, vma, vma->vm_start, vma->vm_end... > > So if you just check the single VMA then we don't need to worry about > re-walking. > If you meant: have a new function do_single_vma_munmap() which checks sealing flag and munmap for one VMA, and is used by ipc/shm.c Yes, we can have that. > I think this is a moot point if my outline above works. > Yes, I agree. that has performance impact only for shm. We can do this optimationzation as a follow-up patch set. > > > > > Does > > > it make sense to deny mseal writing to brk VMAs? > > > > > Yes. It makes sense. Since brk memory doesn't have MAP_SEALABLE at > > this moment, mseal will fail even if someone tries to seal it. > > Sealing brk memory would require more research and design. > > > > > > > > > arch_unmap(mm, start, end); > > > > return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock); > > > > } > > > > > > ... > > > > > > > > > Ah, I see them now. Yes, this is what I expected to see. Does this not > > > have any impact on mmap/munmap benchmarks? > > > > > Thanks for bringing this topic! I'm kind of hoping for performance related > > questions. > > > > I haven't done any benchmarks, due to lack of knowledge on how those > > tests are usually performed. > > > > For mseal(), since it will be called only in a few places (libc/elf > > loading), I'm expecting no real world impact, and that can be > > measured when we have implementations in place in libc and > > elf-loading. > > > > The hot path could be on mmap() and munmap(), as you pointed out. > > > > mmap() was discussed above (adding a check for FIXED ) > > That can probably be dropped as discussed above. > Ok. > > > > munmap(), There is a cost in calling can_modify_mm(). I thought about > > calling can_modify_vma in do_vmi_align_munmap, but there are two reasons: > > > > a. it skips arch_unmap, and arch_unmap can unmap the memory. > > b. Current logic of checking sealing is: if one of VMAs between start to end is > > sealed, mprotect/mmap/munmap will fail without any of VMAs being modified. > > This means we will need additional walking over the VMA tree. > > Certainly, but it comes at a cost. I was just surprised with the > statement that there is no negative from the previous discussion, as I > replied to the cover letter. > Ah, the context of my "no downside" comment is specifically to "having the PROT_SEAL flag in mmap()", i.e. combine mmap() and mseal() in one call. > > > > +/* > > > > + * Apply sealing. > > > > + */ > > > > +static int apply_mm_seal(unsigned long start, unsigned long end) > > > > +{ > > > > + unsigned long nstart; > > > > + struct vm_area_struct *vma, *prev; > > > > + > > > > + VMA_ITERATOR(vmi, current->mm, start); > > > > + > > > > + vma = vma_iter_load(&vmi); > > > > + /* > > > > + * Note: check_mm_seal should already checked ENOMEM case. > > > > + * so vma should not be null, same for the other ENOMEM cases. > > > > > > The start to end is contiguous, right? > > Yes. check_mm_seal makes sure the start to end is contiguous. > > > > > > > > > + */ > > > > + prev = vma_prev(&vmi); > > > > + if (start > vma->vm_start) > > > > + prev = vma; > > > > + > > > > + nstart = start; > > > > + for_each_vma_range(vmi, vma, end) { > > > > + int error; > > > > + unsigned long tmp; > > > > + vm_flags_t newflags; > > > > + > > > > + newflags = vma->vm_flags | VM_SEALED; > > > > + tmp = vma->vm_end; > > > > + if (tmp > end) > > > > + tmp = end; > > > > + error = mseal_fixup(&vmi, vma, &prev, nstart, tmp, newflags); > > > > + if (error) > > > > + return error; > > > > > > > + tmp = vma_iter_end(&vmi); > > > > + nstart = tmp; > > > > > > You set tmp before using it unconditionally to vma->vm_end above, so you > > > can set nstart = vma_iter_end(&vmi) here. But, also we know the > > > VMAs are contiguous from your check_mm_seal() call, so we know nstart == > > > vma->vm_start on the next loop. > > The code is almost the same as in mlock.c, except that we know the > > VMAs are contiguous, so we don't check for some of the ENOMEM cases. > > There might be ways to improve this code. For ease of code review, I > > choose a consistency (same as mlock) for now. > > Yes, I thought that was the case. tmp is updated in that code to ensure > we have reached the end of the range without a gap at the end. Since > you already checked that the VMAs are contiguous, the last tmp update in > your loop is not needed. > > Thanks, > Liam
Jeff Xu <jeffxu@chromium.org> writes: > On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet <corbet@lwn.net> wrote: >> >> jeffxu@chromium.org writes: >> >> > Although the initial version of this patch series is targeting the >> > Chrome browser as its first user, it became evident during upstream >> > discussions that we would also want to ensure that the patch set >> > eventually is a complete solution for memory sealing and compatible >> > with other use cases. The specific scenario currently in mind is >> > glibc's use case of loading and sealing ELF executables. To this end, >> > Stephen is working on a change to glibc to add sealing support to the >> > dynamic linker, which will seal all non-writable segments at startup. >> > Once this work is completed, all applications will be able to >> > automatically benefit from these new protections. >> >> Is this work posted somewhere? Having a second - and more generally >> useful - user for this API would do a lot to show that the design is, in >> fact, right and useful beyond the Chrome browser. >> > Stephen conducted a PoC last year, it will be published once it is complete. > We're super excited about introducing this as a general safety measure > for all of Linux! We're excited too, something like mseal() seems like a good thing to have. My point, though, is that it would be good to see this second (and more general) user of the API *before* merging it. As others have noted, once mseal() is in a released kernel, it will be difficult to change if adjustments turn out to be necessary. Thanks, jon
From: Jeff Xu <jeffxu@chromium.org> This patchset proposes a new mseal() syscall for the Linux kernel. In a nutshell, mseal() protects the VMAs of a given virtual memory range against modifications, such as changes to their permission bits. Modern CPUs support memory permissions, such as the read/write (RW) and no-execute (NX) bits. Linux has supported NX since the release of kernel version 2.6.8 in August 2004 [1]. The memory permission feature improves the security stance on memory corruption bugs, as an attacker cannot simply write to arbitrary memory and point the code to it. The memory must be marked with the X bit, or else an exception will occur. Internally, the kernel maintains the memory permissions in a data structure called VMA (vm_area_struct). mseal() additionally protects the VMA itself against modifications of the selected seal type. Memory sealing is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system. For example, such an attacker primitive can break control-flow integrity guarantees since read-only memory that is supposed to be trusted can become writable or .text pages can get remapped. Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT [3] flag and on OpenBSD with the mimmutable syscall [4]. Also, Chrome wants to adopt this feature for their CFI work [2] and this patchset has been designed to be compatible with the Chrome use case. Two system calls are involved in sealing the map: mmap() and mseal(). 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. mseal() blocks following operations for the given memory range. 1> Unmapping, moving to another location, and shrinking the size, via munmap() and mremap(), can leave an empty space, therefore can be replaced with a VMA with a new set of attributes. 2> Moving or expanding a different VMA into the current location, via mremap(). 3> Modifying a VMA via mmap(MAP_FIXED). 4> Size expansion, via mremap(), does not appear to pose any specific risks to sealed VMAs. It is included anyway because the use case is unclear. In any case, users can rely on merging to expand a sealed VMA. 5> mprotect() and pkey_mprotect(). 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous memory, when users don't have write permission to the memory. Those behaviors can alter region contents by discarding pages, effectively a memset(0) for anonymous memory. In addition: mmap() has two related changes. The PROT_SEAL bit in prot field of mmap(). When present, it marks the map sealed since creation. The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks the map as sealable. A map created without MAP_SEALABLE will not support sealing, i.e. mseal() will fail. Applications that don't care about sealing will expect their behavior unchanged. For those that need sealing support, opt-in by adding MAP_SEALABLE in mmap(). The idea that inspired this patch comes from Stephen Röttger’s work in V8 CFI [5]. Chrome browser in ChromeOS will be the first user of this API. Indeed, the Chrome browser has very specific requirements for sealing, which are distinct from those of most applications. For example, in the case of libc, sealing is only applied to read-only (RO) or read-execute (RX) memory segments (such as .text and .RELRO) to prevent them from becoming writable, the lifetime of those mappings are tied to the lifetime of the process. Chrome wants to seal two large address space reservations that are managed by different allocators. The memory is mapped RW- and RWX respectively but write access to it is restricted using pkeys (or in the future ARM permission overlay extensions). The lifetime of those mappings are not tied to the lifetime of the process, therefore, while the memory is sealed, the allocators still need to free or discard the unused memory. For example, with madvise(DONTNEED). However, always allowing madvise(DONTNEED) on this range poses a security risk. For example if a jump instruction crosses a page boundary and the second page gets discarded, it will overwrite the target bytes with zeros and change the control flow. Checking write-permission before the discard operation allows us to control when the operation is valid. In this case, the madvise will only succeed if the executing thread has PKEY write permissions and PKRU changes are protected in software by control-flow integrity. Although the initial version of this patch series is targeting the Chrome browser as its first user, it became evident during upstream discussions that we would also want to ensure that the patch set eventually is a complete solution for memory sealing and compatible with other use cases. The specific scenario currently in mind is glibc's use case of loading and sealing ELF executables. To this end, Stephen is working on a change to glibc to add sealing support to the dynamic linker, which will seal all non-writable segments at startup. Once this work is completed, all applications will be able to automatically benefit from these new protections. In closing, I would like to formally acknowledge the valuable contributions received during the RFC process, which were instrumental in shaping this patch: Jann Horn: raising awareness and providing valuable insights on the destructive madvise operations. Linus Torvalds: assisting in defining system call signature and scope. Pedro Falcato: suggesting sealing in the mmap(). Theo de Raadt: sharing the experiences and insights gained from implementing mimmutable() in OpenBSD. Change history: =============== V7: - fix index.rst (Randy Dunlap) - fix arm build (Randy Dunlap) - return EPERM for blocked operations (Theo de Raadt) V6: - Drop RFC from subject, Given Linus's general approval. - Adjust syscall number for mseal (main Jan.11/2024) - Code style fix (Matthew Wilcox) - selftest: use ksft macros (Muhammad Usama Anjum) - Document fix. (Randy Dunlap) https://lore.kernel.org/all/20240111234142.2944934-1-jeffxu@chromium.org/ V5: - fix build issue in mseal-Wire-up-mseal-syscall (Suggested by Linus Torvalds, and Greg KH) - updates on selftest. https://lore.kernel.org/lkml/20240109154547.1839886-1-jeffxu@chromium.org/#r V4: (Suggested by Linus Torvalds) - new signature: mseal(start,len,flags) - 32 bit is not supported. vm_seal is removed, use vm_flags instead. - single bit in vm_flags for sealed state. - CONFIG_MSEAL kernel config is removed. - single bit of PROT_SEAL in the "Prot" field of mmap(). Other changes: - update selftest (Suggested by Muhammad Usama Anjum) - update documentation. https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org/ V3: - Abandon per-syscall approach, (Suggested by Linus Torvalds). - Organize sealing types around their functionality, such as MM_SEAL_BASE, MM_SEAL_PROT_PKEY. - Extend the scope of sealing from calls originated in userspace to both kernel and userspace. (Suggested by Linus Torvalds) - Add seal type support in mmap(). (Suggested by Pedro Falcato) - Add a new sealing type: MM_SEAL_DISCARD_RO_ANON to prevent destructive operations of madvise. (Suggested by Jann Horn and Stephen Röttger) - Make sealed VMAs mergeable. (Suggested by Jann Horn) - Add MAP_SEALABLE to mmap() - Add documentation - mseal.rst https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromium.org/ v2: Use _BITUL to define MM_SEAL_XX type. Use unsigned long for seal type in sys_mseal() and other functions. Remove internal VM_SEAL_XX type and convert_user_seal_type(). Remove MM_ACTION_XX type. Remove caller_origin(ON_BEHALF_OF_XX) and replace with sealing bitmask. Add more comments in code. Add a detailed commit message. https://lore.kernel.org/lkml/20231017090815.1067790-1-jeffxu@chromium.org/ v1: https://lore.kernel.org/lkml/20231016143828.647848-1-jeffxu@chromium.org/ ---------------------------------------------------------------- [1] https://kernelnewbies.org/Linux_2_6_8 [2] https://v8.dev/blog/control-flow-integrity [3] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 [4] https://man.openbsd.org/mimmutable.2 [5] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc [6] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com/ [7] https://lore.kernel.org/lkml/20230515130553.2311248-1-jeffxu@chromium.org/ Jeff Xu (4): mseal: Wire up mseal syscall mseal: add mseal syscall selftest mm/mseal memory sealing mseal:add documentation Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/mseal.rst | 183 ++ arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm/tools/syscall.tbl | 1 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + include/linux/mm.h | 48 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/mman-common.h | 8 + include/uapi/asm-generic/unistd.h | 5 +- kernel/sys_ni.c | 1 + mm/Makefile | 4 + mm/madvise.c | 12 + mm/mmap.c | 27 + mm/mprotect.c | 10 + mm/mremap.c | 31 + mm/mseal.c | 343 ++++ tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/mseal_test.c | 1997 +++++++++++++++++++ 33 files changed, 2690 insertions(+), 2 deletions(-) create mode 100644 Documentation/userspace-api/mseal.rst create mode 100644 mm/mseal.c create mode 100644 tools/testing/selftests/mm/mseal_test.c