Went to buy a hard drive cash and at first they didn’t have it and would take two weeks to get. Then I was updated they it was suddenly available in less than 36 hours. There was some other signatures at the location that matched previous signatures before attacks were carried out.
Anyways instead of gaslighting myself, I am curious mainly if I did recieve a modified SSD with malicisious firmware customized for qubes, would it be possible for this to upload my data or allow access to my qubes by an advesary? If so how?
IMHO, not enough information to tell whether it was something nefarious or just a coincidence.
I’m not an expert in this area, but my understanding is that it’s possible for malicious drive firmware to infect dom0 (after which anything is possible). Note that this assumes the drive is an internal storage drive connected directly to dom0 and not some external (e.g., USB) drive. The proposed “storage domain” mitigates this risk, but it has not been implemented yet. You can read more here:
Thank you. This arch spec is beautiful. Is this the latest version? I’ll be pouring over this.
Also any idea when the ‘storage domain’ would be implemented? Is there timeline or somewhere I can see what’s implented and pending according to the envisioned architecture specifications?
Hoping there’s an pending area that aligns with my expertise where I could start to contribute sooner rather than later.
But still curious about ‘storage domain’ and other concepts covered in the arcspec. If there exists somewhere people are either working on them or talking about them, I’d like to read up!
what Jean-Philippe say in Aug 2018 (https://groups.google.com/g/qubes-users/c/qZuNgsPEqw0/m/5dhWAX8iAgAJ )
“currently disks are owned by dom0, and e.g. a malicious nvme device could do arbitrary DMA to compromise dom0 and therefore win. Just because your device has an IOMMU does not mean it is actually in use to protect you from all DMA-related attacks, and is this specific case it is not currently in use as such by Qubes.”
Is still true?
The OPAL standard requires that securely-configured drives (having enabling OPAL or ATA Password and importantly, whether currently locked or unlocked) shall block firmware updates or, if they do not fully block, the unlocking credential used to unlock the drive at boot must also be sent to initiate firmware updates.
IMPORTANTLY: when not securely-configured (as they come from the factory), firmware updates are not blocked at all. Enabling the locking of the drive at power on is also the way to block firmware changes."
But understand this to need start with “known good” state.
