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

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

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