linux-kernel - Re: Apollo Lake with newer microcode: not affected by meltdown anymore?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.21.1808281435050.31480@er-systems.de>
Date:   Tue, 28 Aug 2018 14:35:18 +0200 (CEST)
From:   Thomas Voegtle <tv@...96.de>
To:     Thomas Gleixner <tglx@...utronix.de>
cc:     x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: Apollo Lake with newer microcode: not affected by meltdown
 anymore?

On Tue, 28 Aug 2018, Thomas Gleixner wrote:

> On Tue, 28 Aug 2018, Thomas Voegtle wrote:
>> Kernel 4.18.5 with old microcode:
>>
>> [    0.000000] microcode: microcode updated early to revision 0x2c, date =
>> 2017-03-25
>> cat /sys/devices/system/cpu/vulnerabilities/meltdown
>> Mitigation: PTI
>>
>>
>> Kernel 4.18.5 with new microcode (microcode-20180807.tgz), same config:
>>
>> [    0.000000] microcode: microcode updated early to revision 0x32, date =
>> 2018-05-11
>> cat /sys/devices/system/cpu/vulnerabilities/meltdown
>> Not affected
>>
>>
>> This happens with 4.14.y and 4.9.y as well.
>>
>> The same with ssb:
>> old microcode: spec_store_bypass:Vulnerable
>> new microcode: spec_store_bypass:Not affected
>>
>> Is this intentional behavior? I have never seen this on other CPUs, such
>> as Gemini Lake or Baytrail, Haswell etc.
>
> Looks like the micro code update has the relevant bits set in the
> IA32_ARCH_CAPABILITIES MSR, which tell the kernel that the CPU is not
> vulnerable. So it seems Intel was able to mitigate the mess in micro code
> for this particular CPU model.

Ah, ok.
Didn't think of the most obvious.
But yes RDCL_NO is set to 1 with the new microcode. Wow.

Thanks and sorry for the noise,

   Thomas