Dev1 Galaxy Forum / amd64-microcode update for transient scheduler attacks

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (Matlib) — Fri, 28 Nov 2025 17:55:43 +0000

What's the point of shipping those microcode packages if the packagers themselves do not believe they're safe to apply? And because it's disabled by default, 99.several nines % of users who never look at the /etc/modprobe.d directory don't even know this package does nothing.

Is there a way to download a microcode directly from CPU manufacturer? Duck.ai sais no. There is a github repo with collection of firmwares.

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (stargate-sg1-cheyenne-mtn) — Tue, 02 Sep 2025 14:03:15 +0000

this thread makes me want to dig out my Q6600 and Q8200 quad-core machines...iirc they still have beowulf on spinning rust...sounds like a rainy day endeavour.

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (Altoid) — Mon, 01 Sep 2025 17:14:11 +0000

Hello:

greenjeans wrote:

... in my dmesg there's nothing about microcode until line 488 ...

Well ...

Could be that ... (No idea, just shots in the dark. 8^°)

1. it is an AMD processor. ie: not Intel
2. it is much newer than my Q9550 (released Q1/2008)
3. my CPU gets updated early to a revision number while yours gets the same type of update but to a new patch_level

Note the date on the microcode file (revision 0xa0b, date = 2010-09-28 - 15 years ago) while your patch level is not dated.

Q: do you have the amd64-microcode/stable 3.20240820.1~deb12u1 package installed?

Best,

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (greenjeans) — Mon, 01 Sep 2025 16:29:15 +0000

@Altoid, interesting, in my dmesg there's nothing about microcode until line 488 or so (AMD microcode):

[    3.887181] microcode: microcode updated early to new patch_level=0x05000119
[    3.887366] microcode: CPU0: patch_level=0x05000119
[    3.887388] microcode: CPU1: patch_level=0x05000119
[    3.887403] microcode: Microcode Update Driver: v2.2.

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (rolfie) — Sun, 31 Aug 2025 19:23:31 +0000

Is Devuan in process of putting this update into the Daedalus repos?

Definitely not. The Daedalus repo will only be updated if there is an update coming from the Debian repo.
Devuan is Debian w/o systemd, only parts that have relation to systemd are replaced or modified.

Anyhow, if I read the document correctly the main fix is an bios update.

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (Altoid) — Sun, 31 Aug 2025 19:06:33 +0000

Hello:

greenjeans wrote:

After installing the microcode package ...

These are the first two lines in my dmesg printout:

$ sudo dmesg | more
groucho@devuan:~$ sudo dmesg
[    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
[    0.000000] Linux version 6.1.0-38-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14+deb12u1) ...
--- snip ---
$

ie: first the microcode and then the kernel

Further on, I get this:

$ sudo dmesg | more
--- snip ---
[    0.155960] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
--- snip ---
[    3.399828] microcode: sig=0x1067a, pf=0x10, revision=0xa0b
[    3.400056] microcode: Microcode Update Driver: v2.2.
--- snip ---
$

I also have the intel-microcode package installed and the module blacklisted in /etc/modprobe.d.

$ apt list | grep installed | grep intel-microcode
--- snip ---
intel-microcode/stable-security,now 3.20250512.1~deb12u1 amd64 [installed]
$

The directory /lib/firmware/intel-ucode has 125 files in it, all with a Modify time = May 18 20:06, so they receive updates.

Some insight from Intel:

intel / Intel-Linux-Processor-Microcode-Data-Files @github.com wrote:

OS vendors may choose to provide an MCU that the kernel can consume for early loading. For example, Linux can apply an MCU very early in the kernel boot sequence. In situations where a BIOS update isn't available, early loading is the next best alternative to updating processor microcode. Microcode states are reset on a power reset, hence its required that the MCU be loaded every time during boot process.

I'd say that the module is blacklisted so that only the kernel deals with the respective microcode file at the very start of the boot process.
Just an edguess.

Best,

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (greenjeans) — Sun, 31 Aug 2025 16:21:22 +0000

Firstly, this is NOT an area in which I have great skills or knowledge, so take it with a grain of salt. It's just that I noticed something months ago and am sharing it, forgive me if it's common knowledge. I don't know if it throws a wrench into the process or not.

After installing the microcode package, it throws up a file in /etc/modprobe.d, amd64-microcode-blacklist.conf, which reads thusly:

# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

It does this with intel microcode as well.

I only know about that because I use that folder to blacklist wdat_wdt.

Re: amd64-microcode update for transient scheduler attacks

dummy@example.com (EDX-0) — Sun, 31 Aug 2025 01:22:51 +0000

if i'm not mistake that is a firmware update, either your need to wait until your board vendor releases an update and install manually, or wait a while and check if it is going to be added to the LVFS database to update with fwupd, mind you not all OEM vendors upload every firmware and microcode updates to LVFS nor upload them in a short time from releaseing the updates, could be anything from days to even a year it all depends on how well the vendor, in this case AMD supports the Linux Vendor Firmware Service.

in my experience the support is not great not terrible, in a couple of ocassions i've had firmware updates for my HP ProBook 445 G7 that runs on an AMD ryzen 7 4700U installable via fwupd, for many others however i've had to install the updates from HP via the uefi update menu

https://wiki.debian.org/Firmware/Updates

amd64-microcode update for transient scheduler attacks

dummy@example.com (rmrichesjr) — Sat, 30 Aug 2025 22:41:38 +0000

On an AMD Ryzen 7 5800 machine running Devuan Daedalus, I just updated to kernel 6.1.0-38-amd64 and now see a report in dmesg: "Transient Scheduler Attacks: Vulnerable: Clear CPU buffers attempted, no microcode". There is a similar message in the output of lscpu. I have the amd64-microcode package installed, version 3.20240820.1~deb12u1, which was an updated version from the version initially installed in Daedalus. The fact that I got an updated version at some point after installation would seem to indicate I have apt sources set up correctly to get updates to that package.

From https://www.amd.com/en/resources/produc … -7029.html it appears AMD has released a microcode update a few weeks ago. Is Devuan in process of putting this update into the Daedalus repos?