Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 28 Aug 2018 14:35:18 +0200 (CEST)
From:   Thomas Voegtle <tv@lio96.de>
To:     Thomas Gleixner <tglx@linutronix.de>
cc:     x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@intel.com>
Subject: Re: Apollo Lake with newer microcode: not affected by meltdown
 anymore?
In-Reply-To: <alpine.DEB.2.21.1808281234260.2816@nanos.tec.linutronix.de>
Message-ID: <alpine.LSU.2.21.1808281435050.31480@er-systems.de>
References: <alpine.LSU.2.21.1808281225550.27853@er-systems.de> <alpine.DEB.2.21.1808281234260.2816@nanos.tec.linutronix.de>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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