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 41764C433EF for ; Wed, 29 Sep 2021 13:39:03 +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 0716961216 for ; Wed, 29 Sep 2021 13:39:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0716961216 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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=DsikkS9bKuPojIwxKVJCQISDKoBObVV+56wGLFvIfu4=; b=O1RIOztZ1IKMzM 9dg8w+f3cDzOTUE+/hbK5LW5Ly2HtSPD8R6SZ6UQU+VTuunqNQtPP56639bnM3LgK3sXHGjsuvEw1 KxfHrN2SY4NLJGEYT/eMqj6Z06y+aIW/c19NM69qfLhcaZ/8uuZwhLXFXHtLbMYSjoMJtpmfEqb5F 8Lb6iDyTgqOc5fSQJdoUblJp9dWz2fmxEhmsYzDIJmZ8XXZTYwKmQr5Wp8F1qV9rnDmFazNDpJPov kg0oERN1WstZ8DgQyswICPc7FuTx2lsiXFCJPMlJuihk/OOWbpH/d8EyC1+epDjmUes/sUOvZ3DZM 30asHjW2I6L1ZrwPeWgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVZld-00BA60-8p; Wed, 29 Sep 2021 13:37:01 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVZlZ-00BA4q-4m for linux-arm-kernel@lists.infradead.org; Wed, 29 Sep 2021 13:36:58 +0000 Received: by mail-wr1-x430.google.com with SMTP id t18so4415784wrb.0 for ; Wed, 29 Sep 2021 06:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=p1lN5h412iZ+jiYL21D4EDp28QaTlZGVFwXpgnAG8zY=; b=DZo/M4QwNbhHQlkBcEl3KRzaLXdJF3wDPS/Ks3k8DgOCWQosYBd8pvWAEjyzS3s5o9 3wSq7sTesam/4qyjsV0UxADlliAjJwMnlZ80rO57uKw75z3BNaJE67OeA/zjElYfNBnB upu9H1oGAwkJZWJ5kKHu8XL6UOnWbvf3DORDTyvGnaTtIQJneKhyY01YN0in5proaZ1D CL0LwrgFYEmEGSP9olyni8Heu0DZDAscMtnIy/cEWldMrjYZjt2ZIOdlAVDcNC/coLzy nGaT2CHchlFVlHvVb6gZLG8WKtLmeOgZbLyZcwTt7Up67Hr7VV7vzA0MyJhxGa1H8L5V mXaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p1lN5h412iZ+jiYL21D4EDp28QaTlZGVFwXpgnAG8zY=; b=Q39FR7aGRnVP7C6Vmsg4UBpejUICkfNgCvuzSZgbG1Yeg6U7pkt68trp/l8YSPbHdv kFji20XgxpHGqRixe6ViZv5t+lVMi2go8ja8CJSiQHKWVZ7No8CHUBfKNx5sHHEtbx1V 3Ci/O1JojZbg3CwkTEG7yJODuBvliRnwHwmdLL+NZDhpyk9Zkv1dsZO2rghyxiS7XHZ/ JUj/bFA3Dmv2R8N/auml+9isTzgSTwvLV2wgNdEV+PTylyuBshCkp/VPhxmxFSc/+qDk 3EJYHWd1afmSVv577F6yPAnIA5Hl29QylZya5JQ55maM17hjjiaxGR4A9z45Dh1bJBxk cB0Q== X-Gm-Message-State: AOAM531prgGSOy7FtAUZsrLwMUW5uzWf8Q+G7VlYuAhJ/3BnxHCIUwqX gg23uxRFtJRfGeouFEPssu9XPQ== X-Google-Smtp-Source: ABdhPJxkZq3g55PyvQwEmuy68Rg4FY1ju/lkwZnhBlN5+gehJC8BuR5CbcA5bJB+m5HEiXAV5EsTeA== X-Received: by 2002:adf:fe89:: with SMTP id l9mr6930369wrr.0.1632922613458; Wed, 29 Sep 2021 06:36:53 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:1ebb:fd0f:cf53:11c5]) by smtp.gmail.com with ESMTPSA id z12sm2418453wrv.31.2021.09.29.06.36.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 06:36:53 -0700 (PDT) Date: Wed, 29 Sep 2021 14:36:47 +0100 From: Quentin Perret To: Will Deacon 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: References: <20210923112256.15767-1-will@kernel.org> <20210923112256.15767-4-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210923112256.15767-4-will@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210929_063657_230746_0296B4D4 X-CRM114-Status: GOOD ( 26.82 ) 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 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? Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel