request command line tool to generate usb boot hashes

[loftlifter31]

Is your feature request related to a problem? Please describe.
Heads provides the option to require signed boot hashes when booting from USB. However it is left to the user to make all the hashes which are then to be signed with the kexec-sign-hashes utility.

Describe the solution you'd like
Making the boot hashes is too complex. If it was only a matter of sha256sum /boot/* > kexec_hashes.txt then there would be no problem, but heads complains about missing tpm primary.handle, missing kexec_tree.txt and there is also no rollback counter. Trying to figure out how exactly to format each of the different hashes heads expects to see for signed boot is difficult. It would be nice if there was a simple tool kexec-generate-hashes for example that could generate the hashes in just the format heads wants to verify them in rather than require the user to figure out the formats and files. Heads already generates the hashes for the primary boot device so it seems it would be fairly easy to reuse the code to make a tool for the user to do the same for a usb.

Describe alternatives you've considered
Trial and error of trying to manually create all the hash files using source code as reference.

[tlaurion]

Heads is not meant today to booted from usb as a hard drive, today. This issue, if named correctly, could try to tackle what wouldbe missing to go in that direction. Today, USB boot is permitted to jump in live OS, ie Tails or live ISO, where detach signing that ISO if not provided by Distro can be detached signed with commands exposed under https://osresearch.net/InstallingOS/#generic-os-installation

---

But I think you try this the wrong way around. If you would want USB drive bootable as for nvme/sdd/hdd today, the "easier" way would be to have Heads support usb controllers as when doing mount-usb, but early loaded with config switch accepting USB risks of being loaded early, and scripts not neglect usb drives as bootable as currently today per codebase, excluding usb drives for everything being boot related last time I checked. Or remove TPM primary handle from /boot and hotp counter so that usb boot could be done without requiring states linked to remote attestation being stored under /boot.

Once TPM primary handle+hotp counter not under /boot, or USB controllers and codebase made to not deglect usb drives and permit setting USB drive as default /boot is done, then USB drives could be configured to be the "default" boot drive. But no dual boot here unless hotp counter and tpm2 primary handle becoming stateless, ie not writing anything under /boot.

Note that tpm2 primary handle is another issue, and as long as primary handle and hotp counter are stored under /boot, Heads can't dual boot. As of today, oem-factory-reset and other helpers will detect boot drive if not usb, and permit to set that boot device to have /boot mounted under /boot in init.

If that was done, and user could config settings -> enable usb boot from disk, then Heads would default boot from USB, not making the difference between ssd/nvme/hdd and have everything /boot related for what is expected be be verified to permit default boot all in sync and boot from usb defined /boot partition, considering the OS is doing the right thing here at installation as well.

Makes sense? Or are you attemtping a dual boot without TPM primary handle being on usb drive but still on /boot mounted?

TLDR

• dual boot is not supported right now
• usb boot is supported for ISO as of now, but not for HDD usb boot
• TPM2 primary handle needs to be on default boot /boot mounted partition from init
• HOTP counter still stored under /boot

[loftlifter31]

I don't think I understand what you are saying here. I currently have default boot set to internal hdd. I sometimes need to boot a different OS installed on a USB. Not live cd iso but a full linux install on the USB drive.

[tlaurion]

I don't think I understand what you are saying here. I currently have default boot set to internal hdd. I sometimes need to boot a different OS installed on a USB. Not live cd iso but a full linux install on the USB drive.

Would you be OK booting it without any integrity check at all outside of primary handle still being In main drive /boot, hotp rollback under main drive /boot?

If so, that might be possible to boot usb drive as secondary usb drive without any integrity check whatsoever, just like "unsafe boot" option today, but for usb.

Otherwise, same explanation as before. Please point what you didn't understand and quote for clarifications.

[tlaurion]

Interesting hack talked about at vpub today
https://git.distrust.co/public/airgap/src/commit/767044dfd9987f47a51706efb90b8e53a64a38b3/config/heads/patches/usb-boot.patch

[loftlifter31]

But I think you try this the wrong way around. If you would want USB drive bootable as for nvme/sdd/hdd today, the "easier" way would be to have Heads support usb controllers as when doing mount-usb

Why is this the wrong way around? Doesn't heads already support booting from usb? I can boot from a usb drive just fine now. I just can't do so securely by checking hashes.

But no dual boot here unless hotp counter and tpm2 primary handle becoming stateless, ie not writing anything under /boot.

Does that mean the tpm handle and counter only support a single boot drive? Is that why multiboot won't work? Couldn't there be more than one tpm handle and hotp counter? One for each signed boot drive? Or could heads boot from a usb drive that has no tpm handle or hotp counter and only verify the signed hashes?

If so, that might be possible to boot usb drive as secondary usb drive without any integrity check whatsoever, just like "unsafe boot" option today, but for usb.

It sounds like that is what I'm doing now. I have set CONFIG_BOOT_REQ_HASH=n I select boot from usb and then select the partition I want to boot from. There are no hashes to be verified because when I try to create hashes heads fails to verify them and then won't boot.

[tlaurion]

@JonathonHall-Purism fyi

[tlaurion]

But I think you try this the wrong way around. If you would want USB drive bootable as for nvme/sdd/hdd today, the "easier" way would be to have Heads support usb controllers as when doing mount-usb

Why is this the wrong way around? Doesn't heads already support booting from usb? I can boot from a usb drive just fine now. I just can't do so securely by checking hashes.

Code support booting from ISO from usb, or raw ISO (dd). if you want to check code, put Heads in debug mode which will show tracing. usb-init is called, which deals with ISO. no multiboot because tpm primary handle and hotp counter store under /boot.

But no dual boot here unless hotp counter and tpm2 primary handle becoming stateless, ie not writing anything under /boot.

Does that mean the tpm handle and counter only support a single boot drive? Is that why multiboot won't work? Couldn't there be more than one tpm handle and hotp counter? One for each signed boot drive? Or could heads boot from a usb drive that has no tpm handle or hotp counter and only verify the signed hashes?

Not trivially. Hence why multiboot not supported. You can refer to issues about hotp counter eradication and discussion about tpm2 primary handle eradication.

If so, that might be possible to boot usb drive as secondary usb drive without any integrity check whatsoever, just like "unsafe boot" option today, but for usb.

Discussion today under matrix channel

It sounds like that is what I'm doing now. I have set CONFIG_BOOT_REQ_HASH=n I select boot from usb and then select the partition I want to boot from. There are no hashes to be verified because when I try to create hashes heads fails to verify them and then won't boot.

Exactly.