Can Qubes protect user from backdoor, that resides in BIOS firmware and device driver?

[Insurgo]

@newbie

if new hardware become less & less user-ownable, controllable, repairable, & auditable,
then what will be the future for Insurgo, Purism, Coreboot, Heads ?
what a pity if all the hard work become useless.

This was tackled in other forums posts and I won’t reiterate here once more. We collectively need to take a stance on what we accept and don’t, what we need outside the lesser evil of what is available. Search the forum for FSP(Intel)/AGESA(Amd), PSP(Amd)/ME/CSME(Intel) and blobs presence in firmware that exists nowadays and look for UEFI vulnerabilities or look at Low Level PC/Server Attack & Defense Timeline — By @XenoKovah of @DarkMentorLLC

@newbie

how about supply chain attack ?
in your opinion, is it possible that, compromised supply chain,
is able to give us, compromised version of Heads & Qubes,
while we download them, from correct source in the internet ?

This is another tricky question where nothing is totally perfect unless one is totally in control of the supply chain, which is something that doesn’t exist today, unless we go back in time and accept a regression into our user experience and go back to design board and apply concepts like what is brought by projects like precursor. On highly complex systems we daily use like a computer or a smartphone, supply chain attacks can happen at each layer of each component if they are not locked in and tamper evident seals are not apposed/similar idea is not apposed directly at the assembly line, and yet again, who can prevent someone on the assembly line to not swap one component with another without being noticed.

But if you talk about integrity of software, which firmware also is (software is everywhere, even in hardware) then Heads tackles the issue for the hardware it supports in the sense that it can be externally backuped for inspection and parts can be individually reflashed from within as well (A firmware image is an assembly of components, where the BIOS itself is just one region of it, ME is another etc). A little more can be found here on Heads matter: Upgrading Heads | Heads - Wiki

On Qubes+Heads, the recommended installation method is verified detached signed ISO.
To have been misled into downloading a wrong ISO, this would mean interception of HTTPS connection, or compromise of rsynced ISOs across mirrors of Qubes OS, and then having your own Heads installation compromised so that Qubes distribution signing key (which validates integrity+authenticity of ISO.asc/ISO.sig against downloaded ISO just like Qubes documents how to verify signatures. Heads simply automates the process and permits to boot directly from a downloaded iso, only if the iso is accompanied with a proper detached pgp signature (current iso file, current detached signature). Short version: to have Heads install a wrong iso (ISO supply chain issue alone here. Otherwise look into git commit signature for your other question on how to make sure developers working remotely are not having heir work intercepted on untrusted infrastructure, for which github is not trusted), Heads,downloaded iso and downloaded iso.asc would have needed to be compromised for it to be possible. Highly improbable.

But to go back to this thread once more. Can Qubes protect from backdoor in BIOS/devices?

@Insurgo

Qubes should not be able to write to system BIOS nowadays. Simply because writing to BIOS requires IO access that Qubes doesn’t have from qubes (the qubes have really limited access to real hardware) and where dom0 being compromised would also need to have access to SPI IO (that would be iomem=relaxed at the very least) or physical access, which would be more probable otherwise again talking about chain of exploits to gain persistence.

Is my only relevant answer to this thread outside of how Qubes prevents compromise, permits auditability of compromise and recovery. That is on top of a firmware that can be audited and auditable. On top of a reasonably secure computer, that is. You computer has EC controller firmware, which Heads cannot reprogram (Lenovo BIOS updater can), SSD drive firmware. Of course, there is firmware as well into other peripherals in your computer, one of which is recommended to be replaced, which is your wifi card.

I would also second opening other threads then having this one being a mixed pot of everything FUD related, not truly addressing the numerous points you raised.

Qubes implements proper compartmentalization mechanisms for prevention, implements proper auditability base mechanisms and proper recovery bases through the technologies that it relies on. Each of those sub-sub-sub-subjects would deserve individual threads, otherwise this thread is becoming everything and nothing all at once and its pertinence is tending to none.

It goes to mouses moving alone, to housing compromise doubts to network monitoring, now leads to disk forensic, hardware choices, supply chain reality, desires for better, Heads, UEFI, alternatives, past/current/future hardware offering, coreboot terrain losses, Open firmware reality, ME/CSME neutering/deactivation etc. I am interested into those discussions, but I doubt this thread is the place to do so while many others are already existing and more specific to discuss those individually and the ones not existing would be the place to discuss those subjects instead of this thread.