As far as I remember, the switch to a new firmware uploading mechanism was due to the fact that newer firmware disabled TSX instructions completely on Haswell, thus causing segfaults of applications linked against libpthread. I.e. patching firmware later than "very early on boot" was too late at least for Haswell.
This consideration does not apply directly to Trusty, as Trusty's glibc never used hardware lock elision. However, this might be the case for containers and chroots (including non-Ubuntu ones) running on Trusty. As far as I understand, Ubuntu glibc was later rebuilt to never use hardware lock elision, because it exposed too many double-unlocking bugs in third-party software. My conclusion is that it is 100% unsafe to update firmware blobs in Trusty if there is a possibility that any non-Ubuntu container gets started before the firmware is uploaded to the CPU. If such situation is impossible, then please treat this comment as a no-op. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1700373 Title: Please update microcode to version 20170511 on all supported platforms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1700373/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
