update 20230214 through the operating system might disable SGX due to INTEL-SA000738 fix ?

[hmh]

According to: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00738.html

IF one is using SGX, one MUST install both the BIOS and the microcode update for these processors. Fail to do that, and SGX disables itself. Well, the BIOS update is not something the operating system can ensure...

Is this information correct? Not that it matters much to Debian, since we do not officially support SGX anyway, but still it looks like we should add a (permanent!) warning for these processors that updating their microcode could disable SGX when the system firmware is outdated, but I'd really like to be certain we need such a warning first...

[alexmurray]

It is not clear if this simply disables SGX or if the processor fails to boot if the MCU and BIOS are not updated together - see https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/q1-2023-intel-sgx-tcb-recovery-guidance.html

As such in Ubuntu I plan on not shipping these two affected MCUs (606A6 and 606C1). See comment below.

[hmh]

Sounds good. I will denylist these two specific MCUs as well until more information is available...

I am more worried about people with SGX enabled in firmware, and no incentive to update their firmware because they don't really use SGX, it was just enabled by whatever reason (default? argh!) and left as-is. If that situation still triggers a hang (looks likely), this will be an annoyance for a long, long time.

-- Edit: looks like it will boot fine but not mitigate SA000738 when there is a BIOS/ucode mismatch. Therefore, Debian will ship these microcode updates.

[whpenner]

OS loading the patch does not disable SGX. It also does not mitigate SA000738. OS loading is okay, however SGX users will need to update their BIOS/microcode update when the TCB recovery occurs.

[alexmurray]

@whpenner can you confirm that if the OS loads the microcode and the BIOS has not been updated, then the machine will still boot successfully when SGX is enabled? Also, in this case is SGX still available / functioning? Basically as a distro we want to make sure we don't cause a regression for these machines that have SGX enabled - ie. we can't afford to have them fail to boot and in the case that SGX is being used on the machine, we also don't want this to suddenly stop using just because the microcode update was installed in the distro and then loaded by the OS at next boot.

[alexmurray]

Just to answer my own question after having this all explained to me by an extremely helpful thirdparty:

The machine will both boot fine and be able to use SGX in the case that there is a mismatch between the BIOS and the OS loaded microcode, but the new microcode will fail to load and so they will not be mitigated against SA000738.

As such in Ubuntu we will ship the new 20230214 / IPU 2023.1 without modification (so ignore my comment above).

[whpenner]

@alexmurray Thanks for the response. One clarification, in the case where SGX is enabled and an older microcode update (MCU) is in BIOS, and you then load the newer MCU from the OS, the MCU is loaded but the specific mitigation for SA0000738 is not (because the mitigation needs to be loaded at RESET/FIT). Other changes in the MCU are still effective.

[hmh]

Oh, that's nice. @whpenner, thanks for the good news!