Comment 30 for bug 1700373

FWIW, since I am a completely neutral party (Debian maintainer), here are some points that may help the Ubuntu teams make a decision:

1. Hypervisors must not (and don't) allow a guest to supply microcode updates, they're blocked at the WRMSR handler. This is required behavior, because it is trivial for a guest to attack the whole host system using microcode updates, resulting in denial-of-service (core hangs) and specially crafted microcode containers (whole box hangs, maybe crashes/reboots, microcode downgrade as a step in a complex attack).

Container-based systems cannot filter "guests" (containers) at the WRMSR opcode level like hypervisors can, and therefore must somehow block all entry points to the kernel that could trigger a microcode update from untrusted data. Beware the MSR.ko module.

2. In Debian, we are not aware of any issues with the Trusty's method of microcode updates (late updates) other than the ones related to Intel TSX.

However, late microcode updates have increased risk of regressions since they happen after the kernel and modules have initialized MSRs, etc. We have seen such issues related to *BIOS*-initialized MSRs on Xeon E5v3 (which required further microcode updates to fix), but we have not observed anything related to kernel-initialized MSRs. So, this increased risk is a theoretical issue at the moment, AFAIK.

3. Almost nobody tests late updates anymore. All large distros switched to early updates a couple years ago, AFAIK.

4. What Debian did for Debian wheezy (which uses the same outdated method as Ubuntu Trusty to update microcode) was to have two sets of microcode-updating packages and kernel packages (in this case, using wheezy-backports), and drop support for Haswell and later processors using the old method.

However, this whole thing did not work very well and now the Wheezy-LTS team will have to very much make the same kind of decision you must make for Ubuntu Trusty.