Support rpm-ostree initramfs --enable-overlay

[cgwalters]

Moving this from ostreedev/ostree#1936 - quoting

For CoreOS we have need for networking in the Initramfs for encrypted disks with Clevis/Tang unlock. The problem, though, is that we cannot reliably assume that the DHCP, as the user may have on-disk networking. In talking with @cgwalters the idea of having a layered Initramfs that provides certain files (such as Network configuration), would help to solve this use case and other others.

Basically we want rpm-ostree initramfs --enable-overlay.

This would also fix fedora-silverblue/issue-tracker#3

[cgwalters]

OK so looking at this, we'd have to basically reimplement parts of dracut that "know" which files from /etc to grab.

And specifically for networking...ugh. A whole lot going on here.

[darkmuggle]

@cgwalters another interesting idea: KARGs? Dracut modules use /etc/cmdline.d for potential defaults. For OCP, setting KARGs could be easier if all the MCO has to do is drop a file, and then its picked up, instead of issuing a rpm-ostree command.

[cgwalters]

Yeah, just requiring users specify kernel args for networking for the tang case would work.

[cgwalters]

OK so this came up again for https://bugzilla.redhat.com/show_bug.cgi?id=1775917 and I realized that anyone who needs this today can do:

rpm-ostree initramfs --enable --arg=-I --arg=/etc/vconsole.conf
to include /etc/vconsole.conf - same for any other config files.

This doesn't scale really well in that one needs to enumerate all config files that one needs, but it's there if needed.

[cgwalters]

Followed up on systemd list: https://lists.freedesktop.org/archives/systemd-devel/2019-November/043754.html

[jlebon]

This will require work in libostree too, since right now it can only handle one initrd key in the BLS configs.

[jlebon]

The FIPS mode use case should also be taken into account when designing this. See: https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/53#note_251907083.

[jlebon]

Ahh OK, so the semantics you were thinking of was that there was a single overlay, and we have a list of /etc files somewhere that we know to bring in? Hmm, feels like we might need more flexibility than that.

Wonder if this shouldn't be a separate command instead, e.g. rpm-ostree initramfs-overlay [add|remove] [/etc/file1] [/etc/file2] ...?

Then rpm-ostree initramfs is solely about regenerating the primary initrd, while initramfs-overlay is just about the overlay. (The former being a more drastic measure than the latter. I guess this is parallel with how we split layering packages from base overrides too.)

[jlebon]

(The former being a more drastic measure than the latter. I guess this is parallel with how we split layering packages from base overrides too.)

Although, testing now it seems like overlaid initrds will happily shadow base content. So it's not exactly the same situation (though... even layered packages can still change base content via scriptlets, so maybe it is still apt).

[jlebon]

Cross-referencing: dracutdevs/dracut#792

One thing I wanted to follow up with @cgwalters here that was mentioned there:

Well I was pushing back against using initramfs mutation for this because it conflicts with any approach to signing, it's mixing code and configuration

When you say "initramfs mutation", are you still referring to overlaying a second initrd or rebuilding the initrd? (Though maybe the question is moot since overlaying is still definitely modifying the initrd rootfs in the end).

I'm not familiar with initrd signing, but it sounds interesting. Does that system not have mechanisms for initrds rebuilt on the machine (given that it's the case today for the majority of systems)? If so, we could reuse that for the overlay initrd.

[cgwalters]

When you say "initramfs mutation", are you still referring to overlaying a second initrd or rebuilding the initrd? (Though maybe the question is moot since overlaying is still definitely modifying the initrd rootfs in the end).

Mostly the latter, but even an initramfs overlay is injecting code.

I'm not familiar with initrd signing, but it sounds interesting. Does that system not have mechanisms for initrds rebuilt on the machine (given that it's the case today for the majority of systems)? If so, we could reuse that for the overlay initrd.

Well, there are a few approaches to it. One is actually to concatenate the kernel+initramfs together and sign that whole thing.

And you're right, any system that allows signing can work "client side" too...if you follow the musings in ostreedev/ostree#1959 (and earlier) anything using signing/verity basically either needs to support users doing their own signatures on their privileged code, or not support privileged code at all.

[tunix]

Would this also work for allowing bluetooth at LUKS decryption screen?

[jlebon]

Would this also work for allowing bluetooth at LUKS decryption screen?

For that, I think you'd be better served by rpm-ostree initramfs --enable. And you'll likely also want to add --arg=--add --arg=bluetooth.

[tunix]

Would this also work for allowing bluetooth at LUKS decryption screen?

For that, I think you'd be better served by rpm-ostree initramfs --enable. And you'll likely also want to add --arg=--add --arg=bluetooth.

Unfortunetely that only includes files inside /etc but not /var/lib/bluetooth so you miss the paired device metadata.

[jlebon]

Would this also work for allowing bluetooth at LUKS decryption screen?

For that, I think you'd be better served by rpm-ostree initramfs --enable. And you'll likely also want to add --arg=--add --arg=bluetooth.

Unfortunetely that only includes files inside /etc but not /var/lib/bluetooth so you miss the paired device metadata.

Gotcha. Thanks for bringing this up. We currently don't expose /var to dracut but it could make sense to do so for use cases like this. Can you file a separate issue for this?