[geogriffin]

SGX Remote Attestation was built specifically to deal with events like this. Intel starts to reject attesting to vulnerable microcode revisions after some period following disclosure. In this case, they even postponed disclosure until patched microcode revisions were available and those revisions already required for successful attesation.

If said SGX application wasn't built around this model then it's probably not a valid use case of SGX..

[bscphil]

Isn't this pretty much a no-go for any large public software project, given that microcode updates often depend on the OEMs, which are notoriously bad about supporting devices older than about a year?

[zimmerfrei]

I think that is mostly the case for BIOS and platform firmware. CPU microcode can be loaded by the OS (if the OS allows you to, as Linux does - https://www.cyberciti.biz/faq/install-update-intel-microcode...).

[geogriffin]

BIOS updates are required for most SGX-related microcode updates, as the microcode has to be up-to-date before enabling the SGX feature via a MSR (which is usually done by the BIOS). This is so you can't start an enclave with old microcode, exploit it, upgrade microcode, and still pass remote attestation.

Also, the more major spectre-related microcode updates have to be applied very early (in the BIOS) probably for technical reasons. For this latest microcode update, for example, Intel didn't even include it in their downloadable microcode package as you linked to. On my v6 Xeons, I was able to get to revision 0x84 with the latest OS microcode package, but 0x8e with a BIOS upgrade.

[geogriffin]

It looks like Intel is pushing these security-related patches pretty hard on vendors, as this latest patch was available in late May on one IBM board Softlayer uses, and early June on another Supermicro board they use.