Heads/Coreboot General Thread

I know there is a lot of off-topic discussion on this forum, but considering the fact that much of the QubesOS Certified hardware uses both Coreboot and Heads firmware, I think it makes sense to dedicate a thread to these firmware tools.

For example, I recently figured out that my machine was crashing due to an insecure boot. I was booting the machine by ignoring tampering and forcing a boot. This was because the /boot was not being signed
after a QubesOS dom0 update. It actually forced me to create new GPG key and sign the /boot partition
again after the update.

The Insecure Boot Mode kept showing up during the crash only I didn’t recognize it was described here:

Creating GPG Keys

It was difficult to create new GPG keys because the script kept asking me to insert a USB for downloading
the GPG key externally to the USB stick.

This prompt caused the flashing of the GPG key to the ROM to fail because the step was skipped, because
I didn’t want or need to insert a USB and the script just failed as a result.

I had to realize that I needed to skip this external USB step in order to get to the “flash GPG key to ROM”
step. It was the only way to get the key to flash to the ROM and then sign the /boot partition to get a safe boot without the Insecure Boot Mode showing up.

This sounds like a UX issue with Heads…

Feel free to report (PR welcome).

Also, I’ve moved this thread to a more appropriate category as it’s really not a Qubes issue strictly speaking.
Edit: moving it back as I’ve realized that the OP has not reached the necessary trust level yet.

I mean Coreboot/Heads/Qubes are all part of the firmware/software stack right? It would be beneficial
to have documented issues and troubleshooting steps posted to this forum in my view.

There already are a number of topics touching Heads and Coreboot in this forum, so I’ve set a slow-mode for now. If the conversation doesn’t revolve around Qubes OS or duplicates conversations in other threads it will be closed.

1 Like

Not really. Heads and coreboot aren’t developed by the Qubes team.

In this particular case, I found it difficult to figure out which layer of the software stack the problem was located. Also, there is no Heads/Coreboot forum like this.

For this reason, we have a dedicated Category for such discussions, but it’s only available to users with Trust Level 2 or higher, who already contributed to the forum a bit.

In this particular case, I found it difficult to figure out which layer of the software stack the problem was located. Also, there is no Heads/Coreboot forum like this.

I would like to ask general firmware security questions about how coreboot heads firmware integrity can be verified. Coreboot has a whole set of utilities here:

https://doc.coreboot.org/util.html

Has this code been audited? How can we know if its malicious or not?

Also, Heads has its own set of binaries in the /sbin and /bin directories which we
don’t really know the integrity of.

So, none of this is specific to Qubes OS, and as @fsflover wrote above, the category to discuss it is All around qubes.

Until you can participate in that category @janglingquo_575, you should move this conversation to the Heads or Coreboot forums. I’ll close the topic now.

1 Like