linux-kernel - Re: [PATCH 4.14 038/190] KVM: x86: only do L1TF workaround on affected processors

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200624141520.GF1931@sasha-vm>
Date:   Wed, 24 Jun 2020 10:15:20 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@...ia.com>
Cc:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>
Subject: Re: [PATCH 4.14 038/190] KVM: x86: only do L1TF workaround on
 affected processors

On Wed, Jun 24, 2020 at 12:00:59PM +0000, Rantala, Tommi T. (Nokia - FI/Espoo) wrote:
>On Fri, 2020-06-19 at 16:31 +0200, Greg Kroah-Hartman wrote:
>> From: Paolo Bonzini <pbonzini@...hat.com>
>>
>> [ Upstream commit d43e2675e96fc6ae1a633b6a69d296394448cc32 ]
>>
>> KVM stores the gfn in MMIO SPTEs as a caching optimization.  These are
>> split
>> in two parts, as in "[high 11111 low]", to thwart any attempt to use these
>> bits
>> in an L1TF attack.  This works as long as there are 5 free bits between
>> MAXPHYADDR and bit 50 (inclusive), leaving bit 51 free so that the MMIO
>> access triggers a reserved-bit-set page fault.
>
>Hi, I'm now seeing this warning in VM bootup with 4.14.y

Thanks for the report!

>Not seen with 4.19.129 and 5.4.47 that also included this commit.
>
>Any ideas what's missing in 4.14 ?

I think that this was because we're missing 6129ed877d40 ("KVM: x86/mmu:
Set mmio_value to '0' if reserved #PF can't be generated"). I've queued
it up (along with a few other related commits) and a new -rc cycle
should be underway for those.

-- 
Thanks,
Sasha