To be clear, my point in describing these Qubes developments is to highlight how much effort goes into navel-gazing, even counterproductive misfeatures while something as basic as in-house testing of a valuable x86 implementation has been ignored.
There was not even a mention of AMD in Qubes’ hardware donation requests.
And now Qubes is tacitly accepting vague aspersions that AMD virtualization should be avoided because its a “different implementation” than Intel. Its as if Xen and KVM users are strangers to IOMMU passthrough; What Qubes doesn’t test on AMD means no one else tests it. Very puzzling indeed. Imagine what Trail of Bits think of data centers that are drawn to AMD SEV to handle sensitive information; assuming they do have an opinion of AMD in data centers (bc “deep expertise”, I think they must) the mental gymnastics must be impressive.
Extending the devil we know logic to software, Qubes in its entirety becomes unacceptably insecure. If the same firm is hired not for the benefit of helping a group of Qubes users, but for some other purpose… Their assessment–should they cast their gaze back in this direction–could very well be just that. Qubes is not well tested in relation to more established operating systems as it is a different implementation of isolation mechanisms on the desktop––AVOID. By accepting work from a group invested in Qubes technology, and taking Qubes as a given, a glass house has been constructed.
In spring of 2018–on the heels of Meltdown and Spectre–Trail of Bits was hired by CTS Labs to back up their claims of a supposedly severe set of AMD vulns headlined as Ryzenfall, having given AMD only 1 day to respond. They turned out to be essentially a dud (required admin and/or firmware flashing privs) but not before CTS whipped up a tech media storm against AMD. The Anandtech interview is interesting, especially when CTS cut it short:
DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?
ILO: I definitely am not going to comment on our customers.
DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.
ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.
CTS Labs demanded AMD recall all Ryzen processors “for public safety” and also simultaneously displayed on their ryzenfall site a disclaimer that the contents were merely opinions and not statements of fact… That is not only unheard-of for security research, it is how propaganda orgs operate to manipulate the public.
Many people, including Linus Torvalds, said CTS’ claims (which appear to have been channeled in advance through an investment firm) looked like stock manipulation, and I have to agree.
Trail of Bits’ role as CTS hired hands appears to be quashing skepticism about the severity of the bugs. The “Twitter hot takes” ToB complained about were emphasizing the need to have local admin privs first. ToB bemoaned stirring a “hornet’s nest”, an uncanny act of projection.
There has to be remediation of Qubes’ lack of judgement and courage here, and I’m not talking about damage-control PR tactics. Merely repeating “AMD is supported” won’t dispel the shadow that has been cast on Qubes’ integrity; it will darken the OpenPOWER port (if/when its finished) because that hardware will have even less testing on Qubes, orders of magnitude less than AMD. Any aspect of Qubes development could be (and arguably has been) undermined by this kind of bias.