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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56B69C433EF for ; Tue, 5 Oct 2021 11:32:44 +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 23F9461269 for ; Tue, 5 Oct 2021 11:32:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 23F9461269 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=X7GkEn1vY8VuXlF0DLAjXr4mDM5PM63qet8VeOKYlyA=; b=ifQoKZ4h3VGTtD vqcsouWwpBPx51ULCgHqZAMeRR6agwX3P7RBqZ5A4bwg0dBSPDs9WFnebQ7yvxKCncyzjkLPDE8Mq T1TujK9ytsM4Wo2jLfDURa4tPhH1md/8oVFrBdr0pHXCV1wTSR7tu+gayiSku42TQdC4TQH2Pi8ie +NEsZfCbemFMiXAyQSRGhr2TChNJ+FxCwlqkY6ACM95f41R3JfXUklxsVPlpylPczcF7JDEfU56Nz iq7t8cvGtqC5LvrxHcmEjkgE2yRihbbATeN+h5hjz9Dn4csWBLJFvRiGGbjDT9aVarXEWe8tq2aWV Iam4RF7Kq8q3O/4DgG4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXien-00A8Wd-Q5; Tue, 05 Oct 2021 11:30:49 +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 1mXiek-00A8Vl-JW for linux-arm-kernel@lists.infradead.org; Tue, 05 Oct 2021 11:30:48 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 58B4461247; Tue, 5 Oct 2021 11:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633433445; bh=wNKhKlemUmFvj/9jjAc6uJGFvdce9Q9PFO1r1iZLImE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YZuidyn+FD6A8mbeiW7M00zIWi61RCYKjg9CiCvFbJVy1xT235FzhR5014EnpF7JU 1g4EC497fRmBkOn7XJQ8uerd3TKY8IJeR3gsMRw47DiqVp2GuJDuVFJq88g8g02ZRm 5ajCQfgt66ZVORL+avmC/R22JnkvBqruwlfwYjFjuc6KF3saaxBTwlGHAB5Ad67YF1 UcVLiR1cAd16GlIMaarhqYMjdN7R+oiYDyaWXa8XjlQ0SdRdeS6pIWxghUwkzJ6EIH iJsWUA/AKtO/Q5NL1pM6KS5dW07/90st25NZhANq9UgTWiNFfVM8yFzeAtxz7ib2s3 I+SOwuTa4xuBw== Date: Tue, 5 Oct 2021 12:30:41 +0100 From: Will Deacon To: Quentin Perret Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Catalin Marinas , Alexandru Elisei , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH 3/5] KVM: arm64: Propagate errors from __pkvm_prot_finalize hypercall Message-ID: <20211005113040.GA29208@willie-the-truck> References: <20210923112256.15767-1-will@kernel.org> <20210923112256.15767-4-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20211005_043046_721398_0CD520E6 X-CRM114-Status: GOOD ( 33.73 ) 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 Hey Quentin, On Wed, Sep 29, 2021 at 02:36:47PM +0100, Quentin Perret wrote: > On Thursday 23 Sep 2021 at 12:22:54 (+0100), Will Deacon wrote: > > If the __pkvm_prot_finalize hypercall returns an error, we WARN but fail > > to propagate the failure code back to kvm_arch_init(). > > > > Pass a pointer to a zero-initialised return variable so that failure > > to finalise the pKVM protections on a host CPU can be reported back to > > KVM. > > > > Cc: Marc Zyngier > > Cc: Quentin Perret > > Signed-off-by: Will Deacon > > --- > > arch/arm64/kvm/arm.c | 30 +++++++++++++++++++----------- > > 1 file changed, 19 insertions(+), 11 deletions(-) > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index 9506cf88fa0e..13bbf35896cd 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -1986,9 +1986,25 @@ static int init_hyp_mode(void) > > return err; > > } > > > > -static void _kvm_host_prot_finalize(void *discard) > > +static void _kvm_host_prot_finalize(void *arg) > > { > > - WARN_ON(kvm_call_hyp_nvhe(__pkvm_prot_finalize)); > > + int *err = arg; > > + > > + if (WARN_ON(kvm_call_hyp_nvhe(__pkvm_prot_finalize))) > > + WRITE_ONCE(*err, -EINVAL); > > +} > > I was going to suggest to propagate the hypercall's error code directly, > but this becomes very racy so n/m... > > But this got me thinking about what we should do when the hyp init fails > while the protected mode has been explicitly enabled on the kernel > cmdline. That is, if we continue and boot the kernel w/o KVM support, > then I don't know how e.g. EL3 can know that it shouldn't give keys to > VMs because the kernel (and EL2) can't be trusted. It feels like it is > the kernel's responsibility to do something while it _is_ still > trustworthy. > > I guess we could make any error code fatal in kvm_arch_init() when > is_protected_kvm_enabled() is on, or something along those lines? Maybe > dependent on CONFIG_NVHE_EL2_DEBUG=n? > > It's probably a bit theoretical because there really shouldn't be any > reason to fail hyp init in production when using a signed kernel image > etc etc, but then if that is the case the additional check I'm > suggesting shouldn't hurt and will give us some peace of mind. Thoughts? It's an interesting one. I'm not hugely keen on crashing the system if we fail to deprivilege the host (which I think is effectively what is happening in the case you describe), but you're right that we need to disable pKVM somehow in this case. I think the best thing would be to wipe the pvmfw memory; that would mean that the host can do whatever it likes at EL2, as the keys will no longer be available. I'll make a note about this, since I've parked the pvmfw patches until we've got more of the pKVM infrastructure up and running. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel