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

[Phil Perry]

On 06/01/18 16:29, David Ranch wrote:
> 
> 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?
> 
> 

Other than viewing the changelog and/or tracking the commits on git, I'm 
not really sure. Subscribing to the LKML would also probably be a good 
idea, but I'm guessing it is high volume.

>> 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, I'm guessing we won't have to wait too long to see exploits start 
to appear in the wild.

As I understand it, Meltdown affects only Intel chips, and is addressed 
by the recent kernel patches.

Spectre affects most all CPUs (Intel, AMD, ARM) and is not completely 
fixable, but is also far harder to exploit.

One piece of software elrepo offers (kmod-tpe) may be useful in offering 
an additional line of defence against hackers running local exploit code 
on a machine to which they have access. I posted previously about it here:

http://lists.elrepo.org/pipermail/elrepo/2017-June/003620.html

>> 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.
> 
> 

Agreed. I just checked for BIOS updates from Asus for my own motherboard 
and found that whilst they have released an Management Engine update for 
Intel-SA-00086, the update tool is Windows only and they haven't 
released an updated BIOS.

>> 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!
> 

This method would be far easier for you than updating the old el5 package.

The latest Intel microcode tarball is available here:

https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

That said, I used this method to update my microcode to the latest 
version back in the summer after a bug that affected my CPU (before the 
discovery of the current vulnerabilities), and I note the latest release 
has not updated the microcode for my CPU (Intel Core i3-6100), so just 
because one has the latest version, doesn't mean to say things are fixed.

Consequently, as expected given I've had no effective BIOS or microcode 
update, the Intel-SA-00086 detection tool still shows my system as 
having a vulnerable Management Engine firmware. At this point all I can 
do is try to mitigate the risks. I'm guessing there will be a LOT of 
PCs, laptops, tablets and smartphones in exactly the same position.