When Type=notify-reload got introduced, it wasn't intended to be
mutually exclusive with ExecReload=. However, currently ExecReload=
is immediately forked off after the service main process is signaled,
leaving states in between essentially undefined. Given so broken
it is I doubt any sane user is using this setup, hence I took a stab
to rework everything:
1. Extensions are refreshed (unchanged)
2. ExecReload= is forked off without signaling the process
3a. If RELOADING=1 is sent during the ExecReload= invocation,
we'd refrain from signaling the process again, instead
just transition to SERVICE_RELOAD_NOTIFY directly and
wait for READY=1
3b. If not, signal the process after ExecReload= finishes
(from now on the same as Type=notify-reload w/o ExecReload=)
4. To accomodate the use case of performing post-reload tasks,
ExecReloadPost= is introduced which executes after READY=1
The new model greatly simplifies things, as no control processes
will be around in SERVICE_RELOAD_SIGNAL and SERVICE_RELOAD_NOTIFY
states.
See also: https://github.com/systemd/systemd/issues/37515#issuecomment-2891229652
The impl is directly visible to the compiler so it can apply
all sorts of optimizations wherever it sees fit. And with
the previous commit they are actually "const".
This allows a service to reuse the user namespace created for an
existing service, similarly to NetworkNamespacePath=. The configuration
is the initial user namespace (e.g. ID mapping) is preserved.
* 8e2833a5b6 Automatically figure out the name of the top-level tar dir
* dffbf2beba Make sure fallback source is listed first
* 1d3b892105 Enable sysupdate and sysupdated
This is based on the code from #33276, but is cleaned up, and goes for a
modified approach:
the original PR allocated nvindexes fully dynamically, and that created
big headaches, because the assignments needed to be propagated into the
early boot process, and that meant stuffing them as sidecards to the
boot UKIs.
The TCG then offered us a fixed nvindex range assigned to us, and
happily said yes to that, but since then the discussion stalled, we
couldn't get any answer from TCG on this anymore.
This code uses the range that was hinted to us to use, but not
officially assigned to us by default, but makes it build time
configurable so that downstreams can change this.
(This does *not* make it runtime configurable, because that's really
hard, because of the early boot issue again).
This PR comes with a CI test and full docs. And I think this is really a
version should that be merged.
Fixes: https://github.com/systemd/systemd/issues/29877
We'd like to measure various additional things into PCRs, but all
available ones to the OS are already used for various purposes. Hence,
let's introduce a new concept of "NV Index based PCRs", i.e. let's use
TPM2 nv indexes of type TPM2_NT_EXTEND that mostly behave like real
PCRs, but which we can allocate relatively freely from the nv index
space. Let's call these "fake" PCRs "NvPCRs".
My original intention was to get a fixed NV index range assigned from
the TCG, either for Linux or for systemd as a project, but this stalled
with no further updates from the TCG for more than a year and a half
now. I was told an NV index range to use though, even if it never was
officially assigned, hence this PR uses this by default. But the range
is configurable at build time, on purpose, so that downstreams have some
flexibility to change this if they want. To abstract the actual nvindex
number away we introduce a naming concept, so that nvindexes are
referenced by name string rather than number.
NvPCRs are defined in little JSON snippets in /usr/lib/nvpcr/*.nvpcr,
that match up index number and name, as well as pick a hash algorithm.
There's one complication: these nvindex (like any nvindex) can be
deleted by anyone with access to the TPM, and then be recreated. This
could be used to reset the NvPCRs to zero during runtime, which defeats
the whole point of them. Our way out: we measure a secret as first thing
after creation into the NvPCRs. (Or actually, we measure a per-NvPCR
secret we derive from a system secret via an HMAC of the NvPCR name) and
the nvindex handle). This "anchoring" secret is stored in /run/ +
/var/lib/ + ESP/XBOOTLDR (the latter encrypted as credential, locked to
the TPM), to make it available at the whole runtime of the OS.
We can use this to remove any kind of nvindex, hence give it a generic
name.
Also instead of passing "NONE" as session if none is specified, pass
PASSWORD instead, so that the function actually becomes useful if no
session is specified (the only user so far, pcrlock always provides a
session, hence this is no change in behaviour).
We soon want to add the ability to extend into nvindexes in addition to
PCRs, hence rename the function to make clear it is about pcr extension.
While we are at it, switch things over to "struct iovec" as we generally
try to do it now in tpm2-util.[ch] these days.
Make the systemd-pcrlock tool compatible with TCG CEL records that
encode measurements into nvindexes rather than PCRs.
This doesn't add code for actually predicting them, but just makes sure
we can parse them correctly and display them reasonably.
If UINT32_MAX is passed in the PCR masks pick some reasonable defaults
in encrypt_credential_and_warn().
These defaults copy what "systemd-creds encrypt" uses. By adding these
defaults to the internal functions any user of them can take benefit of
them.
This reworkds TPM2 based creds a bit. Instead of mapping the key type
"tpm2" directly to a TPM2 key without PK, let's map it to an "automatic"
key type that either picks PK or doesn't, depending on what's available.
That should make things easier to grok for people, as the nitty gritty
details of PK or not PK are made autmatic. Moreover it gives us more
leverage to change the TPM2 enrollment types later (for example, we
definitely want to start pinning SRK, and hook up pcrlock too, for
creds, which we currently don't).
This hence adds a new _CRED_AUTO_TPM2
pseudo-type we automatically maps to CRED_AES256_GCM_BY_TPM2_HMAC_WITH_PK
or CRED_AES256_GCM_BY_TPM2_HMAC depending if PK as available. Similar,
_CRED_AUTO_HOST_AND_TPM2 is added, which does the same for the
host/nonhost cred type.
This does not introduce any new type on the wire, it just changes how we
select the right key type.
To make the code more readable this also adds some categorization macros
for the keys, instead of repeating the list of key types at multiple
places.
Mike Yuan
Quentin Deslandes
Zbigniew Jędrzejewski-Szmek
jouyouyun
Lennart Poettering