specs/UKI: Is empty initrd allowed? #74
Comments
|
sdmagic is specific to systemd tools, but a few times we talked about having an identifier section that is generalized. Perhaps .sbat should be used, as after all the point of that section is identifying a binary. On initrd I don't think it is allowed by the tools that load UKIs - ukify probably allows it just because we also build addons, but maybe we should tighten it. You can't boot without an initrd, so I don't know if it would make sense to allow not having one. |
|
This should not be generalized in any spec I'd say. Or if we'd generalize it then cetrainly not under this name |
|
The nix people would like to move the initrd into one of these "PE add-ons" we now support, and have the UKI without an initrd, but combined on boot with one of those add-ons. If we want to cover for that we might want to say "initrd is optional, but must then supplied from somewhere else in a trusted way", or so. |
As mentioned in the PR and at the conf, I think we should make that part of BLS type 1, rather than the UKI spec. IE: 'secure type 1' rather than 'disunified unified kernel image'. The nix folks are ok with this approach too. |
You can boot without an initrd (depending on hardware and builtin modules), that's why I think this should be possible. I have to test what the behavior is right now for the case of an empty initrd section though. Just like cmdline there would of course be the question of no initrd section vs empty initrd section. |
From the kernels perspective it would be nice to have some type of identifier for UKIs. The kernel runs the image passed to kexec through a probe function for all possible file types to determine which one it is. For UKI right now I'm just checking if it's a pe file and that it includes a .linux and .initrd section (could possible also call the bzimage probe function on the .linux section additionally). But it would be even better to have some magic string in a section. I think this would be best practice. |
That seems like a very weird corner case, what can you even do with just a kernel? On a production system? UKIs are aimed at full systems |
We need an identifier yes, and we also need shim to measure these payloads in the high PCRs that sd-stub uses so that we can't be cheated by a different payload pretending to be a UKI. I think we should use the .sbat section for this. It already includes identifiers (that's its practical purpose), and shim already knows how to parse it, so it should be uncontroversial to measure one of its fields - win/win. |
|
Did that linux upstream sbat section get merged? So in this case a UKI is identified by an sbat section containing at least the components linux and systemd? I guess that could work, but the kernel doesn't really care about the sd-stub in the UKI. So from the kernels perspective it should be fine to load a UKI that contains another stub implementation (or maybe no stub at all). In that case the sbat section would include the linux component and that other stub's name. So this is problematic for a magic value. I'm more looking for some static data that uniquely identifies the file as a UKI that promises to follow the UKI spec. Something like a .uki section containing a static string.
What kind of attack are you thinking of here? Are you talking about the trust for PCR 11 and higher basically starting with sd-stub? I guess a UKI with an altered stub could just fake-measure the expected PCR values. The binary loaded by sd-boot (which is the UKI) does end up in PCR 4 though, right? So -> systemd-pcrlock (need to look more into that)? How would the shim know which UKI we will load if there are multiple on the ESP? sd-boot is in a better position. What exactly are you proposing for shim to measure? The .sbat section or the payloads in the UKI (.linux, .initrd)? |
People requested clarification as to what sections are "required" in a UKI. Say that if .linux is present, it's a UKI. This is intentionally vague: depending on the use of the UKI, some other sections will almost always be present, but also depending on the intended use, those might be different sections. So let's keep the specification simple and only define the minimum necessary. When we have a proper specificiation for addons, we shall link it here. (Or maybe we'll add it here?) Closes uapi-group#74.
People requested clarification as to what sections are "required" in a UKI. Say that if .linux is present, it's a UKI. This is intentionally vague: depending on the use of the UKI, some other sections will almost always be present, but also depending on the intended use, those might be different sections. So let's keep the specification simple and only define the minimum necessary. When we have a proper specificiation for addons, we shall link it here. (Or maybe we'll add it here?) Closes uapi-group#74.
Similar to #72
At least ukify allows no initrd, so is that allowed? I guess it should be. In that case I gotta change that in the kernel patch.
Also is the .sdmagic section required? It's not mentioned in the spec.
@bluca
@poettering
The text was updated successfully, but these errors were encountered: