From: Jeff Xu <jeffxu@chromium.org> In load_elf_binary as part of the execve(), when the current task’s personality has MMAP_PAGE_ZERO set, the kernel allocates one page at address 0. According to the comment: /* Why this, you ask??? Well SVr4 maps page 0 as read-only, and some applications "depend" upon this behavior. Since we do not have the power to recompile these, we emulate the SVr4 behavior. Sigh. */ At one point, Linus suggested removing this [1]. Sealing this is probably safe, the comment doesn’t say the app ever wanting to change the mapping to rwx. Sealing also ensures that never happens. [1] https://lore.kernel.org/lkml/CAHk-=whVa=nm_GW=NVfPHqcxDbWt4JjjK1YWb0cLjO4ZSGyiDA@mail.gmail.com/ Jeff Xu (1): binfmt_elf: mseal address zero fs/binfmt_elf.c | 4 ++++ include/linux/mm.h | 4 ++++ mm/mseal.c | 2 +- 3 files changed, 9 insertions(+), 1 deletion(-) -- 2.46.0.rc1.232.g9752f9e123-goog From: Jeff Xu <jeffxu@chromium.org> Some legacy SVr4 apps might depend on page on address zero to be readable, however I can't find a reason that the page ever becomes writeable, so seal it. If there is a compain, we can make this configurable. Signed-off-by: Jeff Xu <jeffxu@chromium.org> --- fs/binfmt_elf.c | 4 ++++ include/linux/mm.h | 4 ++++ mm/mseal.c | 2 +- 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index XXXXXXX..XXXXXXX 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -XXX,XX +XXX,XX @@ static int load_elf_binary(struct linux_binprm *bprm) emulate the SVr4 behavior. Sigh. */ error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC, MAP_FIXED | MAP_PRIVATE, 0); + +#ifdef CONFIG_64BIT + do_mseal(0, PAGE_SIZE, 0); +#endif } regs = current_pt_regs(); diff --git a/include/linux/mm.h b/include/linux/mm.h index XXXXXXX..XXXXXXX 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -XXX,XX +XXX,XX @@ void vma_pgtable_walk_end(struct vm_area_struct *vma); int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *size); +#ifdef CONFIG_64BIT +int do_mseal(unsigned long start, size_t len_in, unsigned long flags); +#endif + #endif /* _LINUX_MM_H */ diff --git a/mm/mseal.c b/mm/mseal.c index XXXXXXX..XXXXXXX 100644 --- a/mm/mseal.c +++ b/mm/mseal.c @@ -XXX,XX +XXX,XX @@ static int apply_mm_seal(unsigned long start, unsigned long end) * * unseal() is not supported. */ -static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) +int do_mseal(unsigned long start, size_t len_in, unsigned long flags) { size_t len; int ret = 0; -- 2.46.0.rc1.232.g9752f9e123-goog From: Jeff Xu <jeffxu@chromium.org> In load_elf_binary as part of the execve(), when the current task’s personality has MMAP_PAGE_ZERO set, the kernel allocates one page at address 0. According to the comment: /* Why this, you ask??? Well SVr4 maps page 0 as read-only, and some applications "depend" upon this behavior. Since we do not have the power to recompile these, we emulate the SVr4 behavior. Sigh. */ At one point, Linus suggested removing this [1]. Code search in debian didn't see much use of MMAP_PAGE_ZERO [2], it exists in util and test (rr). Sealing this is probably safe, the comment doesn’t say the app ever wanting to change the mapping to rwx. Sealing also ensures that never happens. [1] https://lore.kernel.org/lkml/CAHk-=whVa=nm_GW=NVfPHqcxDbWt4JjjK1YWb0cLjO4ZSGyiDA@mail.gmail.com/ [2] https://codesearch.debian.net/search?q=MMAP_PAGE_ZERO&literal=1&perpkg=1&page=1 Jeff Xu (1): binfmt_elf: mseal address zero fs/binfmt_elf.c | 5 +++++ include/linux/mm.h | 10 ++++++++++ mm/mseal.c | 2 +- 3 files changed, 16 insertions(+), 1 deletion(-) -- 2.46.0.rc2.264.g509ed76dc8-goog From: Jeff Xu <jeffxu@chromium.org> Some legacy SVr4 apps might depend on page on address zero to be readable, however I can't find a reason that the page ever becomes writeable, so seal it. If there is a compain, we can make this configurable. Signed-off-by: Jeff Xu <jeffxu@chromium.org> --- fs/binfmt_elf.c | 5 +++++ include/linux/mm.h | 10 ++++++++++ mm/mseal.c | 2 +- 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index XXXXXXX..XXXXXXX 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -XXX,XX +XXX,XX @@ static int load_elf_binary(struct linux_binprm *bprm) emulate the SVr4 behavior. Sigh. */ error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC, MAP_FIXED | MAP_PRIVATE, 0); + + retval = do_mseal(0, PAGE_SIZE, 0); + if (retval) + pr_warn("pid=%d, couldn't seal address 0, ret=%d.\n", + task_pid_nr(current), retval); } regs = current_pt_regs(); diff --git a/include/linux/mm.h b/include/linux/mm.h index XXXXXXX..XXXXXXX 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -XXX,XX +XXX,XX @@ void vma_pgtable_walk_end(struct vm_area_struct *vma); int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *size); +#ifdef CONFIG_64BIT +int do_mseal(unsigned long start, size_t len_in, unsigned long flags); +#else +static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags) +{ + /* noop on 32 bit */ + return 0; +} +#endif + #endif /* _LINUX_MM_H */ diff --git a/mm/mseal.c b/mm/mseal.c index XXXXXXX..XXXXXXX 100644 --- a/mm/mseal.c +++ b/mm/mseal.c @@ -XXX,XX +XXX,XX @@ static int apply_mm_seal(unsigned long start, unsigned long end) * * unseal() is not supported. */ -static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) +int do_mseal(unsigned long start, size_t len_in, unsigned long flags) { size_t len; int ret = 0; -- 2.46.0.rc2.264.g509ed76dc8-goog