linux-kernel - Re: [RFC PATCH v1 1/1] binfmt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202408051402.9C0FA18A12@keescook>
Date: Mon, 5 Aug 2024 14:05:06 -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 1/1] binfmt_elf: mseal address zero

On Thu, Aug 01, 2024 at 05:08:33PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.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@...omium.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 19fa49cd9907..e4d35d6f5d65 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1314,6 +1314,10 @@ 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

Instead of wrapping this in #ifdefs, does it make more sense to adjust
the mm.h declaration instead, like this below...

>  	}
>  
>  	regs = current_pt_regs();
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index c4b238a20b76..b5fed60ddcd9 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4201,4 +4201,8 @@ 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)
{
	return -ENOTSUPP;
}

> +#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.rc1.232.g9752f9e123-goog
> 

And if it returns an error code, should we check it when used in
load_elf_binary()? (And if so, should the mm.h return 0 for non-64bit?)

-- 
Kees Cook