Skip to content
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

Fedora Silverblue + other immutable Fedora OSes support #6

Open
pepawel opened this issue Oct 12, 2024 · 3 comments
Open

Fedora Silverblue + other immutable Fedora OSes support #6

pepawel opened this issue Oct 12, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@pepawel
Copy link
Collaborator

pepawel commented Oct 12, 2024

Initramfs in Fedora Silverblue misses crypttab file (other Fedora variants need to be examined). A different mechanism is used, therefore custom approach has to be implemented by cryptreboot.

Cryptreboot operates in two stages:

  1. When the OS is fully loaded and the disk is unlocked: cryptreboot parses the crypttab file found inside the initramfs to identify encrypted disks and prompt the user for passphrases for those disks. While it could use /etc/crypttab for this, using the copy within the initramfs is more self-sufficient and better aligned with the standard reboot process.

  2. When the patched initramfs code is executed (early userspace): Previously, cryptreboot injected a modified crypttab file into the initramfs. This modified file contains the disk encryption keys, which allow the disk-unlocking code in the initramfs to run without requiring a passphrase from the user.

In the absence of the crypttab file within the initramfs, it is evident that an alternative disk-unlocking mechanism is in use by the initramfs. There is a need to understand how this mechanism functions to allow cryptreboot to provide it with the disk encryption key, thereby eliminating the need for a passphrase prompt.

@pepawel pepawel added the enhancement New feature or request label Oct 12, 2024
@pepawel
Copy link
Collaborator Author

pepawel commented Oct 12, 2024

Depends on #5

@boredsquirrel
Copy link

boredsquirrel commented Oct 15, 2024

can you explain a bit more? crypttab is in /etc, which is in the encrypted root BTRFS partition with all the rest of the OS.

nvme0n1                                       259:0    0  1,8T  0 disk  
├─nvme0n1p1                                   259:1    0  576M  0 part  /boot/efi
├─nvme0n1p2                                   259:2    0 24,3G  0 part  /boot
└─nvme0n1p3                                   259:3    0  1,8T  0 part  
  └─luks-64ae1755-4591-455d-b723-1e46c31ffe53 253:0    0  1,8T  0 crypt /var/home
                                                                        /var
                                                                        /sysroot/ostree/deploy/fedora/var
                                                                        /usr
                                                                        /etc
                                                                        /
                                                                        /sysroot

the /boot partition is needed for GRUB, OpenSUSE supports GRUB with the /boot/efi partition, something like that. I am not totally sure about that.

You are talking about crypttab being on /boot ?

This could be done on the system, /boot is writable by root. crypttab doesnt change normally, so just copying that would be fine.

There is also bootupd, which will soon be used to update the /boot partition with the contents distributed in the OS image, lying in /usr/lib/ostree-boot/ (on the OSTree images, not sure where that stuff is on the OCI images, which you can rebase to... that stuff is complicated.)

So if having crypttab in the initramfs is kinda standard, and if this is in the /boot partition, then this would need to be integrated into bootupd, to not overwrite it on every rpm-ostree/bootc update, triggering a bootupd update, overwriting the /boot partition with the updated stuff in the OS image.

@pepawel
Copy link
Collaborator Author

pepawel commented Oct 26, 2024

I explained the issue more in the issue description, I hope it is more clear now.

@pepawel pepawel changed the title Fedora Silverblue support Fedora Silverblue + other immutable Fedora OSes support Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants