Intel Microcode 64bit Updates & howto

[ozsouth]

NOTE: As of 2023, many woof-ce built Puppies (BookwormPup64 is one) contain their own microcode files.

A. I have made a 64bit Intel microcode file, offering some protection against Meldown/Spectre etc issues.
Needs to be used in conjunction with a kernel with Meltdown/Spectre mitigation for effective protection.
For usage guide, see section B below. Released 12Nov2024. Tested OK in s15pup64-22.12. Use at own risk.
Is here: https://www.mediafire.com/file/d0p30g0g ... .cpio/file

B. How to use early-loading microcode-update-(x)-64.cpio files in Puppy on 64bit UEFI systems:

EFI folder structure - on boot partition (I use folder micd, as in examples below):
/EFI/BOOT/micd .cpio file goes in folder micd, on same level as folders with initrd.gz

if grub bootloader, initrd line:
initrd /EFI/BOOT/micd/microcode-update-(x)-64.cpio /EFI/BOOT/(folder)/initrd.gz

if syslinux bootloader, initrd line:
initrd micd/microcode-update-(x)-64.cpio,(folder)/initrd.gz

C. Checker:
This seems to updated reasonably often. Looking for an 'all green' result at bottom. Use at own risk.
see: https://github.com/speed47/spectre-melt ... master.zip
After download, unzip in main / folder, then in terminal, cd /spectre-meltdown-checker-master & run ./spectre-meltdown-checker.sh

[ozsouth]

I'm concerned about 'checker' programs' results. I have a celeron n3350, which all the checker programs say is vulnerable to spectre 3a & not mitigated by microcode (nor will be). However, from Intel's own list, dated Jan 2021, n3350 is 'Not Affected' by 3a!
List here: https://software.intel.com/security-sof ... -cpu-model

[user1111]

Isn't Spectre/Meltdown attack vectors rather hit and miss, there are far easier ways/things to attack. Most browsers adjusted their clocks after S/M that largely mitigates attacks. OpenBSD opted to turn off SMP and drop to single core that equally negates the risk.

If you're running a browser even as spot on a system that shares the same X session and has other root windows open, then that is a vastly more likely attack surface.

[peebee]

New version:
https://github.com/intel/Intel-Linux-Pr ... e-20220207

[ozsouth]

There is a test script to see if early loading microcode is working, here:
https://github.com/speed47/spectre-melt ... master.zip

Unzip this in a folder (your folder), then in a terminal (full screen) run

Code: Select all

cd /(your folder)/spectre-meltdown-checker-master

, then run

Code: Select all

./spectre-meltdown-checker.sh

All green at the bottom is the desired result.

[gychang]

How to use microcode-update-(x)-64.cpio files in Puppy on 64bit UEFI systems:

EFI folder structure - on boot partition (I use folder micd, as in examples below):
/EFI/BOOT/micd .cpio file goes in folder micd, on same level as folders with initrd.gz

if grub bootloader, initrd line:
initrd /EFI/BOOT/micd/microcode-update-(x)-64.cpio /EFI/BOOT/(folder)/initrd.gz

if syslinux bootloader, initrd line:
initrd micd/microcode-update-(x)-64.cpio,(folder)/initrd.gz

1. am unsure exactly where the file should go on my UEFI PC. I am running FP64 with intel 7 CPU. my boot loader is sda1 as seen, but my initrd.gz is in sda2/FP64/ (a USB stick)
2. does it matter if I had installed intel-microcode using PPM before?

[mikewalsh]

@ozsouth :-

Oz, does it make any difference whether you're running AS UEFI OR in 'legacy' mode? I take it this applies to the hardware itself, yes, regardless of actual boot method..?

I'm assuming this would work with Fossapup's default kernel, since PupSysInfo shows this about it:-

Code: Select all

itlb_multihit:KVM: Vulnerable
l1tf:Mitigation: PTE Inversion
mds:Mitigation: Clear CPU buffers; SMT vulnerable
meltdown:Mitigation: PTI
spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
swapgs barriers and __user pointer sanitization
spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
srbds:Vulnerable: No microcode
tsx_async_abort:Not affected

.....and does anything else need to be installed first.....BEFORE applying this update?

(This is for a Pentium 'Gold' G5400, 8th-gen 'Coffee Lake'...)

Mike.

[ozsouth]

@gychang - I would make a folder under EFI named micd & put the .cpio file in there. Then you would have to reference it exactly in your grub.cfg as in the 1st post. As I'm not sure how the ppm installed your old .cpio, I would uninstall it and ensure grub.cfg only references the new one.

@mikewalsh - I've set this as an early-load option, so the mode shouldn't matter, just the manner of referencing the .cpio changes according to your bootloader. I haven't looked at very new bootloaders (just syslinux & grub), so there may be syntax changes needed in the future. Nothing needed other than the .cpio now.

NOTE: There is a test script to see if it's working - see here:
viewtopic.php?p=49488#p49488

[mikewalsh]

@ozsouth :-

Oz, is this usable with Grub4DOS? That's what I use throughout the kennels, and don't really want to switch bootloaders simply to use this, y'see....

Just wondering where to place it.

With the 'checker' program, I have solid greens, except for one red....and that's "CVE-2020-0543":-

https://cve.circl.lu/cve/CVE-2020-0543

According to the 'checker', there IS no microcode 'fix' for this one, so what d'you reckon? Should I bother with it, or not?

Mike.

[ozsouth]

@mikewalsh - you should be able to edit your grub.cfg as per 1st post, but you're pretty well covered, so it
may not make much difference. Perhaps try if you feel adventurous - I'd be interested to know if it helps.

[mikewalsh]

@ozsouth :-

@mikewalsh - you should be able to edit your grub.cfg as per 1st post, but you're pretty well covered, so it
may not make much difference. Perhaps try if you feel adventurous - I'd be interested to know if it helps.

Mm. Oh, I may.....I may not. If I do, the thing I need to know is whether Grub4DOS's 'menu.lst' will edit same as GRUB2's 'grub.cfg'. Still, I guess it should, so long as I point the initrd.gz line AT the thing, yes?

I don't suppose it matters too much where the /micd directory goes, does it.....so long as the init line points to it, and in the right sequence. I.e., it wants loading just before the initrd.gz, yes?

------ (later) ------------------

Let me just run this by you, OK? Using your directions as a template, this is my Grub4DOS 'menu.lst' entry for jrb's 'lite' spin on Barry's old Quirky April64, where I'm running Fossapup's k5.4.53 kernel (very sweetly, I might add).

• Sda1 is the FAT32-formatted 'boot' partition (remember, although I run in 'legacy' mode, this IS a modern rig with UEFI as opposed to BIOS) with the Grub4DOS bootloader stuff on it.

• The kennels is sda2, with multiple sub-directories; I've created /micd in Quirky's sub-directory, and placed the .cpio file inside it. This puts it at the same level as Quirky's initrd.gz.

Code: Select all

title Quirky April 64 'lite' (sda2/Quirky7_64_lite)
  find --set-root uuid () b142cd08-ce81-413e-b963-12b393d8eaa3
  kernel /Quirky7_64_lite/vmlinuz  pdrv=b142cd08-ce81-413e-b963-12b393d8eaa3  psubdir=/Quirky7_64_lite pmedia=satahd pfix=fsckp
  initrd /Quirky7_64_lite/micd/microcode-update-20220207.cpio /Quirky7_64_lite/initrd.gz

Look about right to you?

Mike.

[ozsouth]

@mikewalsh - that looks about right. BTW would you please delete my 3 empty posts on page 1 of the thread.
I'm adopting the standard 'see first post' format now.

[mikewalsh]

@mikewalsh - that looks about right. BTW would you please delete my 3 empty posts on page 1 of the thread.
I'm adopting the standard 'see first post' format now.

Uh-huh. Okay; well, I'll fire it up with that modded initrd line tomorrow - I'll backup first, of course! - and we'll see what's what.

BTW; I've removed those three empty posts for you, as requested.

Mike.

[mikewalsh]

@ozsouth :-

It's running fine, Oz. Seems quite happy. I enabled it & re-booted last night before turning-in, and I've just powered-up from an overnight suspend.....no issues.

Basically, nowt to report! As you say; I was pretty much covered anyway.....

Mike.

[Marv]

The early microcode loading should show up in dmesg:

Code: Select all

# dmesg | grep -i microcode
[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
[    0.895169] microcode: sig=0x206a7, pf=0x10, revision=0x2f
[    0.895241] microcode: Microcode Update Driver: v2.2.

That shows the actual code date on what intel has provided for your processor, not the overall code package date. The 2nd gen i5 hasn't been updated by intel since 2019 though there have been several package updates since then.

[Jasper]

@ozsouth

Firstly, thanks for the update.

I am using your latest 6x kernel installed on a USB drive.

[Jasper]

@ozsouth

Apologies, I did not follow your instructions correctly and read the thread again.

It works perfectly

[ozsouth]

New intel microcode file released 15 Feb 2023 - see first post.

[Jasper]

@ozsouth

Thanks once again for the update

[Jasper]

@ozsouth

Any chance of an update?

microcode-20230512 Release

[ozsouth]

New version 16 May 2023. See first post.

[Jasper]

@ozsouth

Many thanks for this

[Jasper]

@ozsouth

If you have some spare time, would it be possible to update this again please?

microcode-20230512-rev2 (Released 13-06-2023)

I have looked at the instructions at how to apply this previously but placing the bin files into the firmware file disappears each reboot.

Thanks in advance

[ozsouth]

New microcode file 13/06/23 - see first post. @Jasper - check your pm.

[peebee]

NOTE: As of 2023, many (all?) woof-ce built Puppies contain their own microcode files.

For clarification: not all - only 64-bit builds and only if _00build.conf contains UCODE_EXEC setting e.g.:
## ucode.cpio initial ram disk with CPU bugfixes
## build the microcode initrd to mitigate aganst cpu bugs like spectre/meltdown
## You can specify 'amd' or 'intel' as args to latest_microcode.sh
## comment out to exclude bulding ucode.cpio
#UCODE_EXEC=../support/latest_microcode.sh amd
#UCODE_EXEC=../support/latest_microcode.sh intel
UCODE_EXEC=../support/latest_microcode.sh

[Jasper]

Thanks guys

@peebee your rolling updates are amazing and always up to the minute. Thanks for the information, I haven't managed to compile a kernel or a Woof-CE build as of yet, so your input is welcome ........... my last attempt I did use your kernel configuration and it compiled successfully (took an hour) but I realised the output was for a full install.

Kudos to you and I do appreciate the work undertaken.

[peebee]

I haven't managed to compile a kernel or a Woof-CE build as of yet, so your input is welcome ........... my last attempt I did use your kernel configuration and it compiled successfully (took an hour) but I realised the output was for a full install.

Perhaps needs to be taken to another thread....
You used the Woof-CE kernel-kit?
You should end up with a zdrv and vmlinuz although with different names (kernel-modules-xxxx.sfs & vmlinuz-xxxx)
Not sure what you mean by "for a full install".....

[ozsouth]

New microcode file 08/08/23 - see first post.

[keniv]

@ozsouth
I have only just seen this and I don't pretend to understand it. I have ucode.cpio that came with BookwormPup 10.0.6 which is contained in a separate ext4 partition on an hdd. I also have Linux Mint 21.3 installed on this hdd. BookwormPup is booted from the version of grub that came with Linux Mint. I believe ucode.cpio is loading at boot up. Below is the output from running dmesg | grep microcode in a terminal.

Code: Select all

# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
[    2.045322] microcode: sig=0x206a7, pf=0x10, revision=0x2f
[    2.045367] microcode: Microcode Update Driver: v2.2

There is a test script to see if early loading microcode is working

I have tried this and I attach the last part of a very long terminal output below.

Code: Select all

* GDS is mitigated by microcode:  NO 
* Kernel supports software mitigation by disabling AVX:  UNKNOWN  (couldn't find your kernel image in /boot, if you used netboot, this is normal)
STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not affected)

CVE-2023-20569 aka 'Inception, return address security (RAS)'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports mitigation:  UNKNOWN  (couldn't find your kernel image in /boot, if you used netboot, this is normal)
* Kernel compiled with SRSO support:  YES 
* Kernel compiled with IBPB_ENTRY support:  YES 
STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not affected)

CVE-2023-23583 aka 'Reptar, redundant prefix issue'
STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not affected)

SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK CVE-2023-20593:OK CVE-2022-40982:OK CVE-2023-20569:OK CVE-2023-23583:OK

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer
# 

All green at the bottom is the desired result.

All of the "SUMMARY" is in green. Nothing in the full output is red. Some comments are in a dark yellow e.g. in the last part of the terminal output shown there is the following line.

Code: Select all

Kernel supports mitigation:  UNKNOWN 

UNKNOWN is in dark yellow. I also attach some details of my CPU

Code: Select all

Processor Name             Intel(R) Pentium(R) CPU B960 @ 2.20GHz
 Signature                  Type 0, Family 6, Model 42, Stepping 7
 External Clock             1333 MHz
 BogoMips                   4390.23
 Min/Max Speed              800/2200 MHz
 Current Speed              Core 0:1360 MHz, 1:2041 MHz
 Core Count                 2
 Thread Count               2
 64-bit capable             Yes

From this information can you please tell a user like me (who does not really understand what is required here) whether my system is protected with the current ucode.cpio
(from the output of the test I think it might be) or whether I have to update it.

Regards,

Ken,

[ozsouth]

@keniv - as Jasper says, all green means protected (as long as you use the latest versions of ucode & tester). I would use the ucode modern pups provide as a preference. I mainly made this for those pups which don't supply ucode & Jasper is continuing it.