linux-kernel - Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE

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] [day] [month] [year] [list]

Message-ID: <CABi2SkWE6dguS24oSoycB1z0dCNS1iqW=ftv56Vpm4EtaMTX9A@mail.gmail.com>
Date: Tue, 14 Jan 2025 15:56:42 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Isaac Manjarres <isaacmanjarres@...gle.com>
Cc: Kees Cook <kees@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Jann Horn <jannh@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Jeff Layton <jlayton@...nel.org>, Chuck Lever <chuck.lever@...cle.com>, 
	Alexander Aring <alex.aring@...il.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>, kernel-team@...roid.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	Suren Baghdasaryan <surenb@...gle.com>, Kalesh Singh <kaleshsingh@...gle.com>, 
	John Stultz <jstultz@...gle.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC
 to memfd

On Tue, Jan 14, 2025 at 3:41 PM Jeff Xu <jeffxu@...omium.org> wrote:
>
> On Tue, Jan 14, 2025 at 2:42 PM Isaac Manjarres
> <isaacmanjarres@...gle.com> wrote:
> >
> > On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote:
> > > On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
>
> > Alternatively, MFD_NOEXEC_SEAL could be extended
> > to prevent executable mappings, and MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED
> > could be enabled, but that type of system would prevent memfd buffers
> > from being used for execution for legitimate usecases (e.g. JIT), which
> > may not be desirable.
> >
> The JIT case doesn't use execve(memfd), right ?
>
That might not be important.

I also think selinux policy will be a better option for this, There is
a pending work item to restrict/enforce MFD_NOEXEC_SEAL on
memfd_create().


>
>
> > --Isaac