Hello Arne, hello *,
Core Update 138 (testing, see: https://blog.ipfire.org/post/ipfire-2-23-core-update-138-is-available-for-te...) is running here for about 24 hours without any unexpected behaviour so far.
Since the CPU of my testing machine (Intel Celeron N3150) is not vulnerable to the attacks recently published, I am unable to confirm mitigations against these:
[root@maverick ~]# grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
The updated vulnerabilities.cgi shows the same situation (I still wonder whether the vulnerability listing follows any sort criterion).
@Arne: I observed multiple rootfile and symbolic link patches for the intel-microcode patch of mine (thank you for this). However, they seem to be deleted - are you sure the microcodes were built and shipped the right way?
This log output suggests an older version to be in place on my machine:
[root@maverick ~]# grep microcode /var/log/bootlog [ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 1.966329] microcode: sig=0x406c3, pf=0x1, revision=0x368 [ 1.966409] microcode: Microcode Update Driver: v2.2.
Output of "uname -a" for reference purposes:
[root@maverick ~]# uname -a Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux
As far as I am concerned, this emergency Core Update is ready for release if the core developers (Arne et al.) are able to confirm the correct behaviour of the microcodes on affected systems or fix these to be reliably loaded.
Thanks, and best regards, Peter Müller
I have also not found any affected system but im sure that the microcode links are recreatad by the last commit of core138.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=699381b6993b9428e99a...
Sometimes git cherry-pick does not the inteded thing if a patch was renamed.
Arne
Am 2019-11-17 19:15, schrieb Peter Müller:
Hello Arne, hello *,
Core Update 138 (testing, see: https://blog.ipfire.org/post/ipfire-2-23-core-update-138-is-available-for-te...) is running here for about 24 hours without any unexpected behaviour so far.
Since the CPU of my testing machine (Intel Celeron N3150) is not vulnerable to the attacks recently published, I am unable to confirm mitigations against these:
[root@maverick ~]# grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
The updated vulnerabilities.cgi shows the same situation (I still wonder whether the vulnerability listing follows any sort criterion).
@Arne: I observed multiple rootfile and symbolic link patches for the intel-microcode patch of mine (thank you for this). However, they seem to be deleted - are you sure the microcodes were built and shipped the right way?
This log output suggests an older version to be in place on my machine:
[root@maverick ~]# grep microcode /var/log/bootlog [ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 1.966329] microcode: sig=0x406c3, pf=0x1, revision=0x368 [ 1.966409] microcode: Microcode Update Driver: v2.2.
Output of "uname -a" for reference purposes:
[root@maverick ~]# uname -a Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux
As far as I am concerned, this emergency Core Update is ready for release if the core developers (Arne et al.) are able to confirm the correct behaviour of the microcodes on affected systems or fix these to be reliably loaded.
Thanks, and best regards, Peter Müller
Hello Arne,
thanks for your quick reply.
I am still puzzled by the output of "grep microcode /var/log/bootlog". Does yours differ from mine, especially when it comes to the microcode release date?
Thanks, and best regards, Peter Müller
Am 2019-11-17 22:41, schrieb Peter Müller:
Hello Arne,
thanks for your quick reply.
I am still puzzled by the output of "grep microcode /var/log/bootlog". Does yours differ from mine, especially when it comes to the microcode release date?
Thanks, and best regards, Peter Müller
Intel has released new microcodes on 15.11.2019
-
Arne Fitzenreiter -
Peter Müller