Some (mostly not that relevant) details missing from the article:
1. CPU microcode update packages from Intel ("MCU") are unified "processor package" update containers. They update more areas of the chip other than just the MSROM. This is more obvious in the SoC parts, but it is also true on the discrete parts.
2. MCU can be downgraded, although this is clearly going into "not validated at all" area, so it might not result in a very stable system ;-) It is likely that Intel can set a flag inside the MCU data that forbids this (the MCU loader inside the processor is more than complex enough to support this kind of thing!), but at least up to Westmere downgrades were still working.
2b. and you can always downgrade either just the microcode inside the firmware by modify-and-reflash, or the firmware itself, even if the CPU started to ignore downgrade attempts at runtime.
3. When the MCU update process is done in a trusted environment (microcode update data in the FIT), the reported microcode version CHANGES (the processor reports it as one less than the real version of the microcode). This is relevant for attestation, and it is really something that needs to be added to the IA32 manuals. We only know about it outside of the NDA'ed world because coreboot required a fix for the next issue:
4. As long as you find a way to always feed them the latest microcode (or at least the same revision that you have in the firmware), Linux, VMWare and the BSDs [currently] will always override FIT-provided microcode, thus changing the reported microcode revision (it will not be reported as secured anymore). Since the revision changed, it will break any attestation that depended on it. This looks like a good thing at first glance, given how utterly broken at launch the recent Intel processors have been: anything that would get in the way of an user being able to fix these by updating the MCU is a damn bad idea and NEEDS TO DIE.
5. The microcode update process nicely wastes several million cycles (and it can easily get to a billion cycles in larger systems, as the update cost increases linearly per core) at every operating system boot and resume from ACPI S3/S4/S5 ;-) Try to ensure that your firmware has the latest one if you want to have a smaller carbon footprint, because if the OS decides to update it, the box will be doing this expensive procedure twice at every boot/resume...
Re: 1 - I re-read the relevant SDM sections, and saw that there is no requirement that the new upgrade version exceeds the current microcode version. Thank you very much for pointing that out! The next published revision will have the fix.
Do you have any public references for 3 and 4? That looks like it'd help make the case that SGX rests on very complex and unstable foundations.
1. CPU microcode update packages from Intel ("MCU") are unified "processor package" update containers. They update more areas of the chip other than just the MSROM. This is more obvious in the SoC parts, but it is also true on the discrete parts.
2. MCU can be downgraded, although this is clearly going into "not validated at all" area, so it might not result in a very stable system ;-) It is likely that Intel can set a flag inside the MCU data that forbids this (the MCU loader inside the processor is more than complex enough to support this kind of thing!), but at least up to Westmere downgrades were still working.
2b. and you can always downgrade either just the microcode inside the firmware by modify-and-reflash, or the firmware itself, even if the CPU started to ignore downgrade attempts at runtime.
3. When the MCU update process is done in a trusted environment (microcode update data in the FIT), the reported microcode version CHANGES (the processor reports it as one less than the real version of the microcode). This is relevant for attestation, and it is really something that needs to be added to the IA32 manuals. We only know about it outside of the NDA'ed world because coreboot required a fix for the next issue:
4. As long as you find a way to always feed them the latest microcode (or at least the same revision that you have in the firmware), Linux, VMWare and the BSDs [currently] will always override FIT-provided microcode, thus changing the reported microcode revision (it will not be reported as secured anymore). Since the revision changed, it will break any attestation that depended on it. This looks like a good thing at first glance, given how utterly broken at launch the recent Intel processors have been: anything that would get in the way of an user being able to fix these by updating the MCU is a damn bad idea and NEEDS TO DIE.
5. The microcode update process nicely wastes several million cycles (and it can easily get to a billion cycles in larger systems, as the update cost increases linearly per core) at every operating system boot and resume from ACPI S3/S4/S5 ;-) Try to ensure that your firmware has the latest one if you want to have a smaller carbon footprint, because if the OS decides to update it, the box will be doing this expensive procedure twice at every boot/resume...