We carry our own definitions in missing_mman.h, and otherwise
sys/mman.h is employed. Let's drop the unneeded detection/inclusion
of linux/memfd.h hence.
This is just like memfd_new(), but allows fine grained control of the
sealing flags.
This switches over all uses of memfd_new() where we actually want
sealing to use memfd_new_full().
This then allows use to use memfd_new() for two further calls, where we
previously used the more lowlevel memfd_create_wrapper().
Let's use pwrite() to write the contents of the memfd. This has the
benefit of not moving the file offset, which means we don't have to
reset it after at all.
Let's drop support systems lacking memfds, i.e. pre kernel 3.17 systems.
This allows us to drastically simplify the "data fd" concept, so far
that we can remove it entirely.
This replaces acquire_data_fd() with a specialized call to
memfd_new_and_seal(), not that memfds can be the only implementation of
the concept.
Private mappings are required when F_SEAL_WRITE is set on a memfd,
because otherwise you could end up with writable mappings through
mprotect() and other calls. This is a limitation of the kernel
implementation, and might be lifted by future extensions.
Regardless, the current code tests for the full `is_sealed()` before
using MAP_PRIVATE. This might end up using MAP_SHARED for write-sealed
memfds, which will be refused by the kernel.
Fix this and make memfd_map() check for exactly `F_SEAL_WRITE`.
Rather than always setting all seals, make `memfd_set_seals()` employ
the original set of seals, that is: SEAL+GROW+SHRINK+WRITE
Historically, the memfd code was used with the out-of-tree memfd
patches, which merely supported a single seal ("SEALED", which
effectively was GROW+SHRINK+WRITE). When the code was adapted to the
upstream memfd seals, it was extended to the full seal set. With more
and more seals being added upstream, this because more problematic. In
particular, it is unclear what the function really is meant to achieve.
Instead of just adding all seals, the function is returned to its
original purpose: seal the memfd so futher modifications to its content
are prevented.
With `F_SEAL_SEAL` a memfd can disable further sealing operations,
effectively sealing the set of seals. Testing for it ensures that no
further seals can be added, it never prevents seals from being dropped,
since seals cannot be dropped, ever.
Now testing for `F_SEAL_SEAL` makes sense if you want to ensure that
some seals are *not* set. That is, you either test for the entire set of
seals to match a local set, or you verify that a specific seal is not
set. Neither is what we are doing, so it feels wrong requiring it to be
set.
By dropping the requirement for `F_SEAL_SEAL`, the same FD can be shared
with other entities while retaining the ability to further restrict the
set of seals later on (e.g., being able to mark a region as executable
later on, and then adding `F_SEAL_EXEC`).
Use the flags MEMFD_EXEC or MEMFD_NOEXEC_SEAL as applicable.
These warnings instruct the kernel wether the memfd is executable or
not.
Without specifying those flags the kernel will emit the following
warning since version 6.3,
commit 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC"):
kernel: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1 'systemd'
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
This is similar to TAKE_PTR() but operates on file descriptors, and thus
assigns -1 to the fd parameter after returning it.
Removes 60 lines from our codebase. Pretty good too I think.
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
Yu Watanabe
Mike Yuan
Lennart Poettering
David Rheinsberg
Thomas Weißschuh
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Daniel Mack
Thomas Hindoe Paaboel Andersen
Kay Sievers