LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-10-2018, 03:59 PM   #61
horizn
Member
 
Registered: Jan 2015
Location: UK and Poland
Distribution: Slackware + Debian + Ubuntu
Posts: 112

Rep: Reputation: Disabled

Quote:
Originally Posted by keefaz View Post
Best way it to make ramfs image imho.
iucode_tool has to be installed from sbo / Slackbuilds

Then, infos from /proc/cpuinfo will give you the correct microcode filename (see awk code above)

Once you know the correct microcode file, the easiest way to make the ramfs image is:
Code:
iucode_tool --write-earlyfw=/boot/intel-ucode.cpio /path/to/microcode_file
If you have already an initrd you have to merge it with intel-ucode.cpio image
Code:
cd /boot
cat intel-ucode.cpio initrd.gz > initrd-merged.gz
Then replace initrd.gz with initrd-merged.gz in lilo.conf

Edit: Wow posted too late again :/
This doesn't work for me. Before and after:

Code:
Spectre and Meltdown mitigation detection tool v0.24                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                               
Checking for vulnerabilities against live running kernel Linux 4.4.88 #1 SMP Thu Sep 14 14:07:01 CDT 2017 x86_64                                                                                                                                                               
                                                                                                                                                                                                                                                                               
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'                                                                                                                                                                                                                    
* Checking count of LFENCE opcodes in kernel:  UNKNOWN  (couldn't find your kernel image in /boot, if you used netboot, this is normal)                                                                                                                                        
> STATUS:  UNKNOWN  (impossible to check )                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                               
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'                                                                                                                                                                                                                
* Mitigation 1                                                                                                                                                                                                                                                                 
*   Hardware (CPU microcode) support for mitigation:  NO                                                                                                                                                                                                                       
*   Kernel support for IBRS:  NO                                                                                                                                                                                                                                               
*   IBRS enabled for Kernel space:  NO                                                                                                                                                                                                                                         
*   IBRS enabled for User space:  NO                                                                                                                                                                                                                                           
* Mitigation 2                                                                                                                                                                                                                                                                 
*   Kernel compiled with retpoline option:  NO                                                                                                                                                                                                                                 
*   Kernel compiled with a retpoline-aware compiler:  NO                                                                                                                                                                                                                       
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)                                                                                                                                                      
                                                                                                                                                                                                                                                                               
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'                                                                                                                                                                                                           
* Kernel supports Page Table Isolation (PTI):  NO                                                                                                                                                                                                                              
* PTI enabled and active:  NO                                                                                                                                                                                                                                                  
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                               
A false sense of security is worse than no security at all, see --disclaimer
 
Old 01-10-2018, 04:01 PM   #62
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 420

Original Poster
Rep: Reputation: 91
@Darth Vader, Actually I'm not sure it is updated. Going only on the date stamp of the 0f-04-07 file. Although I'm surprised that there have been NO revisions to 0f-04-07 from the initial release of the BIOS microcode of 2006! Thus my concern that maybe I did some step incorrectly. Is there a way to test if the intel-ucode.cpio file is being loaded before the initrd?

Found my own answer in previous thread https://www.linuxquestions.org/quest...rs-4175608636/ post# 12 by phenixia2003. and running the command I get:
Code:
root@Hicrest1:~# cpio -it < /boot/initrd-custom-4.4.110_ucode.gz
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
3154 blocks
So I'm open to other ideas

Last edited by bamunds; 01-10-2018 at 04:28 PM. Reason: code to check if cpio is loading.
 
Old 01-10-2018, 04:06 PM   #63
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 420

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by horizn View Post
This doesn't work for me. Before and after:..(snip)
The tool you are using is not relevant for finding if the newest microcode is being loaded. You will get better support for using the tool and mitigation of Meltdown/Spectre by posting to thread titled Greg K-H Meltdown and Spectre at https://www.linuxquestions.org/quest...el-4175621133/

Thanks.
 
Old 01-10-2018, 04:39 PM   #64
keefaz
LQ Guru
 
Registered: Mar 2004
Distribution: Slackware
Posts: 5,650

Rep: Reputation: 498Reputation: 498Reputation: 498Reputation: 498Reputation: 498
Quote:
Originally Posted by bamunds View Post

So I'm thinking that nothing was loaded. But maybe this simply indicates that no revisions are available to that CPU processor which would be consistent with Intel's statement that only CPU's from past five years will be available this week and all other processors hopefully by end of January.

Any other ideas?
I made quick & dirty perl script to read rev version and date from intel microcode files
Code:
#!/usr/bin/perl

$f = shift or die "Usage: $0 microcode_file...\n";
open $fh, '<:raw', $f or die $!;
read $fh, $b, 16 or die $!;
($header, $rev, $date, $sig) = unpack 'V V V V', $b;
close $fh;
($m,$d,$y) = unpack 'A2 A2 A4', sprintf "%08x", $date;
printf "cpu sig: 0x%02x, revision: 0x%02x, date: %s-%s-%s\n", $sig, $rev, $y, $m, $d;
When I run it with microcode file for your processor I get:
Code:
./script.pl /path/to/0f-04-07 
rev: 0x03 date: 04212005
So it seems the last update was rev 0x03 from April 21, 2005

Last edited by keefaz; 01-10-2018 at 06:20 PM. Reason: only need to read 16 bytes, nicer output format, added cpu sig
 
1 members found this post helpful.
Old 01-10-2018, 04:48 PM   #65
keefaz
LQ Guru
 
Registered: Mar 2004
Distribution: Slackware
Posts: 5,650

Rep: Reputation: 498Reputation: 498Reputation: 498Reputation: 498Reputation: 498
Quote:
Originally Posted by horizn View Post
This doesn't work for me. Before and after:
It doesnt find your kernel in /boot because it has no test for vmlinuz filename (although I'm not sure why it doesn't find /boot/vmlinuz-$(uname -r) )
add the test here:
Code:
# try to find the image of the current running kernel
[ -e /boot/vmlinuz      ] && img=/boot/vmlinuz
[ -e /boot/vmlinuz-linux       ] && img=/boot/vmlinuz-linux
[ -e /boot/vmlinuz-$(uname -r) ] && img=/boot/vmlinuz-$(uname -r)

Last edited by keefaz; 01-10-2018 at 04:51 PM.
 
Old 01-10-2018, 04:48 PM   #66
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 101

Rep: Reputation: Disabled
Quote:
Originally Posted by bamunds View Post
The tool you are using is not relevant for finding if the newest microcode is being loaded. You will get better support for using the tool and mitigation of Meltdown/Spectre by posting to thread titled Greg K-H Meltdown and Spectre at https://www.linuxquestions.org/quest...el-4175621133/

Thanks.
it actually shows that new microcode is not loaded:
if new microcode is not loaded you will see

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: NO


if new microcode is loaded you should see
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation: YES

in other words it works as well as the method you are using e.g.:
dmesg -t |grep 'microcode'

in fact his way of doing things is better because at least it shows that new microcode fixes what is supposed to fix (still waiting for IBRS update in the kernel though)

Last edited by Aeterna; 01-10-2018 at 04:49 PM.
 
Old 01-10-2018, 05:05 PM   #67
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 493

Rep: Reputation: 118Reputation: 118
Quote:
Originally Posted by keefaz View Post
Code:
cd /boot
cat intel-ucode.cpio initrd.gz > initrd-merged.gz
Then replace initrd.gz with initrd-merged.gz in lilo.conf

Edit: Wow posted too late again :/
Even though the command ran without errors and my initrd-XXXX.gz grew from 5.7 MB to 7.3 MB its still not loading. Thanks for the help anyways. I'll keep it moving without it.
 
Old 01-10-2018, 05:19 PM   #68
keefaz
LQ Guru
 
Registered: Mar 2004
Distribution: Slackware
Posts: 5,650

Rep: Reputation: 498Reputation: 498Reputation: 498Reputation: 498Reputation: 498
Quote:
Originally Posted by PROBLEMCHYLD View Post
Even though the command ran without errors and my initrd-XXXX.gz grew from 5.7 MB to 7.3 MB its still not loading. Thanks for the help anyways. I'll keep it moving without it.
Maybe just redo the initrd:
Code:
cd /boot
iucode_tool -S --write-earlyfw=intel-ucode.cpio /lib/firmware/intel-ucode/
cat intel-ucode.cpio initrd_4.14.12-smp.gz > initrd-XXXX.gz
Edit lilo.conf and run lilo (if initrd name has changed), reboot.
If it still doesn't load the new microcode, I'll have no clue

Last edited by keefaz; 01-10-2018 at 05:34 PM.
 
Old 01-10-2018, 05:21 PM   #69
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 420

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by Aeterna View Post
..(snip)
in other words it works as well as the method you are using e.g.:
dmesg -t |grep 'microcode'
Thank you for answering the question and providing support.
Interesting.
Please use this thread for loading and verifying Intel microcode and not about Meltdown or Spectre mitigation.
Please direct question about threats to the proper security thread so this thread doesn't become a focus for questions about those threats or any new threat that may be "fixed" by new microcode. I'm hoping a "How to update Intel Microcode" article will be written for docs.slackware.com from the information shared here about that specific article.
Cheers.
 
Old 01-10-2018, 05:25 PM   #70
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 420

Original Poster
Rep: Reputation: 91
Quote:
Originally Posted by keefaz View Post
I made quick & dirty perl script to read rev version and date from intel microcode files
...(snip)...So it seems the last update was rev 0x03 from April 21, 2005
Thanks @keefaz, appreciate the helpful script. Now I can truly expect that this CPU will be a late January update, if even then. But at least I also know I'm loading the microcode and doing the step correctly. AND I have a tool to check Intel's microcode releases for any change for this processor.
Code:
root@Hicrest1:# ./intel-ucode-checker.pl /lib/firmware/intel-ucode/0f-04-07
rev: 0x03 date: 0421200
The only issue would be incorrectly identified the CPU signature, but using a simle dmesg | grep micro gives me the signature in 0xf47 and after dropping the 0x it simply translate remaining to 0f-04-07.

I still need to try the mkinitrd.conf method and see what the steps are to make that work. Cheers

Last edited by bamunds; 01-10-2018 at 05:55 PM. Reason: add results of script tested on Intel 20180108 I've downloaded.
 
Old 01-10-2018, 05:32 PM   #71
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 493

Rep: Reputation: 118Reputation: 118
Spoke too soon.

Last edited by PROBLEMCHYLD; 01-10-2018 at 05:40 PM.
 
Old 01-10-2018, 05:42 PM   #72
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 493

Rep: Reputation: 118Reputation: 118
Quote:
Originally Posted by keefaz View Post
Maybe just redo the initrd:
Code:
cd /boot
iucode_tool -S --write-earlyfw=intel-ucode.cpio /lib/firmware/intel-ucode/
cat intel-ucode.cpio initrd_4.14.12-smp.gz > initrd-XXXX.gz
Edit lilo.conf and run lilo (if initrd name has changed), reboot.
If it still doesn't load the new microcode, I'll have no clue
This put the icing on the cake!!!!!!!!
Thanks, I'll go have a drink since I spent a few hours for a 2 min fix. Thanks

Code:
[root@darkstar:Desktop] # dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0xa4, date = 2010-10-02
[    1.217706] microcode: sig=0x6fd, pf=0x80, revision=0xa4
[    1.221141] microcode: Microcode Update Driver: v2.2.
 
Old 01-10-2018, 05:55 PM   #73
Aeterna
Member
 
Registered: Aug 2017
Location: Terra Mater
Distribution: VM Host: Slackware-current, VM Guests: Artix, CRUX, FreeBSD, Funtoo, HardenedBSD, OpenIndiana
Posts: 101

Rep: Reputation: Disabled
Quote:
Originally Posted by PROBLEMCHYLD View Post
This put the icing on the cake!!!!!!!!
Thanks, I'll go have a drink since I spent a few hours for a 2 min fix. Thanks

Code:
[root@darkstar:Desktop] # dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0xa4, date = 2010-10-02
[    1.217706] microcode: sig=0x6fd, pf=0x80, revision=0xa4
[    1.221141] microcode: Microcode Update Driver: v2.2.
your microcode is too old to fix anything related to Spectre it seems:
date = 2010-10-02

Last edited by Aeterna; 01-10-2018 at 05:56 PM.
 
Old 01-10-2018, 05:57 PM   #74
PROBLEMCHYLD
Member
 
Registered: Apr 2015
Posts: 493

Rep: Reputation: 118Reputation: 118
Quote:
Originally Posted by Aeterna View Post
your microcode is too old to fix anything related to Spectre it seems:
date = 2010-10-02
But its still updated which is a plus+. Thanks guys
 
Old 01-10-2018, 06:11 PM   #75
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware Gentoo ARM (eval)
Posts: 205

Rep: Reputation: 81
As a side note, with all this microcode updating frenzy, which is a natural and understandable reaction, the time and efforts being greatly appreciated, from a general point of view (platform independent), while solid security mechanisms are in place, mechanisms which remind me of UEFI and recently Intel ME, I suggest to double/triple check the sources of the microcode before "playing" around with the CPUs.
A good (recent) lecture on this:
https://www.usenix.org/system/files/...ec17-koppe.pdf
(instead of TL;DR better go for the Chapter 8 - Discussion on page 13/19)

Last edited by abga; 01-10-2018 at 06:27 PM. Reason: 1 little typo
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Is it possible to update intel microcode using kernel-huge and grub2, without initrd? lagavulin16 Slackware 5 01-03-2018 10:27 AM
intel-microcode-20170707 kjhambrick Slackware 1 07-15-2017 09:04 AM
Lenovo Thinkpad x220 - Proprietary Driver for Microcode for Intel processor? wh33t Linux - Hardware 2 06-15-2016 12:41 PM
intel-microcode error Soapm Linux - Newbie 3 06-25-2015 02:37 AM
Intel IA32 CPU microcode...What is it Jester888 Linux - General 1 02-09-2007 12:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:19 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration