The Latest Kernel Release.

kjhambrick · 01-05-2018, 02:46 PM

Quote:

Originally Posted by Petri Kaukasoina

No, kernel-firmware contains binary blobs to be loaded in the ethernet card and so on.

You get the latest Intel microcode via BIOS updates from the PC vendor, or you can install intel-microcode from slackbuilds.org. Intel has given out new microcode only for some cpus. If you have installed iucode_tool from slackbuilds.org, "iucode_tool -S" prints the processor signature, like 0x000206a7. Only these new microcodes are ready:

Code:

2017-12-15 (unofficial bundle with CVE-2017-5715 mitigation):
  * Updated Microcodes:
    sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
    sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
    sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
    sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
    sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
    sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
    sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
    sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
    sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
    sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

CVE-2017-5715 is SPECTRE. The page table isolation fixes MELTDOWN.

Nice ! Thanks Petri Kaukasoina !!

Nothing ready for my Intel 6700K just yet:

Code:

# iucode_tool -S

iucode_tool: system has processor(s) with signature 0x000506e3

I'll be on the lookout though.

-- kjh

bassmadrigal · 01-05-2018, 02:48 PM

Quote:

Originally Posted by kjhambrick

How does one tell the kernel-firmware version ?

The SlackBuild simply appends a `date` stamp when the SlackBuild was run.

I don't think you can tell. The SlackBuild strips all git information from it, including the latest commit. But the SlackBuild does just grab the latest from "master", so if you go through the commit log, just find where your package date falls in and that's what version you're running.

kjhambrick · 01-05-2018, 02:53 PM

Quote:

Originally Posted by bassmadrigal

I don't think you can tell. The SlackBuild strips all git information from it, including the latest commit. But the SlackBuild does just grab the latest from "master", so if you go through the commit log, just find where your package date falls in and that's what version you're running.

Thanks bassmadrigal.

Thats what I read in the SlackBuild.

But Aeterna's version: linux-firmware-20180103-r1 looked completely different than the kernel-firmware version from Pat's SlackBuild soo I wondered if there was a version I missed somewhere on the git site.

-- kjh

Aeterna · 01-05-2018, 03:11 PM

Quote:

Originally Posted by kjhambrick

Thanks bassmadrigal.

Thats what I read in the SlackBuild.

But Aeterna's version: linux-firmware-20180103-r1 looked completely different than the kernel-firmware version from Pat's SlackBuild soo I wondered if there was a version I missed somewhere on the git site.

-- kjh

ehh..
I am sorry kjhambrick, wrong distro (regarding linux firmware version, not that you need all the updates: kernel and firmware or microcode)

keefaz · 01-05-2018, 05:23 PM

Quote:

Originally Posted by Petri Kaukasoina

No, kernel-firmware contains binary blobs to be loaded in the ethernet card and so on.

You get the latest Intel microcode via BIOS updates from the PC vendor, or you can install intel-microcode from slackbuilds.org. Intel has given out new microcode only for some cpus. If you have installed iucode_tool from slackbuilds.org, "iucode_tool -S" prints the processor signature, like 0x000206a7. Only these new microcodes are ready:

Code:

2017-12-15 (unofficial bundle with CVE-2017-5715 mitigation):
  * Updated Microcodes:
    sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
    sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
    sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
    sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
    sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
    sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
    sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
    sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
    sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
    sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

CVE-2017-5715 is SPECTRE. The page table isolation fixes MELTDOWN.

Where did you find this bundle?

Latest is 20171117 at intel website
https://downloadcenter.intel.com/dow...code-Data-File

bassmadrigal · 01-05-2018, 05:31 PM

I don't think they have an official one out. I did find this link through gentoo that might be it.

https://dev.gentoo.org/~whissi/dist/intel-microcode/

slalik · 01-05-2018, 05:34 PM

Quote:

Originally Posted by keefaz

Where did you find this bundle?

For example, here: https://packages.debian.org/source/sid/intel-microcode

More microcodes distributed with bios upgrades, for example, I've seen revision c2 for 506e3.

keefaz · 01-05-2018, 05:34 PM

Quote:

Originally Posted by bassmadrigal

I don't think they have an official one out. I did find this link through gentoo that might be it.

https://dev.gentoo.org/~whissi/dist/intel-microcode/

Thanks, I think I'll wait for an official release

willysr · 01-05-2018, 05:48 PM

Linux Kernel 4.14.12 has released with some notes:

Quote:

There are a few minor issues still known with this release that people
have run into. Hopefully they will be resolved this weekend, as the
patches have not landed in Linus's tree.

For now, as always, please test your in environment.

bamunds · 01-05-2018, 06:29 PM

The Intel location has a really comprehensive list of Intel CPU's and the tar file once exploded has a release_note file which explains two methods of using the 11-17-2017 firmware. My Pentium D 820 is included in that file, per the Intel web site. However, the instruction talk about using microcode.dat or the intel-ucode directory.

1) IS it correct that Slackware is using the microcode.dat in /dev/cpu/ rather than placing the firmware in /lib/firmware/intel-ucode, since Slackware64 14.2 has /lib/firmware/intel but not intel-ucode?
1a) Do the owner and groups also need to be changed when using "# dd if=microcode.dat of=/dev/cpu/microcode bs=1M" ?

2) Does the 11-17-2017 microcode have the meltdown/spectre fix if the kernel also is fixed? Or are we still waiting on Intel to fix the microcode?

3) Iucode_tools tells me the processor code but not the microcode firmware version date. Is there a way to tell the loaded version date?

4) ls /var/log/packages is telling me I have multile kernel-firmware-xxxxxxxxx-noarch-1 files loaded, because I always have used the recommended approach of installpkg for all things kernel. But isn't this redundant for this one kernel file, ie aren't all the firmware files inclusive of previous version plus the newest firmware, so really there should be only one kernel-firmware on the system at any one time?

Always learning and learning. Cheers.

Always learning.

bassmadrigal · 01-05-2018, 06:43 PM

Can't answer all of these...

Quote:

Originally Posted by bamunds

1) IS it correct that Slackware is using the microcode.dat in /dev/cpu/ rather than placing the firmware in /lib/firmware/intel-ucode, since Slackware64 14.2 has /lib/firmware/intel but not intel-ucode?

AFAIK, Intel microcode can only be applied via BIOS/UEFI updates or as part of your initrd. It can't be loaded on the fly like AMD's microcode can (which gets distributed with the kernel-firmware package).

Quote:

Originally Posted by bamunds

2) Does the 11-17-2017 microcode have the meltdown/spectre fix if the kernel also is fixed? Or are we still waiting on Intel to fix the microcode?

Pretty sure it doesn't. There's a 15 DEC 2017 version floating around, but as far as I know, it is unofficial (possibly put out by Intel, but not as an official release).

Quote:

Originally Posted by bamunds

4) ls /var/log/packages is telling me I have multile kernel-firmware-xxxxxxxxx-noarch-1 files loaded, because I always have used the recommended approach of installpkg for all things kernel. But isn't this redundant for this one kernel file, ie aren't all the firmware files inclusive of previous version plus the newest firmware, so really there should be only one kernel-firmware on the system at any one time?

That's correct. You only need one kernel-firmware package. You should always "installpkg" kernel-generic, kernel-huge, kernel-modules, and kernel-source. kernel-firmware can be upgraded because it all resides in the same location.

You can safely remove all older kernel-firmware packages. removepkg is smart enough to not remove any files that exist in any other packages, so if the filenames didn't change at all, it would just remove the entry from /var/log/packages/.

keefaz · 01-05-2018, 07:41 PM

Quote:

Originally Posted by bassmadrigal

Can't answer all of these...

AFAIK, Intel microcode can only be applied via BIOS/UEFI updates or as part of your initrd. It can't be loaded on the fly like AMD's microcode can (which gets distributed with the kernel-firmware package).

In fact yes there is a method to load microcode in a running system but it's considered as unsafe in README file installed with iucode_tool package.

Quote:

***** WARNING ***** the method below is unsafe ***** WARNING *****
1. Place the binary microcode in /lib/firmware/ with the correct
file name (iucode_tool -K can do this automatically for Intel
microcode);

2. Trigger a microcode refresh action, either by the initial load
of the kernel "microcode" module, or if it is already loaded,
by running the shell commands:

(Linux v3.6 and later)
echo 1 > /sys/devices/system/cpu/microcode/reload

For intel, firmware microcode files go in /lib/firmware/intel-ucode/

Loomx · 01-05-2018, 08:11 PM

Quote:

3) Iucode_tools tells me the processor code but not the microcode firmware version date. Is there a way to tell the loaded version date?

Try this; it should be one of the first lines:

Code:

dmesg | head

bassmadrigal · 01-05-2018, 08:32 PM

Quote:

Originally Posted by BratPit

Quick and dirty explanation of Meltdown.

https://medium.com/@pwnallthethings/...n-1189548f1e1d

That was a crazy read, but it was put forward really well and made it easier to understand what's going on. It's amazing that people even figured out that this was possible.

bamunds · 01-05-2018, 09:02 PM

Quote:

Originally Posted by Loomx

Try this; it should be one of the first lines:

Code:

dmesg | head

That didn't work. dmesg | less is showing:

[ 0.000000] DMI: emachines T5224/D945GCL, BIOS CF94510J.15A.0028.2006.1213.1629 12/13/2006

which is a very old BIOS.
What should the microcode line look like?