Linux is stupid and sometimes returns a "struct sockaddr_un" that is
longer than its fields, as it NUL terminates .sun_path[] even if it has
full length. ubsan detects this, rightfully. Since this is a Linux
misdesign let's trick out ubsan a bit.
Fixes: #11024
We want it for global variables, which LLVM supports and GCC currently
does not (GCC does support it for functions, but we care about global
variables here).
Why is this relevant? When asan is used global variables are padded with
hotzones before and after. But we can't have that for the registration
variables we place in special ELF sections: we want them tightly packed
so that we can iterate through them.
Note that for gcc this isn't an issue, as it will pack stuff in
non-standard sections anyway, even if asan is used.
This cleans up a bit how we set up things for the ELF section magic:
1. Let's always use our gcc macros, instead of __attribute__ directly
2. Align our structures to sizeof(void*), i.e. the pointer size, rather
than a fixed 8 or __BIGGEST_ALIGNMENT__. The former is unnecessarily
high for 32bit systems, the latter too high for 64bit systems. gcc
seems to use ptr alignment for static variables itself, hence this
should be good enough for us too. Moreover, the Linux kernel also
uses pointer alginment for all its ELF section registration magic,
hence this should be good enough for us too.
3. Let's always prefix the sections we create ourself with SYSTEMD_,
just to make clear where they come from.
4. Always align the pointer we start from when iterating through these
lists. This should be unnecessary, but makes things nicely
systematic, as we'll align all pointers we use to access these
sections properly.
We follow no general rule, but in most cases we do not place a space
outside of macro.h. Hence let's stick to that, and adapt macro.h too,
and follow the rule systematically that there shall not be a space
between __attribute__ and ((...
Yes, this does not matter at all, and is purely OCD cosmetics. But then
again, the uses of __attribute__ are very local only, hence the changes
cleaning this up are small and are unlikely to have to be repeated too
often...
This splits out a bunch of functions from fileio.c that have to do with
temporary files. Simply to make the header files a bit shorter, and to
group things more nicely.
No code changes, just some rearranging of source files.
Whenever we invoke external, foreign code from code that has
RLIMIT_NOFILE's soft limit bumped to high values, revert it to 1024
first. This is a safety precaution for compatibility with programs using
select() which cannot operate with fds > 1024.
This commit adds the call to rlimit_nofile_safe() to all invocations of
exec{v,ve,l}() and friends that either are in code that we know runs
with RLIMIT_NOFILE bumped up (which is PID 1 and all journal code for
starters) or that is part of shared code that might end up there.
The calls are placed as early as we can in processes invoking a flavour
of execve(), but after the last time we do fd manipulations, so that we
can still take benefit of the high fd limits for that.
This is really basic stuff and in a follow-up commit will use it all
across the codebase, including in process-util.[ch] which is in
src/basic/. Hence let's move it back to src/basic/ itself.
Yu Watanabe
Lennart Poettering
Evgeny Vereshchagin