I already countered him on microarchitectural covert channels. Goes back further to VAX Security Kernel (1992) being designed to certify to A1-class which mandated covert-channel analysis that regular, "secure coders" didn't do. INFOSEC pioneers had already found them in software and hardware like disks. A person on that project reported them for cache timing as well. Aside from the Trojan model, they also described them back then as inherent design flaws where shared resources leak details about one computation to another. In other words, cpercival's model. They talked about Trojan model mostly because solving the threat of superset model, subversion, solved other one as side effect. Knocking out all backdoors and leaks was what culture of the time highlighted the most. I pointed it out plus some follow up commentary here:

https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_kno...

I didn't respond to the later nonsense dismissals on HN and elsewhere about the Intel CPU Security submission since I had surgery shortly after that on an impacted tooth. Didn't want to be online all drugged up talking about these things. ;) Suffice it to say, high-assurance security had already found piles of risk areas for both penetration and side channels in Intel CPU's with some attempts at mitigation (including avoid Intel CPU's) by the mid-1990's. They encouraged Intel, purchasers, and security community to deal with it as part of routine work in improving security.

As usual, the mainstream security community just ignored everything they said when they bumped into each other. It's not like high-security folks stopped trying to tell them about prior successes and problems:

http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf

Then, a bright researcher independently discovered the side channels in caches later. They started reacting to that claim. They found some similar issues in other stuff looking narrowly. Now, we have another clever attack that started with a shared resource as would've been identified in the 1992 methodology that got stretched in really creative ways. It was still same root cause they ignored or justified for things like lowest price/performance versus alternatives doing it securely. Or just physical separation of different security domains which highest-security setups stuck with grudgingly.

My prediction in one of the Lobsters comments was that piles of comments would happen about this that didn't involve actually solving it (social gratification), more people would similarly write articles boasting their understanding to generate extra rep since talking problems in is rewarded in mainstream INFOSEC more than preventing/solving them, a few mitigations would show up that were narrowly-focused on just this new kind of problem (like happened with caches), they'd still ignore prior work in high-assurance like Kemmerer or Wray's analyses that found similar problems 20+ years before analyzing whole system, they'd mostly ignore the new work on information-flow analysis (some in link below), and we'd at best get some time until the next problem that could've been prevented by 1990's or recent methods since that's how mainstream security industry and culture works.

They're right on track since that's about all I saw while in recovery for a week. Endless articles using the buzzwords to their advantage plus people who don't know we could've beaten this in the 1990's because security professionals in industry suppress that knowledge for some reason. That needs to stop. At least they're rediscovering 60's-90's knowledge at an accelerated rate now.

Work on Information Flow Security in Hardware
https://pastebin.com/ajqxDJ3J