What security impact of the Haswell/early-Broadwell TSX bug? The support for all TSX instructions where really disabled by the microcode update, and we know that for sure because it crashed the world instantly (in Linux).
Now, working TSX can have a security impact, yes. At least on TSX as implemented on later Broadwell/early Skylake, memory accesses done from inside an speculative region are allowed to bypass stuff they shouldn't. Is that what you meant?
Meh, for C2000, it can be also a sign of outdated firmware. We don't get microcode updates for SoCs in the general distribution: either your system vendor does a good job of keeping up with firmware updates, or you are screwed.
Sort of. Removing the firmware-provided microcode update would likely kill Intel SGX support, though. And if UEFI is set for secure boot and its implementation happens to uses SGX or TXT for that, it probably will brick the box until one restores its system FLASH to a valid state.
You can further update the processor microcode later, from UEFI or from the operating system. But the all-important initial processor microcode[1] update has to be done from a trusted path [for Intel SGX to be available].
And no, it is not UEFI early boot updating the microcode as it used to work in the past: when doing a secure Intel SGX boot path, the microcode looks up the FIT table in system FLASH, to get the address of a microcode update table in system flash. If found, the microcode then proceeds to self-update from FLASH.
This whole auto-load-microcode-from-FIT thing seems to have started with Skylake. Since Intel SGX is almost entirely implemented in microcode, it makes a lot of sense.
ON INTEL SKYLAKE AND LATER, you can notice whether the current microcode update came from FIT or not by reading its revision number. If it is odd, it came from the FIT. If it is even, it came from regular UEFI or O.S. updates.
As for recent Intel systems without Intel SGX (or with it disabled), you still likely need a firmware-provided initial microcode update or it will be hopelessly buggy. Chances are it won't be stable enough to actually boot the target O.S.
[1] Intel has been shipping its processors with shamelessly incomplete/buggy factory microcode for a while now. You pretty much have to install a microcode update, or what you will get might not even qualify as a X86-64 compatible processor. The factory microcode doesn't need to know how to do paging or hardware-assisted virtualization correctly at all, for example, or even implement SIMD and floating point math instructions. All it has to do is to be able to run enough of BIOS/UEFI to get the initial microcode update.
No, if you break the signature, something (processor microcode or the IME boot block?) will notice, and the system will either not start, or shutdown after ~30min.
There is microcode-level integration between the IME and the system processor in an Intel system. It also involves the platform TPM (which could be an IME module), on systems where Intel SGX or Intel TXT is active.
OTOH, if the non-critical IME modules are missing, the system boots and goes on working just fine. Since the IME "partition table" is not signed, this allows you to remove the undesired modules such as Intel AMT.
It is actually possible for a system integrator/motherboard factory to request from Intel a minimal IME build that lacks AMT, you know.
It is also rather trivial to disable the (documented) IME path to the network: don't use the chipset-embedded ethernet MAC (as in midia access controller, not MAC address). That requires adding a full LOM NIC chip and taking up precious PCIe lanes, instead of just adding a (much cheaper) LOM PHY.
Are you aware that the newer Xeons, and only the Xeons, have such an serial number facility available?
Control over this processor identification facility is supposed to be offered as a user-accessible control in UEFI, to "enable, leave disabled but unlocked, and lock disabled". Once "lock disabled", it cannot be enabled back again until a hard reset happens.
Also, unlike the Pentium III "processor serial number cpuid", you need to read a MSR to access the new version, so it is supposed to be restricted to the O.S. kernel, which could then either make it available to regular programs or not.
It is not easy to find out about it, either: it is hidden in plain sight on the public Intel SDM (the processor's manual). You need to look over all the model-specific MSRs with a magnifying glass until you find it :-)
In the end, it boils down to whether your favorite O.S. cares about your privacy or not. It can lock the thing disabled at early boot, denying access to everything other than UEFI.
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.
Now, working TSX can have a security impact, yes. At least on TSX as implemented on later Broadwell/early Skylake, memory accesses done from inside an speculative region are allowed to bypass stuff they shouldn't. Is that what you meant?