Greg Kroah-Hartman on Meltdown, Spectre and the Linux kernel
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As the admin of a small "fleet" of Slackware desktops and servers, I can honestly say that I'm not looking forward to this:
Quote:
And then keep updating them over the next few weeks, we are still working out lots of corner case bugs given that the testing involved here is complex given the huge variety of systems and workloads this affects
Yoinks!
I'm glad though that a lot of very clever people are hard at work resolving this whole mess. Also I'm happy that most of the boxes at my company are AMD. I think I'm down to a measly 9-10 Intel boxes, so that's a good thing at least.
But yea, interesting times ahead indeed.
What is your plan/experience with all this? I for one intend to just apply whatever patches Pat + crew put out.
Right now, there are a lot of very overworked, grumpy, sleepless, and just generally pissed off kernel developers working as hard as they can to resolve these issues that they themselves did not cause at all. Please be considerate of their situation right now. They need all the love and support and free supply of their favorite beverage that we can provide them to ensure that we all end up with fixed systems as soon as possible.
What is your plan/experience with all this? I for one intend to just apply whatever patches Pat + crew put out.
Use the publicity around this to encourage people to run ad-blockers (ublock-origin / NoScript etc), after all the web browser is the No1 introducer of untrusted content on to the average computer and if that has the side effect of also blocking the trackers then that's just the cherry on top.
Segment networks more - look at what does what - for example that Kodi box attached to the telly is as bad as the web browser and possibly worse, yes it's nice to be able to stream from the NAS but really it doesn't need unfettered access to the rest of the network. This I'm happy to firewall off from the rest of the network but have to accept that's not a solution many will bear.
IOT, if you have any, deserve a very close look indeed. If a phone manufacturer/provider whose business model is selling the latest shiny thing fails to support your phone after 2-3 years, how well maintained will your internet connected television/refrigerator/washing-machine be? Again, wall it off to the greatest extent you can.
Act fast - Grandma & Grandpa will soon forget about all these headlines - act while the news is still fresh - it's your best chance of introducing sensible security measures, especially if they cost a little in convenience.
Thanks for the update and link to Greg K-H's blog. One person wrote that Meltdown and Spectre require both a kernel and microcode update. Is this true or simply a best practice?
Anyone have a link to a Intel's microcode release that is later than the 20171117?
I'm glad though that a lot of very clever people are hard at work resolving this whole mess.
I am pretty sure that the CPU industry has a lot of very hard working clever people as well. And they aren't ethically defective. I guess most of them (if not all) are tied up by NDAs and this makes me feel pity for them. Wasn't Linus himself involved in CPU design at Transmeta? We are so lucky to have him doing what he does now.
Did you check the links? There are newer files with different sizes in at least the gentoo link compared to the original (didn't check the debian), so something has definitely changed between the two. I did an ls -lart in both intel-ucode directories and redirected the output into files. I then compared the files and the output is below:
Code:
diff --git a/microcode-1117 b/microcode-1215
index 87adf1a..732d86b 100644
--- a/microcode-1117
+++ b/microcode-1215
@@ -1,4 +1,4 @@
-total 1672
+total 1684
drwxr-xr-x 2 jbhansen users 4096 Nov 16 12:28 ./
drwxr-xr-x 3 jbhansen users 4096 Jan 8 13:26 ../
-rw-r--r-- 1 jbhansen users 2048 Nov 16 12:27 06-06-05
@@ -68,30 +68,30 @@ drwxr-xr-x 3 jbhansen users 4096 Jan 8 13:26 ../
-rw-r--r-- 1 jbhansen users 14336 Nov 16 12:27 06-1a-04
-rw-r--r-- 1 jbhansen users 24576 Nov 16 12:27 06-17-0a
-rw-r--r-- 1 jbhansen users 4096 Nov 16 12:27 06-17-07
--rw-r--r-- 1 jbhansen users 32768 Nov 16 12:27 06-3f-02
-rw-r--r-- 1 jbhansen users 15360 Nov 16 12:27 06-3e-07
-rw-r--r-- 1 jbhansen users 11264 Nov 16 12:27 06-3e-06
-rw-r--r-- 1 jbhansen users 13312 Nov 16 12:27 06-3e-04
--rw-r--r-- 1 jbhansen users 17408 Nov 16 12:27 06-3d-04
--rw-r--r-- 1 jbhansen users 22528 Nov 16 12:27 06-3c-03
-rw-r--r-- 1 jbhansen users 12288 Nov 16 12:27 06-3a-09
-rw-r--r-- 1 jbhansen users 13312 Nov 16 12:27 06-2f-02
-rw-r--r-- 1 jbhansen users 17408 Nov 16 12:27 06-2d-07
--rw-r--r-- 1 jbhansen users 98304 Nov 16 12:27 06-4e-03
-rw-r--r-- 1 jbhansen users 11264 Nov 16 12:27 06-47-01
-rw-r--r-- 1 jbhansen users 24576 Nov 16 12:27 06-46-01
--rw-r--r-- 1 jbhansen users 20480 Nov 16 12:27 06-45-01
-rw-r--r-- 1 jbhansen users 16384 Nov 16 12:27 06-3f-04
--rw-r--r-- 1 jbhansen users 16384 Nov 16 12:27 06-5c-09
-rw-r--r-- 1 jbhansen users 21504 Nov 16 12:27 06-56-04
-rw-r--r-- 1 jbhansen users 20480 Nov 16 12:27 06-56-03
-rw-r--r-- 1 jbhansen users 28672 Nov 16 12:27 06-56-02
--rw-r--r-- 1 jbhansen users 26624 Nov 16 12:27 06-55-04
--rw-r--r-- 1 jbhansen users 26624 Nov 16 12:27 06-4f-01
-rw-r--r-- 1 jbhansen users 72704 Nov 16 12:27 06-7a-01
-rw-r--r-- 1 jbhansen users 98304 Nov 16 12:27 06-5e-03
--rw-r--r-- 1 jbhansen users 97280 Nov 16 12:27 06-8e-09
--rw-r--r-- 1 jbhansen users 97280 Nov 16 12:27 06-9e-09
-rw-r--r-- 1 jbhansen users 96256 Nov 16 12:27 06-8e-0a
-rw-r--r-- 1 jbhansen users 97280 Nov 16 12:27 06-9e-0b
-rw-r--r-- 1 jbhansen users 95232 Nov 16 12:27 06-9e-0a
+-rw-r--r-- 1 jbhansen users 33792 Dec 15 07:59 06-3f-02
+-rw-r--r-- 1 jbhansen users 27648 Dec 15 07:59 06-4f-01
+-rw-r--r-- 1 jbhansen users 27648 Dec 15 07:59 06-55-04
+-rw-r--r-- 1 jbhansen users 98304 Jan 4 17:35 06-9e-09
+-rw-r--r-- 1 jbhansen users 98304 Jan 4 17:35 06-8e-09
+-rw-r--r-- 1 jbhansen users 16384 Jan 4 17:35 06-5c-09
+-rw-r--r-- 1 jbhansen users 99328 Jan 4 17:35 06-4e-03
+-rw-r--r-- 1 jbhansen users 22528 Jan 4 17:35 06-45-01
+-rw-r--r-- 1 jbhansen users 18432 Jan 4 17:35 06-3d-04
+-rw-r--r-- 1 jbhansen users 23552 Jan 4 17:35 06-3c-03
However, on the SBo mailing list, 55020 gave some insight on what's likely going on. Here's his message:
Quote:
Some distros seem to have mysteriously got a 20171215 release, it must
have come from Intel but it is not available from Intel's page. Maybe
a bit more information is below, from the Debian bugreport.
In particular see https://bugs.debian.org/cgi-bin/bugr...?bug=886367#37
"The current plans are for stable to wait for Intel's official microcode
update pack. It is not like this set of microcode updates will get you anything
without the kernel IBRS and IPBP support, which is still being
stabilized. These updates are currently necessary for people doing the
kernel work
and for testing and stabilization. Ditto for AMD microcode updates,
which I will upload soon now that the kernel support for loading them
has made it to Linux mainline."
So I hope this is a partial answer -- there is a supplementary set of
20171215 files circulating amongst the kernel devs so they can prepare
kernel fixes that depend on them. Those kernel fixes are not yet
ready, and 20171215 isn't useful on its own.
Long story short, microcode updates probably won't help until you have a kernel that has the required fixes in it. Just wait for the kernel devs to do their thing, then Intel will release the official update and hopefully we'll see updated kernels for Slackware relatively quick.
@bassmadrigal I had looked at these links on 01/03/18 and they did not contain the updates now showing as being added on 01/04/18. Wonder why Gentoo didn't bump the file name, but added updates for a later date? I did not do the compare as you did, which is showing the six updates for recent processors. What isn't known and isn't mentioned in the "releasenote" file is what these updates address. So it is a guess that these updates address Meltdown or Spectre, when in fact they may address something totally different.
I agree with your final analysis..."...wait for kernel devs to do their thing, then Intel will release the official update...". In the meantime, I'm going to use the 20171117 with my currently running kernel 4.4.106 to see if I can do the microcode upgrade correctly in preparation for the microcode fixes for Meltdown and Spectre. I'll then after 24 hours running with the newer microcode update to 4.4.110 with the Kaiser updates and TPKI switch and see how that functions. It is probably better to do the earlier update since it should be stable and not cause issues. Then later this month maybe Slackware will have an official release of a kernel that more completely addresses the issues. Although Greg K-H in his 01/06/18 blog stated that the LTS kernels already had shipped with updates, although more would be coming, what ever that is addressing. CHeers.
I've read many references in the articles describing these vulnerabilities in the online media (especially in the German one) in which it was suggested that Intel has had these microcode updates prepared and due to be released on the 9th of January. However, I couldn't find any official statement on Intel's site about this. Intel's latest update is on the 5th of January: https://security-center.intel.com/ad...nguageid=en-fr
(check Revision history)
On the Debian forum these "pre release" Intel updates are also discussed: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=886367
Whereas, theoretically, nobody but Intel can modify/update the microcode, this being protected/signed with RSA: https://www.dcddcc.com/docs/2014_paper_microcode.pdf
I'm still not sure if the latest modification to the Linux kernel, mitigating these vulnerabilities on a SW level, will be necessarily needed or the CPU microcode will handle the issues all by itself. I, hope for the latter, whereas the kernel patches have their value for systems that are not being patched (operational issues) at CPU level (microcode). We'll wait & see.
To completely address the issues, also the entire operating system should be rebuilt using a patched GCC.
This is the single way to address the Spectre in a effective way.
I fear that this will be the ARM solution and it will be definitely an overkill. Not sure how Android (mobile devices manufacturers) will handle that.
(mentioned it here) https://www.linuxquestions.org/quest...ml#post5801910
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
