See the info in post #16 on how to check.... What you've posted isn't enough information.... You should be able to cross reference the info gathered in post #16 to check properly.
[URGENT] Intel downfall / AMD Inception kernel security updates & microcode
- Thread starter CRCinAU
- Start date
See the info in post #16 on how to check.... What you've posted isn't enough information.... You should be able to cross reference the info gathered in post #16 to check properly.
we do: but the list from intel is not clear, is can be the last microcode, but there is no info about mitigation of this issue or about this microcode is the only last available for this cpu.
we wonder bebause on intel we get for our cpu:
"2023.3: 0xf4"
but in dmesg:
[ 0.000000] microcode: microcode updated early to revision 0xf4, date = 2022-07-31
[ 1.641541] microcode: sig=0x906ed, pf=0x2, revision=0xf4
[ 1.644172] microcode: Microcode Update Driver: v2.2.
the date is what we wonder about. also we have
intel-microcode is already the newest version (3.20230214.1~deb10u1)
and debian says: https://security-tracker.debian.org/tracker/CVE-2022-40982
we have:
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
stepping : 13
microcode : 0xf4
so the information are not clear we think.
so we have to ask what do you think, does revision 0xf4 mitigates the CVE-2022-40982 ?
we wonder bebause on intel we get for our cpu:
"2023.3: 0xf4"
but in dmesg:
[ 0.000000] microcode: microcode updated early to revision 0xf4, date = 2022-07-31
[ 1.641541] microcode: sig=0x906ed, pf=0x2, revision=0xf4
[ 1.644172] microcode: Microcode Update Driver: v2.2.
the date is what we wonder about. also we have
intel-microcode is already the newest version (3.20230214.1~deb10u1)
and debian says: https://security-tracker.debian.org/tracker/CVE-2022-40982
| buster/non-free | 3.20220510.1~deb10u1 | vulnerable | |
| buster/non-free (security) | 3.20230214.1~deb10u1 | vulnerable | |
| bullseye/non-free | 3.20230214.1~deb11u1 | vulnerable |
we have:
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
stepping : 13
microcode : 0xf4
so the information are not clear we think.
so we have to ask what do you think, does revision 0xf4 mitigates the CVE-2022-40982 ?
Last edited:
This should translate to 06_9FH - which isn't listed on the Intel site at all. The "Stepping" would be D (in hex = 13 decimal)
Thinking further, you might have to wait for a kernel update that adds the path for `/sys/devices/system/cpu/vulnerabilities/gather_data_sampling` to be able to tell.
On kernel 6.4.10, I see:
Code:
# cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Not affected
Last edited:
we have no new kernel with debian 10 and proxmox 6 (yes we know, upgrade to 7, but impossible yet).
so we get
cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
cat: /sys/devices/system/cpu/vulnerabilities/gather_data_sampling: No such file or directory
cat /proc/version
Linux version 5.4.203-1-pve (build@proxmox) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.203-1 (Fri, 26 Aug 2022 14:43:35 +0200)
Our CPU is (get from cpuinfo)
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
stepping : 13
microcode : 0xf4
cpu MHz : 4674.055
cache size : 16384 KB
physical id : 0
siblings : 16
core id : 5
cpu cores : 8
apicid : 11
06-9E Revision D (stepping : 13), intel says 0xfa for revision D, but we get 0xf4
we wonder also because
https://github.com/intel/Intel-Linu...mmit/6788bb07eb5f9e9b83c31ea1364150fe898f450a
| CFL-H | R0 | 06-9e-0d/22 | 000000f8 | 000000fa | Core Gen9 Mobile
the old microcode version is 000000f8
but we are on 0xf4 , this can not be the old version.
we are very confused.
so we get
cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
cat: /sys/devices/system/cpu/vulnerabilities/gather_data_sampling: No such file or directory
cat /proc/version
Linux version 5.4.203-1-pve (build@proxmox) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.203-1 (Fri, 26 Aug 2022 14:43:35 +0200)
Our CPU is (get from cpuinfo)
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
stepping : 13
microcode : 0xf4
cpu MHz : 4674.055
cache size : 16384 KB
physical id : 0
siblings : 16
core id : 5
cpu cores : 8
apicid : 11
06-9E Revision D (stepping : 13), intel says 0xfa for revision D, but we get 0xf4
we wonder also because
https://github.com/intel/Intel-Linu...mmit/6788bb07eb5f9e9b83c31ea1364150fe898f450a
| CFL-H | R0 | 06-9e-0d/22 | 000000f8 | 000000fa | Core Gen9 Mobile
the old microcode version is 000000f8
but we are on 0xf4 , this can not be the old version.
we are very confused.
Ah - more like upgrade to 8
After a bit of hunting, fixed kernel versions are:
* 6.4.9
* 6.1.44
* 5.15.125
* 5.10.189
* 4.19.290, and
* 4.14.321
Anything older than these or in a different release branch won't get the kernel patches...
Last edited:
yes 8 , but this did not solve our problems because yet we can not update. so we do microcode updates and reboots. but we wonder, see abough.
may the 2023.3: 0xfa is a typo and it has to be 0xf4
because we never find 0xfa in other cpus or in update files (google microcode "0xfa" intel).
, but this did not solve our problems because yet we can not update. so we do microcode updates and reboots. but we wonder, see abough.| 06_9EH | D |
|
|
| 906ED | 2023.3: 0xfa | MCU |
because we never find 0xfa in other cpus or in update files (google microcode "0xfa" intel).
Last edited:
yes 8
may the 2023.3: 0xfa is a typo and it has to be 0xf4
06_9EH D
- Coffee Lake H
- Coffee Lake Xeon E
- Coffee Lake S
- 9th Generation Intel® Core™ Processor Family
- Intel® Xeon® E processor family
- 9th Generation Intel® Core™ Processor Family
- Mobile
- Workstation
AMT Server- Desktop
906ED 2023.3: 0xfa MCU
because we never find 0xfa in other cpus or in update files (google microcode "0xfa" intel).
Oh god - I'm a moron hahahaha 9E == 158 - not 9F..... Don't worry about me..... Yeah - that is your CPU hahahah - and no, it will be `0xfa` - which is newer than `0xf4`
You can also get the microcode directly from: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/
welcome , no worry
0xfa i have never seen and we wonder, because we are on 0xf4 with fresh updates and reboot.
0xf4 seems not to be an old version. and if, how can we upgrade to 0xfa ?
we have /lib/firmware/intel-ucode , all file in there are from april.
intel-microcode is already the newest version (3.20230214.1~deb10u1)
so wonder about that we are on 0xf4
so may intel has a typo?
0xfa i have never seen and we wonder, because we are on 0xf4 with fresh updates and reboot.
0xf4 seems not to be an old version. and if, how can we upgrade to 0xfa ?
we have /lib/firmware/intel-ucode , all file in there are from april.
intel-microcode is already the newest version (3.20230214.1~deb10u1)
so wonder about that we are on 0xf4
so may intel has a typo?
Likely not the fixed versions.
Follow the instructions from the Intel github link above and see what microcode version you end up with then...
Yes, but we can not do experiments because it is a productive environment.
so we have to wait for
https://security-tracker.debian.org/tracker/CVE-2022-40982
3.20230214.1~deb10u1 update.
PVE 6.X has been EOL for more than one year now - and we won't publish updated kernels for it (the microcode update might become available through Debian though)
I skimmed through the Ubuntu repositories and it seems they released their latest tags without any fixes for AMD Inception (a.k.a SRSO a.k.a CVE-2023-20569).@Stoiko Ivanov Thanks for your work on Intel Downfall
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?
Since we had one report (for different setup running Debian on the host) - where the SRSO fixes (which are in the latest Debian kernel, and in the stable releases of kernel.org) seems to potentially cause issues:
https://forum.proxmox.com/threads/amd-incpetion-fixes-cause-qemu-kvm-memory-leak.132057/
we still would need to take a closer look for this
I decided to take the security/stability tradeoff and build Proxmox kernel packages based on upstream kernel version 6.4.12, which includes the latest Inception/SRSO mitigations. If anyone would like to do the same, here are the changes I made to the pve-kernel build tooling, and the steps to run a build: https://github.com/jprenken/pve-kernel-upstream