From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 217D1C04AAC for ; Mon, 20 May 2019 20:49:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DBFB421479 for ; Mon, 20 May 2019 20:49:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726088AbfETUtb convert rfc822-to-8bit (ORCPT ); Mon, 20 May 2019 16:49:31 -0400 Received: from mail.csgraf.de ([188.138.100.120]:48682 "EHLO zulu616.server4you.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726011AbfETUtb (ORCPT ); Mon, 20 May 2019 16:49:31 -0400 Received: from [172.16.70.131] (unknown [70.96.135.254]) by csgraf.de (Postfix) with ESMTPSA id 9C04139002BA; Mon, 20 May 2019 22:49:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: #VE support for VMI From: Alexander Graf X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190520183331.GD28482@linux.intel.com> Date: Mon, 20 May 2019 13:49:27 -0700 Cc: =?utf-8?Q?Mihai_Don=C8=9Bu?= , Paolo Bonzini , kvm@vger.kernel.org, KarimAllah Ahmed Content-Transfer-Encoding: 8BIT Message-Id: <0A615AC6-C27F-41DA-AC20-7191DAD2CAC7@csgraf.de> References: <571322cc13b98f3805a4843db28f5befbb1bd5a9.camel@bitdefender.com> <80e0baaf-150b-0966-6920-b36d23a6cdef@csgraf.de> <20190520183331.GD28482@linux.intel.com> To: Sean Christopherson Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org > Am 20.05.2019 um 11:33 schrieb Sean Christopherson : > >> On Mon, May 20, 2019 at 11:10:51AM -0700, Alexander Graf wrote: >>> On 20.05.19 08:48, Mihai Donțu wrote: >>> Hi Paolo, >>> >>> We are looking at adding #VE support to the VMI subsystem we are >>> working on. Its purpose is to suppress VMEXIT-s caused by the page >>> table walker when the guest page tables are write-protected. A very >>> small in-guest agent (protected by the hypervisor) will receive the EPT >>> violation events, handle PT-walk writes and turn the rest into VMCALL- >>> s. >>> >>> A brief presentation of similar work on Xen can be found here: >>> https://www.slideshare.net/xen_com_mgr/xpdss17-hypervisorbased-security-bringing-virtualized-exceptions-into-the-game-mihai-dontu-bitdefender >>> >>> There is a bit of an issue with using #VE on KVM, though: because the >>> EPT is built on-the-fly (as the guest runs), when we enable #VE in >>> VMCS, all EPT violations become virtualized, because all EPTE-s have >>> bit 63 zero (0: convert to #VE, 1: generate VMEXIT). At the moment, I >> >> Are you 100% sure? Last time I played with #VE, it only triggered on >> misconfigurations/permission checks (lack of R/W/X, but P=1), not on P=0 >> pages. > > #VEs trigger on RWX=0, but not misconfigurations, i.e. any and all > EPT_VIOLATION exits (reason 48) are convertible, and EPT_MISCONFIG exits > (reason 49) are never convertible. The reasoning behind the logic is > that an EPT_MISCONFIG is the result of a VMM bug (or in KVM's case, MMIO > trickery), whereas a RWX=0 EPT_VIOLATION could be a malicious entity in > the guest probing non-existent pages or pages it doesn't have access to. I see - I must have forgotten about some change I did on my playground setup then. Either way, you want a direct deflection path. You can not guarantee that a page is always present on an overcommitted system. Alex