At 2019-06-01T09:04:39+0200, Philipp Kern wrote: > Are we then looking more closely at AMD-based machines given that > those had less problems around speculative attacks? To borrow a phrase from Christopher Hitchens, this comment gives a hostage to fortune. My team at work closely follows (and part of it contributes to) the research in microarchitectural timing-channel attacks; we just covered the white paper on one of the three new attacks (RIDL)[1] on Friday. I'll say this now because I don't know of anything embargoed that could get me into trouble: don't count on AMD's good smell just this second to last. Remember that the previous round of embarrassments (Spectre/Meltdown) didn't entirely spare AMD and ARM, and we haven't yet seen any ground-up reimplementations of CPU cores with publically auditable, formally-verified proofs of immunity to microarchitectural timing channel attacks. I see no reason to reward AMD with purchases based on what may be an accidental and temporary lack of egg on the face. This is the same firm that followed Intel into the land of unauditable system management firmware[2] and acquired ATI and shut down the information channels enabling good free video drivers to be developed[3]. My two cents[4] is that DSA should make its purchasing and hardware solicitation decisions with the architectural security issue fairly far down the priority list. It saddens me to say that, but this new class of exploits, what van Schaik et al. call "microarchitectural data sampling" (MDS), is a playground for security researchers right now; a big rock has been turned over and bugs are erupting from the soil in a squamous frenzy. It will take months or years for the situation to settle down. To acquire hardware based on what is known today is to risk buyer's remorse. Plan on inescapable remorse later; every chip vendor will let us down until corporate managers learn to treat confidentiality and integrity as feature rather than cost centers. (And count on them to forget what they've learned after a few quarters pass without embarassing headlines.) Some day, perhaps, if the universe is less than maximally cruel, we'll have the option of server-class RISC-V systems with fully-documented, formally-verified designs. But that day is not yet here. In the meantime, always keep a fork with some cooked crow on it ready to hand, so that the next time you run into one of the many "pragmatic" people in our community who puffed and blew about how we didn't "really need" open hardware, you can invite them to eat the stuff and so be silent. One wonders how pragmatic they'll feel when it's _their_ private data being exfiltrated. [1] https://mdsattacks.com/files/ridl.pdf [2] https://libreboot.org/faq.html#amd [3] I don't have a good cite handy for this, but Michel Dänzer can doubtless tell the story with more accuracy and precision than I can. [4] ...further discounted reflecting my rather low level of project activity.
Attachment:
signature.asc
Description: PGP signature