> OK, so color me confused about the timing in all this. > > Do we update the microcode now or do we wait until the latest microcode_ctl > rpm is available and then tackle this issue? The message is: stay away from microcode updates because they're broken right now. Intel may or may not release fixes next week to be tested by OEMs. Once working updates are available, OEMs will integrate them into their firmware/BIOS releases. That is one method to avail of microcode updates. The other method is loading during OS boot (via udev rule), with codes provided by the microcode_ctl rpm. It looks like Red Hat are now staying away from that; in any case, their previous rpm only included ucodes for three cpus. I did not check if the microcode.dat included more updates than that. Method number 2b is to download the firmware from Intel directly and provide it in the locations defined by the microcode_ctl rpm. Then it's up to you to do the QA. If your RHEL/CentOS is fully up to date, you're protected against variant 1/Spectre and Meltdown. Red Hat have done a pretty good job to backport those patches from upstream. GKH's blog is worth a read.