From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 16 Oct 2019 08:15:17 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iKeSh-0008QK-0v for speck@linutronix.de; Wed, 16 Oct 2019 10:15:16 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7A8B0BA4B for ; Wed, 16 Oct 2019 08:15:08 +0000 (UTC) Date: Wed, 16 Oct 2019 10:15:07 +0200 From: Joerg Roedel Subject: [MODERATED] Re: ***UNCHECKED*** NX, nested virtualization and arch caps Message-ID: <20191016081507.GD4695@suse.de> References: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Hi Paolo, On Tue, Oct 15, 2019 at 11:45:14AM +0200, speck for Paolo Bonzini wrote: > Right now, the NX patches are not advertising the > ARCH_CAP_PSCHANGE_MC_NO bit to its guests (especially nested > hypervisors). This is despite KVM's shadow paging will ensure that the > nested hypervisor's EPT pages are 4K in size. > > This is because nx_huge_pages is writable. Therefore, the value of the > parameter could change from Y to N while a guest runs, and then the > nested hypervisor would become vulnerable to the nested guest's bad > behavior. > > On the other hand, if the ITLB_MULTIHIT mitigation is disabled, then any > guest is anyway vulnerable to other guests' shenanigans. Therefore the > nested hypervisor can just ignore ITLB_MULTIHIT altogether, even if it > would then be vulnerable to L2's bad behavior. And this means we can > unconditionally advertise to nested hypervisors that the processor is > not vulnerable. > > Are there any issues with this reasoning? I also think that any nested hypervisor can ignore the ITLB_MULTIHIT bug, but for a different reason: The host also builds the nested EPT table as a shadow of the guests EPT table, so it does the mitigation on behalf of the nested hypervisor. Regards, Joerg