Yes, i’m part of Heads development. I’m tlaurion · GitHub
Would it be possible to boot from external DVD? Yes, for some platforms with docking station and/or USB + and compiling + packaging those kernel drivers into initrd so that those could be loaded on demand. That would consume space in the firmware, while i’m not sure this is really needed? If you think so, please open an issue on Issues · linuxboot/heads · GitHub, it was never asked before.
Yes, Heads can currently only “USB boot” from USB drives only. Supporting USB DVD would require SCSI support and other modules to be packed inside of Heads, where booting from signed ISO from a USB thumb drive fits the bill while not requiring to burn a DVD at each new ISO version, which seems to be a better low cost approach. A lot of “things” can be supported by USB, but Heads basically supports USB2/USB3 controllers by default (with USB1 support needing explicit board configuration) through generic drivers, loaded on demand. Then usb-storage when needed to detect block devices on top of USB. Then the kernel sees no difference, abstracting SATA/NVMe/USB drives. But all other USB devices kernel drivers are not compiled in the kernel nor compiled as modules; hence not making the hardware available to Heads. Also, there is no udev or systemd under Heads. The scripts are specifically loading the required drivers when needed, and prior of loading them, measuring them, so that if for some reason an additional driver was loaded, Heads TPM measurements would be different and would not unseal either TOTP/HOTP nor the TPM Disk encryption key to default boot the machine on normal boot.
A GPG detached signature (that .iso.asc/iso.sig in case of USB ISO boot) is basically GPG generating a hash that is then verified against a signed one, that signed one being under .iso.asc/iso.sig. It’s basically done in one pass from gpg --verify against a detached signature. In the case of iso, you can see per the size of the iso.asc/iso.sig that a lot of “blocks” are considered in the detached signature, which is proportional to the size of the content that was detached signed with the release private key on Qubes OS side. So verifying a file (or a digest: which is basically a list of checksums+files), needs to be filled in the same order to be validated through a detached signature. You might want to dig deeper into signatures and detached signatures differences if needed What is the difference between a GPG signature and a detached signature? - Unix & Linux Stack Exchange
Step 4 - Installing Qubes and other OSes | Heads - Wiki gives a complete example of output of what you would have got on screen when Qubes 4.1 iso detached signature verified both integrity and authenticity of the iso file, prior of stating its validity, and then if valid only, propose the boot options of what was found under the grub.cfg file under mounted iso. If the detached signature doesn’t match, ISO boot from USB will simply fail, not permitting to boot from a corrupted/non-authentified ISO file against its detached signature.
In the case you download a ISO that is not providing a detached signature, instructions are provided to generate one yourself, of course after having verified the integrity of the ISO yourself prior of signing it. This way, you can have multiple ISOs side by side, ones being supported by Heads will boot them after having their authenticity/integrity against public keys present in the firmware, and the ones you detached signed yourself against your public key also fused inside of the firmware.
Heads doesn’t pretend to have magic preventing vulnerability exploitation that would only live in memory based on exploitation of its packed tools. Heads verifies that the measured and sealed integrity of the firmware (TOTP/HOTP) is consistent across boots. That is, after an OS is installed. Rubber ducky types of attacks are mitigated on boards not requiring USB Keyboard (usb HID support) on boot, which could go in recovery and back through emulation of keyboard keypresses. Anything that would tamper the firmware (coreboot+Heads payload) will be detected on next boot if TOTP is sealed. TOTP/HOTP unsealing will not work if coreboot measured stages are not consistent to what was sealed when generating a Qr code/pairing HOTP with user’s USB Security dongle.
So, for example, if your USB thumb drive firmware is targeting you, and for whatever reason faking the reading of blocks and made gpg report the detached signature as being valid (that would be amazing), but then your USB thumb drive replaced the ISO file that was validated with a tampered one(also amazing), there is no way Heads could detect this and would do the kexec call to the mounted ISO, passing magic related to the path/GUID of the ISO/other magic depending on the linux distribution at play and tweaks needed to boot its installer (this varies across debian/fedora/archlinux etc).
When one decides to boot from USB, usb-storage kernel module is additionally loaded on demand. The attack surface of USB devices at that point is a combination of a USB thumb drive tampered firmware, the USB controller drivers inside of Heads, the Heads kernel’s filesystem drivers (ext2/ext3/ext4/Jolliet(ISO)/), USB thumb drive filesystem exploited bugs, and busybox from the versions packed under flashed Heads version used. On top of that, if detached signature are validated, we add the gpg toolstack tools packed under Heads.
What I want to put emphasis on here is the following: Heads is a ram based Recovery Shell, executed from a measured boot coreboot, where Heads also measures its modules prior of permitting to unseal an additional TPM Disk encryption key sealed into a separate TPM’s NVRAM memory region, up to the point of booting an OS (USB, Disk). After that, Heads linux kernel’s space is replaced (kexec) with loaded kernel+initrd+xen binaries, and Heads is replaced by the OS booted environment.
An “infected/compromised thumb drive” can mean many things, most of the time containing untrusted files, possibly infected per another OS the USB thumb drive was connected to. Booting from ISO+detached signature is a simple but additional and effective way to make sure that the ISO in question is in the expected state prior of booting from it, but nothing else. It is intended mount the ISO only after having been verified, then having the glue to call expected boot options from there. This means that in the stretched hypothesis that ext2/ext3/ext4/ partition is malformed to trigger a parsing vulnerability of Heads, the kexec call which will boot ISO’ OS’ initrd, which will then remount the ISO would also need to be compromised by that same malformity. Again highly improbable. Having a USB thumb drive firmware hacked in such way that it provides different blocks in case of gpg detached verification then when mounted is also highly improbable. Now, having a USB device exposing many other devices than a storage device will not be permitted by Heads, simply because those others USB drivers are not available.
I cannot think, right now, of a case where an infected/compromise USB thumb drive would infect Heads outside of a possible, while low probability, runtime exploitation that would vanish once Heads boots into the chainloaded OS after the kexec call. As opposed to preparing a USB boot drive, the ISO boot method is considered safer since a single bit corruption of the ISO would be detected prior of booting the ISO. As opposed to a burnded dvd/prepared single installer USB thumb drive, the USB Thumb drive containing the ISO can be untrusted, since the validation is made prior of booting the installation media.
Agreed that there is a small incongruity with the installation process, a chiken/egg problem that lies in the absence of /boot mountable filesystem available for HOTP to drop its /boot/kexec_hotp_counter, which is required under hotp board variants to provide its counter protection (guaranteeing a hotp enabled USB Security dongle can only be used on one device for the moment, and in sync between devices, as opposed to TOTP which counter is inside of the TPM and not requiring an OS to be installed to have firmware measurements sealed prior of OS installation.
Heads currently requires an installed OS to seal firmware measurements through HOTP into the USB Security dongle. This is why, if no OS is detected, Heads will propose to install one. And then, will propose to “OEM Factory Reset/Re-Ownership” on next reboot, when an OS is detected. Being paranoid, you could Upgrading Heads | Heads - Wiki to make sure that the firmware was not tampered by a compromised USB Thumb drive, while again, highly improbable.