[URGENT] Intel downfall / AMD Inception kernel security updates & microcode

C

CRCinAU

Well-Known Member
May 4, 2020
120
36
48
crc.id.au
Last edited:
On a quick read of the https://downfall.page/ it seems that installing the updated intel-microcode should fix the vulnerability.

While these are not in bookworm yet - they have been releaed in sid though:
https://security-tracker.debian.org/tracker/CVE-2022-40982

You can install the intel-microcode package from there - or wait a few days (usually those things transition quite fast to bookworm-security (and bullseye-security for PVE 7.x))
See https://forum.proxmox.com/threads/zenbleed-cve-2023-20593.131164/post-576011 (for a similar recent issue)
 
  • Like
Reactions: VictorSTS
Stoiko Ivanov said:
On a quick read of the https://downfall.page/ it seems that installing the updated intel-microcode should fix the vulnerability.
Click to expand...

It's kind of both - from the changelog of kernel 6.4.9 release:

Borislav Petkov (AMD) (8):
x86/bugs: Increase the x86 bugs vector size to two u32s
x86/srso: Add a Speculative RAS Overflow mitigation
x86/srso: Add IBPB_BRTYPE support
x86/srso: Add SRSO_NO support
x86/srso: Add IBPB
x86/srso: Add IBPB on VMEXIT
x86/srso: Add a forgotten NOENDBR annotation
x86/srso: Tie SBPB bit setting to microcode patch detection

Daniel Sneddon (4):
x86/speculation: Add Gather Data Sampling mitigation
x86/speculation: Add force option to GDS mitigation
x86/speculation: Add Kconfig option for GDS
KVM: Add GDS_NO support to KVM
Click to expand...
 
I guess for proxmox 7 I should better wait instead of trying a sid version? And if I wouldn't want to wait how to install it safely to a proxmox 7 server since it's meant for sid?
 
CRCinAU said:
I still haven't seen the update come through for either kernel or firmware / microcode :|
Click to expand...
Make sure you have "non-free" at the package list in file /etc/apt/sources.list in proxmox 7, or "non-free-firmware" if you are using proxmox 8.

In proxmox 7 it should be like this:
Bash: 
deb http://ftp.debian.org/debian bullseye main contrib non-free
deb http://ftp.debian.org/debian bullseye-updates main contrib non-free
deb http://security.debian.org bullseye-security main contrib non-free

In proxmox 8:

Bash: 
deb http://ftp.debian.org/debian bookworm main contrib non-free-firmware
deb http://ftp.debian.org/debian bookworm-updates main contrib non-free-firmware
deb http://security.debian.org bookworm-security main contrib non-free-firmware
 
Yep, I have:

/etc/apt/sources.list
Code: 
deb http://ftp.au.debian.org/debian bookworm main contrib
deb http://ftp.au.debian.org/debian bookworm-updates main contrib
deb http://security.debian.org bookworm-security main contrib

/etc/apt/sources.list.d/pve-no-subscription.list
Code: 
deb http://download.na.cdn.proxmox.com/debian/pve bookworm pve-no-subscription

I added `non-free-firmware` to each line - but it looks like the microcode package wasn't even installed.....

So, I ran: `apt-get update && apt-get install intel-microcode`

I'm not quite sure how to check the mitigations are ok though - as in the updated kernel, you get:

Code: 
# cd /sys/devices/system/cpu/vulnerabilities && grep . *
gather_data_sampling:Not affected
itlb_multihit:KVM: Mitigation: VMX disabled
l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
mds:Mitigation: Clear CPU buffers; SMT disabled
meltdown:Mitigation: PTI
mmio_stale_data:Mitigation: Clear CPU buffers; SMT disabled
retbleed:Mitigation: IBRS
spec_rstack_overflow:Not affected
spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl
spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2:Mitigation: IBRS, IBPB: conditional, STIBP: disabled, RSB filling, PBRSB-eIBRS: Not affected
srbds:Vulnerable: No microcode
tsx_async_abort:Mitigation: Clear CPU buffers; SMT disabled

However, the PVE kernel doesn't have the `gather_data_sampling` entry to see what is going on....

I can't see any mentions of microcode in dmesg or journalctl -b....
 
Last edited:
CRCinAU said:
/etc/apt/sources.list
Click to expand...
the firmware packages are in the `non-free-firmware` component of the repositories - e.g.:
Code: 
deb http://ftp.at.debian.org/debian bookworm main contrib non-free-firmware
for bookworm and later releases

for bullseye and earlier they were in the '`non-free` component

EDIT: added mention of the change in bookworm
 
Last edited:
Stoiko Ivanov said:
the firmware packages are in the `non-free-firmware` component of the repositories - e.g.:
Click to expand...
Yeah - correct.... I added the `non-free-firmware` part to each line in /etc/apt/sources.list

The debian wiki (https://wiki.debian.org/Microcode) has 3 different ways to check, but none of them return anything - so I'm not sure how to check if the updated microcode was loaded....
 
  • Like
Reactions: logopk
after installing the intel-microcode (similarly for the amd64-microcode) package - you need to reboot the node.
the initramfs needs to be regenerated - but this should happen by the post-install script of the microcode package

else - read through the journal after the reboot - there should be a mention about the loaded microcode.
 
Yeah - that's what I'd think too:

Code: 
# dmesg | grep -i microcode
[    4.412471] microcode: Microcode Update Driver: v2.2.
# journal -b | grep -i microcode
Aug 11 23:32:21 syd-pm kernel: microcode: Microcode Update Driver: v2.2.

It did regenerate the initramfs in the package installation - but just to confirm, I ran `update-initramfs -c -k all` again and rebooted.....

Still no mention beyond the above....
 
Stoiko Ivanov said:
I sent an initial patch to the pve-devel list for review :
https://lists.proxmox.com/pipermail/pve-devel/2023-August/058751.html

once this or an improved version has been built and tested internally it will be shipped to our public repositories
Click to expand...
Nice, thanks for the cherry picks etc.... Hit me up when its out and I'll try and test it all where I can.

It's good that it'll add in `/sys/devices/system/cpu/vulnerabilities/gather_data_sampling` - which afaik, is the only way to easily check if you're vulnerable - and if you are, if the microcode fix has been applied.

The only Intel CPUs I have at the moment are either Fedora systems, or a PM node - so I can't easily tell what has been mitigated, what is vulnerable, and what is just fine.

At least in this way, it'll give people a way to be certain.

It could well be that I don't have a problem - which is why I'm not seeing a microcode load - but at the same time, maybe the microcode load is broken hahhaha. The only way to be sure would be to check after the patch.

EDIT: It also looks like I've got a BIOS update for my only actual server server..... So I've installed that - which may well have the updated microcode in it as well....
 
Last edited:
For those following along, Intel have updated their vulnerable products list:
https://www.intel.com/content/www/u...olidated-product-cpu-model.html#tab-blade-1-0

If you look at /proc/cpuinfo - look for:
Code: 
cpu family      : 6
model           : 63
...
stepping        : 2
microcode       : 0x49

To look this up in the tables on the Intel web site - the CPUID Family_Model column is <cpu family>_<model in hex>H

So for my CPU in this example, 6_63 (in decimal) == 6_3FH (in hex).

The MCU Update column tells you the latest microcode version - mine shows 0x49 - so I'm running the latest available microcode.

It also tells me in the GDS/Downfall column: Not Affected. So yay for me in this case.

You'll be able to take your details, look them up and see how you go and if you need to apply these updates.

I'd strongly recommend that anyone in a shared hosting environment - where any external party has access to a VM or CT that these updates be done ASAP.
 
Last edited:
@Stoiko Ivanov Thanks for your work on Intel Downfall :) Any idea about a timeline for AMD Inception?
Prior to Zen3 we need kernel mitigation but see no Ubuntu kernel yet with 5.15.125 from Andy & Stefan.
With 6.2 as non-LTS it needs backporting by them first. Do we need to wait for the kernel SRU cadence?
 
Haste makes waste.

Ubuntu depends on Debian and lags behind, apparently having most kernels in "needs triage" state as of today.

The intel microcode 3.20230808.1 is available by:
* https://www.debian.org/security/2023/dsa-5474

To Intel microprocessors this matters most and one was able to install this to Proxmox platforms by early Friday.

Please note for both AMD- und Intel the Debian GNU/Linux kernel (linux) security updates are available since Friday by:
* https://www.debian.org/security/2023/dsa-5475

Responsible fixing and adapting kernel binaries needs time. Proxmox will provide their proprietory kernel binary in due time, I trust.
 
Last edited:
@piefke To be precise Ubuntu doesn't depend on Debian for their kernel but on their kernel team.
For AMD Eypcs with Zen3 and up the mitigations are available via amd64-mircocode => 3.20230719.1
For AMD Eypcs with Zen2 and earlier plus all desktop CPUs like Ryzens we need the kernel update:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html
Hope meanwhile performance impacts of the AMD kernel mitigation will be known via Phoronix & co.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom