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