df7ee6f8b0
These aren't wired up yet to do anything useful. For now we just define them. This sections are supposed to carry a signature for expected measurements on PCR 11 if this kernel is booted, in the JSON format "systemd-measure sign" generates, and the public key used for the signature. The idea is to embedd the signature and the public key in unified kernels and making them available to userspace, so that userspace can easily access them and enroll (for which the public key is needed) or unlock (for which the PCR signature is needed) LUKS2 volumes and credentials that are bound to the currently used kernel version stream. Why put these files in PE sections rather than just into simple files in the initrd or into the host fs? The signature cannot be in the initrd, since it is after all covering the initrd, and thus the initrd as input for the calculation cannot carry the result of the calculation. Putting the signature onto the root fs sucks too, since we typically want to unlock the root fs with it, hence it would be inaccessible for it's primary purpose then. The public key could be in the initrd or in the root fs, there's no technical restriction for that. However, I still think it's a good idea to put it in a PE section as well, because this means the piece of code that attaches the signature can also attach the public key easily in one step, which is nice since it allows separating the roles of the kernel/initrd/root fs builder, and the role of the signer, and the former doesn't have to have knowledge about what the latter is going to add to the image. Note that the signature section is excluded from the TPM measurements sd-stub does about its resource sections, since – as mentioned – it's the expected output of the signing operation whose input are the measurements, hence it cannot also be input to them. The public key section is included in the measurements however. |
||
---|---|---|
.clusterfuzzlite | ||
.github | ||
.lgtm/cpp-queries | ||
.semaphore | ||
catalog | ||
coccinelle | ||
docs | ||
factory | ||
hwdb.d | ||
LICENSES | ||
man | ||
mkosi.default.d | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.packit.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson_options.txt | ||
meson.build | ||
mkosi.build | ||
mkosi.postinst | ||
NEWS | ||
README | ||
README.md | ||
TODO |
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.