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.
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.
https://review.coreboot.org/cgit/coreboot.git/commit/?id=504...
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.