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

On Thu, Aug 01, 2024 at 05:08:32PM +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. */
> 
> At one point, Linus suggested removing this [1].

For users, I didn't find much in a Debian Code Search:
https://codesearch.debian.net/search?q=MMAP_PAGE_ZERO&literal=1&perpkg=1

I see rr uses it in testing, and some utils have it as an option, so I
think maybe just leave it supported.

> 
> 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.

Yeah, this seems fine to me.

> 
> [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
> 

-- 
Kees Cook

On Mon, Aug 5, 2024 at 2:01 PM Kees Cook <kees@kernel.org> wrote:
>
> On Thu, Aug 01, 2024 at 05:08:32PM +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. */
> >
> > At one point, Linus suggested removing this [1].
>
> For users, I didn't find much in a Debian Code Search:
> https://codesearch.debian.net/search?q=MMAP_PAGE_ZERO&literal=1&perpkg=1
>
> I see rr uses it in testing, and some utils have it as an option, so I
> think maybe just leave it supported.
>
Thanks for checking, I will add those in the V2 cover letter.

> >
> > 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.
>
> Yeah, this seems fine to me.
>
> >
> > [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
> >
>
> --
> Kees Cook