-
Any examples of hardware supply chain attacks that are backed by evidence to this point have been targeted to individuals or entities under surveillance (I’m referring to things revealed in Snowden disclosures, so far the Bloomberg implant stories don’t seem to be backed by physical evidence, but hearsay). Performing hardware supply chain attacks across an entire product line is certainly possible but also unlikely, due to the larger threat of being discovered. These same well-resourced entities that would be able to do such a thing, also are intelligent enough to know that the far safer way to achieve the same goal as a hardware implant, is through software implants, as they are much easier to explain away as a mistaken debug mode left into firmware. There are also plenty of examples in the wild of this exact type of backdoor, compared to hardware implants. I talk more about that here.
-
We try to reduce the amount of proprietary code in our products to a minimum, however there are still some blobs left in PureBoot including CPU microcode updates (although we’ve been able to reduce the number of blobs over time with a goal to reduce it to zero). We supply a firmware update tool that provides you with the latest version of either PureBoot or coreboot depending on what you use.
-
Yes Heads is specifically designed to alert you to that kind of tampering. That would make it safer to dual boot Qubes with something else but it’s still not ideal because you would be relying on the strength of your LUKS password protecting dom0 at that point (as a remote attacker who could compromise your other OS could start attempting to attack your encrypted Qubes file system, even if their attempts to attack the kernel in /boot would be detected).
-
So far anything along those lines (that I’m aware of) is in the realm of the hypothetical without a functional proof of concept.
-
If you do choose to dual boot (which I don’t recommend if you use Qubes) you would end up sharing the /boot partition between Qubes and PureOS. Ideally if you do it correctly, GRUB updates on either end would do the “right thing” when you get new kernels. I’ve done such a thing in the past based on a guide Micah Lee has published, but if you are concerned about the complexity of Qubes, maintaining a dual boot situation in my opinion would add to that complexity.
-
If you were to use something other than PureOS, which had proprietary drivers, you might see it attempt to inject CPU microcode updates, which other OSes ship with. You may also see proprietary modules in place to extend the Intel graphics driver, and might see proprietary drivers that enable the Bluetooth device on the WiFi card.
-
The problem with proprietary code is that you can’t see inside it to answer that question. So it’s all hypothetical conjecture. The best you can do is try to compartmentalize and reduce proprietary code as much as possible (ultimately to zero), which has been our approach.
4 Likes