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;
Subject: Re: [FYI PATCH 0/7] Mitigation for CVE-2018-12207
To:     Nadav Amit <nadav.amit@gmail.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org
References: <1573593697-25061-1-git-send-email-pbonzini@redhat.com>
 <DEF550EE-F476-48FB-A226-66D34503CF70@gmail.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <fa4a67e8-50db-a42a-3186-072327ea538a@redhat.com>
Date:   Wed, 13 Nov 2019 19:33:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <DEF550EE-F476-48FB-A226-66D34503CF70@gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 13/11/19 19:10, Nadav Amit wrote:
>=20
>> On Nov 12, 2019, at 1:21 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> CVE-2018-12207 is a microarchitectural implementation issue
>> that could allow an unprivileged local attacker to cause system wide
>> denial-of-service condition.
>>
>> Privileged software may change the page size (ex. 4KB, 2MB, 1GB) in the
>> paging structures, without following such paging structure changes with
>> invalidation of the TLB entries corresponding to the changed pages. In
>> this case, the attacker could invoke instruction fetch, which will resul=
t
>> in the processor hitting multiple TLB entries, reporting a machine check
>> error exception, and ultimately hanging the system.
>>
>> The attached patches mitigate the vulnerability by making huge pages
>> non-executable. The processor will not be able to execute an instruction
>> residing in a large page (ie. 2MB, 1GB, etc.) without causing a trap int=
o
>> the host kernel/hypervisor; KVM will then break the large page into 4KB
>> pages and gives executable permission to 4KB pages.
>=20
> It sounds that this mitigation will trigger the =E2=80=9Cpage fracturing=
=E2=80=9D problem
> I once encountered [1], causing frequent full TLB flushes when invlpg
> runs. I wonder if VMs would benefit in performance from changing
> /sys/kernel/debug/x86/tlb_single_page_flush_ceiling to zero.
>=20
> On a different note - I am not sure I fully understand the exact scenario=
.
> Any chance of getting a kvm-unit-test for this case?

No, for now I only have a test that causes lots of 2 MiB pages to be
shattered to 4 KiB.  But I wanted to get and post a test case in the
next week.

Paolo

> [1] https://patchwork.kernel.org/patch/9099311/
>=20