I want to use qubes os since it provides compartmentalization to my activities. My one potential threat is firmware attacks performed from the OS userland, for example by trying to rewrite firmware of my computer with malicious payload uploaded throug vulnerable networking software in my userland. I am worried particularly about attacks on BIOS. As far as I know in order to rewrite firmware on Linux systems the attacker has to have root priveleges. I have several questions related to if I should use Heads with Qubes, or see if coreboot alone is enough for my threat model.
- If an attacker desires to overwrite firmware on my device, which files inside my Linux system he would need to target? Are they located in /dev, or /lib/firmware or both?
- Am I right that in order to try to overwrite firmware from inside Qubes OS, it is not enough for attacker to compromise only AppVM? Does he have to move over from compromised AppVM to attack dom0 to access firmware storage?
- It shouldn’t be possible to access dom0 from the Internet because dom0 has no network interfaces, is it right?
- Considering that physical attacks like evil maid are outside of my threat model, should I use Heads at all? I could flash coreboot on my hardware and set up write protection on SPI storage where coreboot and its payload will be located. So attacker wont be able to overwrite firmware programatically at all, of course if there is no vulnerability that can bypass SPI write protection. In such case measured boot provided by Heads is unnecessary.
- In case I choose to go with Heads, I would like to store as little information as possible in TPM because I don’t trust it too much. Can I make Heads store in TPM only that cryptographic information required only for measured boot functionality? particularly I am talkin about PCR values. Can I choose not to place LUKS encryption key inside TPM, so my computer can derive the key on its own from my LUKS password that I give on each boot without using any persistent storage?