Repart considers the start and end of the usable space to the first multiple
of grainsz (at least 4096 bytes). However the first usable LBA of a GPT
partition is at sector 34 (512 bytes sectors) which is not a multiple of 4096.
The backup GPT label at the end also takes up 33 sectors, meaning the last
usable LBA is at 34 sectors from the end, unlikely to be a 4096 multiple as
well.
This meant that the very first and last sectors were never discarded. However
more problematically if an existing partition started before the first
usable grainsz multiple its start didn't get taken into account as a valid
starting point and got its data discarded.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Just to match service_release_stdio_fd() and service_release_fd_store()
in the name, since they do similar things.
This follows the concept that we "release" resources, and this is all
generically wrapped in "service_release_resources()".
We already clear the various fds we keep from the release_resources()
handler, let's also destroy the runtime dir from there if this
preservation mode is selected.
This makes a minor semantic change: previously we'd keep a runtime
directory around if RuntimeDirectoryPreserve=restart is selected and at
least one JOB_START job was around. With this logic we'll keep it around
a tiny bit longer: as long as any job for the unit is around.
The file descriptors we keep in the fdstore might be basically anything,
let's clean it up with our asynchronous closing feature, to not
deadlock on close().
(Let's also do the same for stdin/stdout/stderr fds, since they might
point to network services these days.)
Now that we have a potentially pinned fdstore let's add a concept for
cleaning it explicitly on user requested. Let's expose this via
"systemctl clean", i.e. the same way as user directories are cleaned.
Oftentimes it is useful to allow the per-service fd store to survive
longer than for a restart. This is useful in various scenarios:
1. An fd to some security relevant object needs to be stashed somewhere,
that should not be cleaned automatically, because the security
enforcement would be dropped then.
2. A user namespace fd should be allocated on first invocation and be
kept around until the user logs out (i.e. systemd --user ends), á la
#16328 (This does not implement what #16318 asks for, but should
solve the use-case discussed there.)
3. There's interest in allow a concept of "userspace reboots" where the
kernel stays running, and userspace is swapped out (i.e. all services
exit, and the rootfs transitioned into a new version of it) while
keeping some select resources pinned, very similar to how we
implement a switch root. Thus it is useful to allow services to exit,
while leaving their fds around till the very end.
This is exposed through a new FileDescriptorStorePreserve= setting that
is closely modelled after RuntimeDirectoryPreserve= (in fact it reused
the same internal type), since we want similar behaviour in the end, and
quite often they probably want to be used together.
Let's normalize how we release service resources, i.e. the three types
of fds we maintain for each service:
1. the fdstore
2. the socket fd for per-connection socket activated services
3. stdin/stdout/stderr
The generic service_release_resources() hook now calls into
service_release_fd_store() + service_close_socket_fd()
service_release_stdio_fd() one after the other, releasing them all for
the generic "release_resources" infra of the unit lifecycle.
We do no longer close the socket fd from service_set_state(), moving
this exclusively into service_release_resources(), so that all fds are
closed the same way.
The per-unit-type release_resources() hook (most prominent use: to
release a service unit's fdstore once a unit is entirely dead and has no
jobs more) was currently invoked as part of unit_check_gc(), whose
primary purpose is to determine if a unit should be GC'ed. This was
always a bit ugly, as release_resources() changes state of the unit,
while unit_check_gc() is otherwise (and was before release_resources()
was added) a "passive" function that just checks for a couple of
conditions.
unit_check_gc() is called at various places, including when we wonder if
we should add a unit to the gc queue, and then again when we take it out
of the gc queue to dtermine whether to really gc it now. The fact that
these checks have side effects so far wasn't too problematic, as the
state changes (primarily: that services would empty their fdstores) were
relatively limited and scope.
A later patch in this series is supposed to extend the service state
engine with a separate state distinct from SERVICE_DEAD that is very
much like it but indicates that the service still has active resources
(specifically the fdstore). For cases like that the releasing of the
fdstore would result in state changes (as we'd then return to a classic
SERVICE_DEAD state). And this is where the fact that the
release_resources() is called as side-effect becomes problematic: it
would mean that unit state changes would instantly propagate to state
changes elsewhere, though we usually want this to be done through the
run queue for coalescing and avoidance of recursion.
Hence, let's clean this up: let's move the release_resources() logic
into a queue of its own, and then enqueue items into it from the general
state change notification handle in unit_notify().
Since da6053d0a7 this is a size_t, not an
unsigned. The difference doesn't matter on LE archs, but it matters on
BE (i.e. s390x), since we'll return entirely nonsensical data.
Let's fix that.
Follow-up-for: da6053d0a7
An embarassing bug introduced in 2018... That made me scratch my head
for way too long, as it made #27135 fail on s390x while it passed
everywhere else.
The verity fec_* parameters allows to use Forward Error Correction to
recover from corruption if hash verification fails.
This adds the options fec_device, fec_offset and fec_roots (sixth
argument) which are the equivalent of the options --fec-device,
--fec-offset and --fec-roots in the veritysetup world.
- fec-device=FILE
- fec-offset=BYTES
- fec-roots=UINT64
See `veritysetup(8)` for more details.
The verity parameter no_superblock allows to format/open an hash device
without the superblock. However, the superblock data must be set to open
the data-device.
This adds the option superblocks (sixth argument) and all the underlying
options which are implied to set the superblock manually if hash device
has no superblock:
- superblock=BOOL
- format=NUMBER (hash version type, 0 for original ChromeOS, 1 for
modern)
- data-block-size=BYTES (max page-size, multiple of 512)
- hash-block-size=BYTES (max page-size, multiple of 512)
- data-blocks=BLOCKS (size of data-device in blocks)
- salt=HEXSTR (salt used at format, max 256 bytes)
- uuid=UUID
- hash=STR (algorithm name for dm-verity used at format, default is
sha256)
See `veritysetup(8)` for more details.
The verity parameter hash_area_offset allows to locate the superblock in
the hash device. It can be used to have a single device which contains
both data and hashes.
This adds the option hash-offset=BYTES (sixth argument) which is the
equivalent of the option --hash-offset in the veritysetup world.
See `veritysetup(8)` for more details.
Correct what appears to be a copy/paste error in config_parse_exec_coredump_filter that is preventing the coredump_filter setting from working correctly.
/bin/login is shipped in util-linux, however, systemd.spec on Fedora has
"Requires: (util-linux-core or util-linux)". If the dependency is
fulfilled just by installation of util-linux-core then users won't be
able to log in into the container after it boots. Let's add util-linux
package to the package list so that /bin/login is always present.
valgrind systemctl is-enabled --root=/ -l default.target >/dev/null
==746041== Memcheck, a memory error detector
==746041== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==746041== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==746041== Command: systemctl is-enabled --root=/ -l default.target
==746041==
==746041==
==746041== HEAP SUMMARY:
==746041== in use at exit: 8,251 bytes in 4 blocks
==746041== total heap usage: 3,440 allocs, 3,436 frees, 1,163,346 bytes allocated
==746041==
==746041== LEAK SUMMARY:
==746041== definitely lost: 24 bytes in 1 blocks
==746041== indirectly lost: 35 bytes in 1 blocks
==746041== possibly lost: 0 bytes in 0 blocks
==746041== still reachable: 8,192 bytes in 2 blocks
==746041== suppressed: 0 bytes in 0 blocks
==746041== Rerun with --leak-check=full to see details of leaked memory
==746041==
==746041== For lists of detected and suppressed errors, rerun with: -s
==746041== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
This also fixes a memory leak in the old code.
valgrind systemctl -t socket --root=/ list-unit-files >/dev/null
==2601899== Memcheck, a memory error detector
==2601899== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2601899== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==2601899== Command: systemctl -t socket --root=/ list-unit-files
==2601899==
==2601899==
==2601899== HEAP SUMMARY:
==2601899== in use at exit: 39,984 bytes in 994 blocks
==2601899== total heap usage: 344,414 allocs, 343,420 frees, 2,001,612,404 bytes allocated
==2601899==
==2601899== LEAK SUMMARY:
==2601899== definitely lost: 7,952 bytes in 497 blocks
==2601899== indirectly lost: 32,032 bytes in 497 blocks
==2601899== possibly lost: 0 bytes in 0 blocks
==2601899== still reachable: 0 bytes in 0 blocks
==2601899== suppressed: 0 bytes in 0 blocks
==2601899== Rerun with --leak-check=full to see details of leaked memory
==2601899==
==2601899== For lists of detected and suppressed errors, rerun with: -s
==2601899== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Let's honour the flag if it is set, just to be safe.
(This only handles the case for the writing side: whenever the client
code hands us a json object with the flag set we'll honour it till the
it's out of reach for us. This does *not* handle the reading side, which
is left for a later patch once needed. We probably should add a
per-connection flag that simply globally enables the sensitive logic for
all messages coming in on a specific varlink conneciton.)
Let's add infrastructure to implement fd passing in varlink, when used
over AF_UNIX.
This will optionally associate one or more fds with a message sent via
varlink and deliver it to the server.
Some minor refactoring. This adds a helper call whose only job is to
unref the JSON object of the currently processed incoming message.
This doesn't make too much sense on its own, given this just replaces
one line by another. However, in a later patch when we'll add fd passing
we'll extend the function to also destroy associated fds, and then it
will start to make more sense.
So far, if we do a synchronous varlink call from the client side via
varlink_call(), we'll
move the returned json object from "v->current" into "v->reply", and
keep it referenced there until the next call. We then return a pointer
to it. This ensures that the json object remains valid between two
varlink_call() invocations.
But the thing is, we don't need a separate field for that, we can just
leave the data in "v->current". This means VARLINK_IDLE_CLIENT state
will be permitted with and without v->current initialized. Initially,
after connection setup it will be set to NULL, but after the first
varlink_call() it will be set to the most recent response, pinning it
into memory.
When running in a container, we can propagate the exit status of
pid1 as usual via the process exit status. This is not possible
when running in a VM. Instead, let's send EXIT_STATUS=%i via the
notify socket if one is configured. The user running the VM can then
pick up the exit status from the notify socket after the VM has shut
down.
Daan De Meyer
OMOJOLA JOSHUA DAMILOLA
Yu Watanabe
Lennart Poettering
Sjoerd Simons
Gaël PORTAY
Franklin Yu
David Schroeder
Michal Sekletar
Mike Yuan
Zbigniew Jędrzejewski-Szmek
David Tardon