How to modify kernel cmdline params on HEADS computer?

User Support
1

UPDATE: See my comment below. There is no issue – it is as easy as editing /etc/default/grub and regenerating the grub config, and then re-signing things when Heads pops up with it’s ZOMG warning.

I recently got a certified laptop with Heads, and everything is great, I’m very happy with it. However, I need help with how to change the [dom0] cmdline parameters used during bootup, because I would like to roughly follow this guide:

LUKS with Yubikey 2FA (chal-resp) on Qubes 4.2.0

and implement requiring both a password and my yubikey to unlock the rootfs, (after having successfully used another separate hardware key for the Heads anti-tampering / change detection).

I have extensive experience with changing boot, using grub, dracut, and Arch’s mkinitcpio, and have had many custom boot setups on other systems, and I understand how to setup the cmdline params and what to do with crypttab and fstab.

However, with this Heads computer, I’m not clear what/where the bootloader even is. By all appearances, it looks like Heads is acting both as the bios firmware and the bootloader. I can see all the Heads files in /boot/, but I am scared to modify anything, because I don’t want to get into a state where I can’t boot. (I have all my qubes backed up – getting in a non-boot state isn’t world ending, just very very annoying.)

My goal is to modify the cmdline params so that I can implement the “require yubikey+password for rootfs luks decryption” outlined in the link above, and sign this new setup with my non-yubikey hardware dingy that does the Heads validation, and have that cmdline change persist across dom0 kernel updates.

The laptop does not appear to have grub installed, although it does have dracut, but the dracut conf is completely empty. (The empty conf may be fine and normal and not indicative that dracut isn’t being used, I don’t know.)

So, TLDR: does anybody have enough knowledge about how Heads works to help me make a change to the bootup kernel cmdline?

1 Like
2

You will likely need this resource:

1 Like
3

So I read through that section, and the ability to make the menu file was nice, but I wanted to have something I didn’t need to manage beyond the normal system update process. I found out I did have grub mkconfig available (duh!) and I was just searching for grub-mkconfig instead of grub2-mkconfig. I still don’t think I actually have grub, but the Heads documentation you linked mentions that Heads looks for and uses the grub config file if it’s present in order to parse out the boot information. So based on that, I just modified the /etc/default/grub file to add a dummy cmdline option, regenerated the grub.cfg, and rebooted, and lo and behold Heads saw it, complained that it had the wrong hash, and I was able to confirm that the cmdline options in grub.cfg were indeed being used – whether by grub or not! I also ran “dracut -f” with no options, and it regenerated the initramfs – and it appears this process is reproduceable with the default options, because Heads did not complain about its hash differing.

Armed with the confidence/knowledge that the grub config and dracut builds were safe to run (i.e. I could still boot after running them…), I proceeded to follow the guide I linked and setup the disk encryption to require the yubikey as well. The only downside is that the ykluks script allows more than just yubikey usb devices… but I know exactly where that script is, and I know that I can change it and rebuild the initramfs with dracut, and still boot (…unless I fuck up changing that script!), so I’m not terribly worried about that since I can fix it. And protecting the disk password from should surfing by requiring the yubikey is definitely a worthwhile trade-off in the meantime.

Anyway, just wanted to update my thread that there was nothing special to do. Editing the cmdline in /etc/default/grub and regenerating the grub config was all I had to do (besides re-signing the new files in Heads afterwards). No issues whatsoever.

1 Like