-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add CPIO packing for companion files #168
Conversation
In what situation do we have to create initrds? You only mentioned appending them and cpios can be appended without repacking them. |
Companion files are not initrd, they are just random files laying around on the ESP. Therefore, to make them available in your initrd phase, you need to pack them as CPIOs and merge them with the others initrds, hence the need for a CPIO packing phase. (They are not CPIO on their own at the start, otherwise, it would be cumbersome to manipulate from userspace.) |
ac5df5d
to
f7c720d
Compare
f7c720d
to
1180fd3
Compare
@nikstur I think this CPIO stuff is the good opportunity to introduce our "library crate" for UEFI bootloaders stuff. |
rust/stub/src/cpio.rs
Outdated
|
||
/// Compute the necessary padding based on the provided length | ||
/// It returns None if no padding is necessary. | ||
fn compute_pad4(len: usize) -> Option<Vec<u8>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be easier to handle if it returns a zero-length vector when zero padding is required. This makes the calling code easier because it removes case distinctions.
rust/stub/src/cpio.rs
Outdated
} | ||
|
||
impl Cpio { | ||
fn pack_one(&mut self, fname: &CStr16, contents: &[u8], target_dir_prefix: &str, access_mode: u32) -> uefi::Result |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From an architectural point, it would be great to separate the CPIO writing from any UEFI stuff. So we could split this file into one module that does only CPIO construction in memory (without using any UEFI types) and another module that adds whatever UEFI magic is required.
89ce47b
to
6ac63ff
Compare
e9ec7a0
to
9ca2548
Compare
I decided to be serious about the problem space, so here's my strategy.
|
36df0d4
to
a60c471
Compare
It is now enclosed in its own subdirectory, but full of `expect`.
It is now possible to discover credentials and systemd extensions and pack them as CPIOs.
With this feature, it is now possible to load dynamic initrds (possibly read from filesystem or generated on the fly) and extend existing initrds. This feature will be useful to implement addons in the future.
6bfad96
to
97df618
Compare
@blitz @nikstur I would appreciate a review on the credentials part, I'm not sure yet what I want to do about local credentials vs. global credentials. I feel like you can always use global credentials and local credentials are almost always useless with lanzaboote except if you use the fat UKIs model? So I suggest removing the code for them from the tool, as it does not make a lot of sense. For sysexts, I will add more stuff soonish to test them properly. |
This is better to perform integration testing and separate the cost of ownership / maintenance.
For dynamic usecases, e.g. credentials or system extension images, we have a need for dynamic merging of initrds.
97df618
to
3766712
Compare
Note for reviewers: I will work to remove the fork dependency in this PR. |
Actually, I'm thinking, but I don't think systemd-sysext makes a lot of sense, just merging in |
Now, lzbt can install global credentials directories passed inside the ESP and manage the lifecycle of it in a basic fashion.
As soon as we open in exclusive our own image, we will not be able easily to re-open it because of the locking mechanism. Therefore, we should use the opportunity to get information we may be interested in and avoid us re-opening the loaded image protocol. This is useful to know from where you were loaded for example, e.g. filesystem path.
Now the lanzaboote module can understand passed list of credentials, either global or local and pass them to `lzbt` CLI.
Create a simple test to evaluate credentials mechanism with lanzaboote that does not even make use of TPM2 and just copy garbage around.
…ls and sysexts now systemd just has to pick them up!
And offer a way to debug CPIO representations just with your eyes, Here's a useful snippet to transform that representation into a proper binary CPIO using Python: >>> raw = "<insert the string representation with the proper escaping>" >>> open("/tmp/cpio", "wb").write(bytes(raw.replace("\\x00", "\x00"), "ascii")) Then, you can poke the cpio using `cpio -t < /tmp/cpio` or extract it and `cpio` should complain accordingly.
Until I rebase my changes and push it upstream properly.
Now, systemd is fixed, we can use credentials.
Those are leftovers that didn't fuse correctly with my past commits.
3766712
to
cf5887c
Compare
I think the separate CPIO module goes in the right direction, but it would make sense to split it off into a separate PR for reviewing. |
Also split. |
Depended on #167 #166.This adds CPIO packing and open credentials and systemd extensions discovery and load.
With this, we should be able to read from drop-in directories, load CPIO archives and combine them as initrds for sysexts (+ measurements).