[PATCH v2 0/1] binfmt_elf: seal address zero

[PATCH v2 0/1] binfmt_elf: seal address zero

[jeffxu]

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

[PATCH v2 1/1] binfmt_elf: mseal address zero

[jeffxu]

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 19fa49cd9907..f839fa228509 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1314,6 +1314,11 @@ 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 c4b238a20b76..a178c15812eb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -4201,4 +4201,14 @@ 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 bf783bba8ed0..7a40a84569c8 100644
--- a/mm/mseal.c
+++ b/mm/mseal.c
@@ -248,7 +248,7 @@ 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

Re: [PATCH v2 1/1] binfmt_elf: mseal address zero

[Petr Tesařík]

On Tue,  6 Aug 2024 21:49:27 +0000
jeffxu@chromium.org wrote:

> 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 19fa49cd9907..f839fa228509 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1314,6 +1314,11 @@ 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 c4b238a20b76..a178c15812eb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4201,4 +4201,14 @@ 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

Strictly speaking, this should be

#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)

But since we do not support any 64-bit architecture without MMU, I'm
just making this marginal note, so it can be found in ML archives if
needed.

Petr T

Re: [PATCH v2 1/1] binfmt_elf: mseal address zero

[Jeff Xu]

On Wed, Dec 4, 2024 at 10:04 AM Petr Tesařík <petr@tesarici.cz> wrote:
>
> On Tue,  6 Aug 2024 21:49:27 +0000
> jeffxu@chromium.org wrote:
>
> > 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 19fa49cd9907..f839fa228509 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -1314,6 +1314,11 @@ 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 c4b238a20b76..a178c15812eb 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -4201,4 +4201,14 @@ 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
>
> Strictly speaking, this should be
>
> #if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
>
> But since we do not support any 64-bit architecture without MMU, I'm
> just making this marginal note, so it can be found in ML archives if
> needed.
>
Noted.

Thanks!

> Petr T

Re: [PATCH v2 0/1] binfmt_elf: seal address zero

[Kees Cook]

On Tue, 06 Aug 2024 21:49:26 +0000, jeffxu@chromium.org wrote:
> 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. */
> 
> [...]

I added the cover letter details to the commit log and changed pr_warn()
to pr_warn_ratelimited(), but otherwise, looked good.

Applied to for-next/execve, thanks!

[1/1] binfmt_elf: mseal address zero
      https://git.kernel.org/kees/c/44f65d900698

Take care,

-- 
Kees Cook

Re: [PATCH v2 0/1] binfmt_elf: seal address zero

[Lorenzo Stoakes]

On Wed, Aug 14, 2024 at 09:59:47AM -0700, Kees Cook wrote:
> On Tue, 06 Aug 2024 21:49:26 +0000, jeffxu@chromium.org wrote:
> > 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. */
> >
> > [...]
>
> I added the cover letter details to the commit log and changed pr_warn()
> to pr_warn_ratelimited(), but otherwise, looked good.
>
> Applied to for-next/execve, thanks!
>
> [1/1] binfmt_elf: mseal address zero
>       https://git.kernel.org/kees/c/44f65d900698
>
> Take care,
>
> --
> Kees Cook
>
>

Hi Kees,

Reproducing diffstat here:

 fs/binfmt_elf.c    |  5 +++++
 include/linux/mm.h | 10 ++++++++++
 mm/mseal.c         |  2 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

It seems that in commit 44f65d9006982 ("binfmt_elf: mseal address zero")
you took a patch that makes changes to mm code without any review/ack from
any mm maintainer.

While I realise this was a small change, in future can you make sure to
ensure you have that?

I know linux-mm was cc'd but clearly it was missed.

Thanks, Lorenzo

Re: [PATCH v2 0/1] binfmt_elf: seal address zero

[Kees Cook]

Sorry for the delay in my reply -- I've been trying to catch up on stuff
after 2 weeks off.

On Tue, Dec 03, 2024 at 02:13:45PM +0000, Lorenzo Stoakes wrote:
> On Wed, Aug 14, 2024 at 09:59:47AM -0700, Kees Cook wrote:
> > On Tue, 06 Aug 2024 21:49:26 +0000, jeffxu@chromium.org wrote:
> > > 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. */
> > >
> > > [...]
> >
> > I added the cover letter details to the commit log and changed pr_warn()
> > to pr_warn_ratelimited(), but otherwise, looked good.
> >
> > Applied to for-next/execve, thanks!
> >
> > [1/1] binfmt_elf: mseal address zero
> >       https://git.kernel.org/kees/c/44f65d900698
> >
> > Take care,
> >
> > --
> > Kees Cook
> >
> >
> 
> Hi Kees,
> 
> Reproducing diffstat here:
> 
>  fs/binfmt_elf.c    |  5 +++++
>  include/linux/mm.h | 10 ++++++++++
>  mm/mseal.c         |  2 +-
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> It seems that in commit 44f65d9006982 ("binfmt_elf: mseal address zero")
> you took a patch that makes changes to mm code without any review/ack from
> any mm maintainer.
> 
> While I realise this was a small change, in future can you make sure to
> ensure you have that?

Oh, yes! I can do that. As you say, it was a very small change and
almost entirely "standard" boilerplate. But sure, I will be poke people
more directly if anything touches mm in the future.

-Kees

-- 
Kees Cook