Lennart Poettering
845707aae2
This adds support for the EFI stub to look for credential files and sysext files next to the EFI kernel image being loaded, and pack them up in an initrd cpio image, and pass them to the kernel. Specifically, for a kernel image foo.efi it looks for foo.efi.extra.d/*.cred and packs these files up in an initrd, placing it inside a directory /.extra/credentials/. It then looks for foo.efi.extra.d/*.raw and pack these files up in an initrd, placing them inside a directory /.extra/sysexts/. It then concatenates any other initrd with these two initrds, so they are combined. Or in other words auxiliary files placed next to the kernel image are picked up automatically by the EFI stub and be made available in the initrd in the /.extra/ directory. What's the usecase for this? This is supposed to be useful in context of implementing fully trusted initrds, i.e. initrds that are not built locally on the system and unsigned/unmeasured – as we do things currently —, but instead are built by the vendor, and measured to TPM. The idea is that a basic initrd is always linked into the kernel EFI image anyway. This will already be sufficient for many cases. However, in some cases it is necessary to parameterize initrds, or to extend the basic initrds with additional subsystems (e.g. think complex storage, or passing server info/certificates/… to initrds). The idea is that the parameterization is done using the "credentials" logic we already have in systemd, with these credential files (which can optionally be encrypted+authenticated by TPM2) being placed in the ESP next to the kernel image. And the initrd extension via the "sysext" logic we already have in systemd too. Note that the files read by this code are not verified immediately, they are copied *as-is* and placed into /.extra/ in the initrd. In a trusted environment they need to be validated later, but before first use. For the credentials logic this should be done via the TPM2 encryption/authentication logic. For the sysext stuff the idea is that this is done via signed images, as implemented by #20691.
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.