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]
Date: Thu, 1 Feb 2024 15:11:51 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, keescook@...omium.org, jannh@...gle.com,
	sroettger@...gle.com, willy@...radead.org,
	gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
	usama.anjum@...labora.com, rdunlap@...radead.org, jeffxu@...gle.com,
	jorgelo@...omium.org, groeck@...omium.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org, pedro.falcato@...il.com, dave.hansen@...el.com,
	linux-hardening@...r.kernel.org, deraadt@...nbsd.org
Subject: Re: [PATCH v8 2/4] mseal: add mseal syscall

On Wed, Jan 31, 2024 at 05:50:24PM +0000, jeffxu@...omium.org wrote:
> [PATCH v8 2/4] mseal: add mseal syscall
[...]
> +/*
> + * The PROT_SEAL defines memory sealing in the prot argument of mmap().
> + */
> +#define PROT_SEAL	0x04000000	/* _BITUL(26) */
> +
>  /* 0x01 - 0x03 are defined in linux/mman.h */
>  #define MAP_TYPE	0x0f		/* Mask for type of mapping */
>  #define MAP_FIXED	0x10		/* Interpret addr exactly */
> @@ -33,6 +38,9 @@
>  #define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be
>  					 * uninitialized */
>  
> +/* map is sealable */
> +#define MAP_SEALABLE	0x8000000	/* _BITUL(27) */

IMO this patch is misleading, as it claims to just be adding a new syscall, but
it actually adds three new UAPIs, only one of which is the new syscall.  The
other two new UAPIs are new flags to the mmap syscall.

Based on recent discussions, it seems the usefulness of the new mmap flags has
not yet been established.  Note also that there are only a limited number of
mmap flags remaining, so we should be careful about allocating them.

Therefore, why not start by just adding the mseal syscall, without the new mmap
flags alongside it?

I'll also note that the existing PROT_* flags seem to be conventionally used for
the CPU page protections, as opposed to kernel-specific properties of the VMA
object.  As such, PROT_SEAL feels a bit out of place anyway.  If it's added at
all it perhaps should be a MAP_* flag, not PROT_*.  I'm not sure this aspect has
been properly discussed yet, seeing as the patchset is presented as just adding
sys_mseal().  Some reviewers may not have noticed or considered the new flags.

- Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ