Re: Core Update 138 (testing) report

[Arne Fitzenreiter <arne_f@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

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=699381b6993b9428e99a0055dae03e7a222ea9f9

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-testing)
> 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(a)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(a)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(a)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