[elrepo] Recommended minimum fixes in both the kernel and Intel microcode for Meltdown and Spectre

[David Ranch]

Hello Phil,

I appreciate the reply...  please see inline for a few questions..


> https://elrepo.org/bugs/view.php?id=810
>
> It looks like it was fixed in 4.4.110

Excellent, thank you.  One thing I've struggled to *simply* figure out 
is what fixes get into what releases.  For example, what release of the 
3.2 or 3.16 LTS kernels have this fix?  Sure, I can find the git commit 
in that branch that has the fix BUT it's not clear how to see what 
commits are in what release.  Maybe there is a simple way to do this?


> Generally though, users should run the latest release, built from the 
> latest upstream kernel sources to ensure they have all the latest 
> patches.

Absolutely understood but that's not always possible in a quick turn 
around.  I'm also waiting to really hear what the exploitability of this 
is going to be.  Sounds like web browser vendors are de-tuning their 
JavaScript's timing engines to avoid this but what else from a practical 
point of view is needed to avoid remote exploitability? Time will tell I 
suppose.


> Yes. As I understand this package applies microcode patches to the CPU 
> regardless of the running kernel. I would also check with hardware 
> vendors for any bios updates that also address the issue.

Excellent, thank you though you bring up an interesting point on the 
BIOS.  In my experience, there is little to zero chance of getting that 
to happen on older motherboards by even the best vendors like Intel, 
Asus, etc.  I'm curious though, if the newer microcode can be installed 
by the OS, why do we need to worry about the BIOS?  I generally don't 
have enough understanding of the initialization handoff between the BIOS 
and the Linux kernel but I was under the impression Linux doesn't need 
much of the legacy BIOS or modern UEFI equivalents anymore.


> As you are aware, EL5 is EOL, so if still running should not be 
> internet facing as there will be many other security risks besides 
> meltdown and spectre. But to address these issues specifically, one 
> should run the latest release of a supported kernel branch, check for 
> any vendor bios updates and apply the latest microcode updates. For 
> the latter, you could either look to build an updated package 
> containing the latest upstream microcode from Intel, or you can 
> download the microcode files from Intel, unpack the intel-ucode folder 
> into /usr/lib/firmware/intel-ucode/ overwriting the files provided by 
> the microcode_ctl package and manually force an update without 
> rebooting by doing:

Thank you for the details there as well.  Two things I'm looking for:

    - Is it possible to still find the last SRPMs that were used for 
ElRepo's LT kernels?  If I have that, I can hopefully shoehorn in a 
newer kernel (maybe 3.2 or 3.16) with all the required fixes.

    - If I can also find the SRPM for the last Centos 5 microcode_ctl 
package ( 
https://www.centos.org/docs/5/html/5.5/Technical_Notes/microcode_ctl.html 
) , maybe I can load in the new Intel firmware into that too.  If not, 
maybe shoehorning the required firmware into the kernel package itself 
might work ( 
https://www.dotslashlinux.com/2017/04/30/building-intel-cpu-microcode-updates-directly-into-the-linux-kernel/ 
)


> echo 1 > /sys/devices/system/cpu/microcode/reload

Cool trick and I never imagined you could do that hot like that. Impressive!

--David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20180106/4bfa9521/attachment.html>