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=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 94478C4338F for ; Fri, 30 Jul 2021 12:52:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5FE7160F00 for ; Fri, 30 Jul 2021 12:52:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5FE7160F00 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LAmDz1iL5wEmR67BAZhfPp0WsUPc8zmMLqxI6s1PIZA=; b=TsMlndaaExoFqa cDZNHp3yp+1Db+YigVX9WsTEqMxae9CqezcY39ssq1z4aoGky3LwdWcaKuh3P2esur/bzI00wzRhI glhPNT1Zyaa9LbQamTlxIAdssCUdjv8YCajv4RPizVHmeBABzcAso654bnTMA89PsI9fU9DbKH2m8 ncItL276xdP8C2zNliubKu46ZlX4fjSwcXLulD7Y/0AtdxoCdJ2GdcxuXvrnfhpGfgJ8PVFqB/cN6 5PJ3yehQ4Ki0snTzzC0eCaUVTVGhv2/jlRqnn3wu2PNx6EBLTAH/ipA/Xn1+Vz9Gg1yKt8d9hib02 2GeZBv7X9U9yir7OiFyA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9Rxz-008eXl-10; Fri, 30 Jul 2021 12:50:19 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9Rxv-008eX2-0N for linux-arm-kernel@lists.infradead.org; Fri, 30 Jul 2021 12:50:16 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 84E8060F94; Fri, 30 Jul 2021 12:50:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627649414; bh=Qx8s173dITTj8lJV0Vz8eXvZOBa4mUT9bdDcZtwP9Uo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FElWlKyjKu/pcWTrbgSrqv/Is3Rt7MaSar2yTy2qsCABnJd2AlNmxJP17O/tqGRmn Z+OrWRwxwm+SjOmpbYX2hRt0zu+6dPgzKnxi8SCvCqokvhn3XdrEvRuoa8F+9xg0/l kEKUMk6Q6fHWLK8pI4QJuS4aejesAiwFNKpJAK2mUaVHEx9hAEVZzS39P+v/va8ik0 DguLFDI2Jlg+dzGCuTAdx1/Su7YHNFHHF02BCsIPZCCUjdLYTgmrT+26Ar/MRDFhDH f/caP/gOfCDjDOxCkP4VOx9QzBfgcwCfUcvC0MIuoyVo6CYTwZ1t/fdnbAe9kNVWc5 0XVIgQF+h36wA== Date: Fri, 30 Jul 2021 13:50:09 +0100 From: Will Deacon To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qperret@google.com, dbrazdil@google.com, Srivatsa Vaddagiri , Shanker R Donthineni , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH 06/16] KVM: arm64: Force a full unmap on vpcu reinit Message-ID: <20210730125008.GB23756@willie-the-truck> References: <20210715163159.1480168-1-maz@kernel.org> <20210715163159.1480168-7-maz@kernel.org> <20210727181132.GE19173@willie-the-truck> <87wnpad8pg.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87wnpad8pg.wl-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210730_055015_125711_089B0ADE X-CRM114-Status: GOOD ( 32.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 28, 2021 at 11:38:35AM +0100, Marc Zyngier wrote: > On Tue, 27 Jul 2021 19:11:33 +0100, > Will Deacon wrote: > > > > On Thu, Jul 15, 2021 at 05:31:49PM +0100, Marc Zyngier wrote: > > > As we now keep information in the S2PT, we must be careful not > > > to keep it across a VM reboot, which could otherwise lead to > > > interesting problems. > > > > > > Make sure that the S2 is completely discarded on reset of > > > a vcpu, and remove the flag that enforces the MMIO check. > > > > > > Signed-off-by: Marc Zyngier > > > --- > > > arch/arm64/kvm/arm.c | 8 +++++++- > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > > index 97ab1512c44f..b0d2225190d2 100644 > > > --- a/arch/arm64/kvm/arm.c > > > +++ b/arch/arm64/kvm/arm.c > > > @@ -1096,12 +1096,18 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu, > > > * ensuring that the data side is always coherent. We still > > > * need to invalidate the I-cache though, as FWB does *not* > > > * imply CTR_EL0.DIC. > > > + * > > > + * If the MMIO guard was enabled, we pay the price of a full > > > + * unmap to get back to a sane state (and clear the flag). > > > */ > > > if (vcpu->arch.has_run_once) { > > > - if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB)) > > > + if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB) || > > > + test_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags)) > > > stage2_unmap_vm(vcpu->kvm); > > > else > > > icache_inval_all_pou(); > > > + > > > + clear_bit(KVM_ARCH_FLAG_MMIO_GUARD, &vcpu->kvm->arch.flags); > > > > What prevents this racing with another vCPU trying to set the bit? > > Not much. We could take the kvm lock on both ends to serialize it, but > that's pretty ugly. And should we care? What is the semantic of > resetting a vcpu while another is still running? It's definitely weird, but given that this is an attack vector I don't think we can rule out attackers trying whacky stuff like this (although maybe we end up forbidding vcpu reset in pKVM -- dunno). > If we want to support this sort of behaviour, then our tracking is > totally bogus, because it is VM-wide. And you don't even have to play > with that bit from another vcpu: all the information is lost at the > point where we unmap the S2 PTs. > > Maybe an alternative is to move this to the halt/reboot PSCI handlers, > making it clearer what we expect? I think that's probably worth looking at. The race is quite hard to reason about otherwise, so if clearing the bit can be done on the teardown path in single-threaded context then I think that's better. It looks like kvm_prepare_system_event() has all the synchronisation we need there. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel