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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: [FYI PATCH 0/7] Mitigation for CVE-2018-12207
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <1573593697-25061-1-git-send-email-pbonzini@redhat.com>
Date:   Wed, 13 Nov 2019 10:10:59 -0800
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEF550EE-F476-48FB-A226-66D34503CF70@gmail.com>
References: <1573593697-25061-1-git-send-email-pbonzini@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 12, 2019, at 1:21 PM, Paolo Bonzini <pbonzini@redhat.com> =
wrote:
>=20
> CVE-2018-12207 is a microarchitectural implementation issue
> that could allow an unprivileged local attacker to cause system wide
> denial-of-service condition.
>=20
> 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 =
result
> in the processor hitting multiple TLB entries, reporting a machine =
check
> error exception, and ultimately hanging the system.
>=20
> 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 =
into
> the host kernel/hypervisor; KVM will then break the large page into =
4KB
> pages and gives executable permission to 4KB pages.

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.

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?

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