[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202408051400.C402BE97E@keescook>
Date: Mon, 5 Aug 2024 14:01:44 -0700
From: Kees Cook <kees@...nel.org>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, jannh@...gle.com, sroettger@...gle.com,
adhemerval.zanella@...aro.org, ojeda@...nel.org,
adobriyan@...il.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, jorgelo@...omium.org
Subject: Re: [RFC PATCH v1 0/1] binfmt_elf: seal address zero
On Thu, Aug 01, 2024 at 05:08:32PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.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
Powered by blists - more mailing lists