Re: [PATCH v2 3/5] memfd: improve userspace warnings for missing exec-related flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-09-05, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
> * Andrew Morton:
> 
> > OK, thanks, I'll revert this.  Spamming everyone even harder isn't a
> > good way to get developers to fix their stuff.
> 
> Is this really buggy userspace?  Are future kernels going to require
> some of these flags?
> 
> That's going to break lots of applications which use memfd_create to
> enable run-time code generation on locked-down systems because it looked
> like a stable interface (“don't break userspace” and all that).

There is no userspace breakage with the current behaviour and obviously
actually requiring these flags to be passed by default would be a pretty
clear userspace breakage and would never be merged.

The original intention (as far as I can tell -- the logging behaviour
came from the original patchset) was to try to incentivise userspace to
start passing the flags so that if distributions decide to set
vm.memfd_noexec=1 as a default setting you won't end up with programs
that _need_ executable memfds (such as container runtimes) crashing
unexpectedly. I also suspect there was an aspect of "well, userspace
*should* be passing these flags after we've introduced them".

I'm sending a patch to just remove this part of the logging because I
don't think it makes sense if you can't rate-limit it sanely, and
there's probably an argument to be made that it doesn't make sense at
all (at least for the default vm.memfd_noexec=0 setting).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux