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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E0225C4345F for ; Fri, 3 May 2024 14:40:09 +0000 (UTC) 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=81lR2UEgI3yXfXAoEGbTo/HTpjHnNft7eqfKE0pkeQI=; b=A8ie0YwgUOfQqt Lo/ebRV+kTarrHc9AZ9cn25RiFl7dcsX0FppoP9BxrckNSEOE/Alpyk9s6ZvFZ3Mkk3k0mBhQzbyN AAv7Yl1pSCJdxWLgrdVwObG/QRJ1VHOc1eE+o+krfKmGVX29oJ7ZCetdauzKOmOfH6OFBRyPQ4VqB VTZeANF6lbQBZffhpsFzSPHbKnRiGr/cEGzO4EKGfXn1bh/g9saS6AZnsINDrBLtXWIJ7IoJMGvSl AwLj2OCOSoVHT4kvK3BwKuOU6D+WNBnaoeaoaYHzd7D4pQo1SheXt9t/OMnc7kYtV8rjiSv8+dfLe ZBQapY1qfBYMSxpysUrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2u4u-0000000GtIy-0jwK; Fri, 03 May 2024 14:40:00 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2u4q-0000000GtG2-0LjX for linux-arm-kernel@lists.infradead.org; Fri, 03 May 2024 14:39:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 8C7E7CE1919; Fri, 3 May 2024 14:39:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3749C116B1; Fri, 3 May 2024 14:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714747184; bh=crmrWVWqDYe1RC0chX9UhqYvAe5bPNAEZ5pSMdrlJns=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MHtpp8aWu7z/uZkDA0XYRKCvCDCh/qTV7J2O/xkkETrfYkh52o+P+K/RseqapzLgc DWOKCly+UKNxtd7Mmj7heEFRdTtA5wU9wm5CkkgLBPqxDvWsb9JYPXy2qDuuFoGIJ5 95yJ3K14GQjNr7ZCylufH7pSWVczsZsBhysKK0RbOq0ip7eBRYwQe7ukOXyTBtfPnH GHD1qntB/Ou6DhQ9fdRRrVReVDeCCsxrBd3A1DtuxkjKmKheVij2HIelnuOyNzR3mx zRU9VKhA1pnoCAF9NTdEiwMRnIqHEej041B3uRpQQx27vDRuYcdFUWdmvXqd0ViAEL PQSdd30xUJ7DA== Date: Fri, 3 May 2024 15:39:38 +0100 From: Will Deacon To: Sebastian Ene Cc: catalin.marinas@arm.com, james.morse@arm.com, jean-philippe@linaro.org, maz@kernel.org, oliver.upton@linux.dev, qperret@google.com, qwandor@google.com, sudeep.holla@arm.com, suzuki.poulose@arm.com, tabba@google.com, yuzenghui@huawei.com, lpieralisi@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 1/4] KVM: arm64: Trap FFA_VERSION host call in pKVM Message-ID: <20240503143937.GA18656@willie-the-truck> References: <20240418163025.1193763-2-sebastianene@google.com> <20240418163025.1193763-3-sebastianene@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240418163025.1193763-3-sebastianene@google.com> 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-20240503_073956_508651_90AF868F X-CRM114-Status: GOOD ( 32.71 ) 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 Hi Seb, On Thu, Apr 18, 2024 at 04:30:23PM +0000, Sebastian Ene wrote: > The pKVM hypervisor initializes with FF-A version 1.0. Keep the > supported version inside the host structure and prevent the host > drivers from overwriting the FF-A version with an increased version. > Without trapping the call, the host drivers can negotiate a higher > version number with TEE which can result in a different memory layout > described during the memory sharing calls. > > Signed-off-by: Sebastian Ene > --- > arch/arm64/kvm/hyp/nvhe/ffa.c | 43 ++++++++++++++++++++++++++++++++--- > 1 file changed, 40 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c > index 320f2eaa14a9..023712e8beeb 100644 > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c > @@ -58,6 +58,7 @@ struct kvm_ffa_buffers { > hyp_spinlock_t lock; > void *tx; > void *rx; > + u32 ffa_version; > }; Why should this be part of 'struct kvm_ffa_buffers'? The host, proxy and Secure side will end up using the same version, so a simple global variable would suffice, no? > /* > @@ -640,6 +641,39 @@ static bool do_ffa_features(struct arm_smccc_res *res, > return true; > } > > +static void do_ffa_version(struct arm_smccc_res *res, > + struct kvm_cpu_context *ctxt) > +{ > + DECLARE_REG(u32, ffa_req_version, ctxt, 1); > + u32 current_version; > + > + hyp_spin_lock(&host_buffers.lock); Why do you need to take the lock for this? > + current_version = host_buffers.ffa_version; > + if (FFA_MAJOR_VERSION(ffa_req_version) != FFA_MAJOR_VERSION(current_version)) { > + res->a0 = FFA_RET_NOT_SUPPORTED; > + goto unlock; > + } We won't have probed the proxy if the Secure side doesn't support 1.x so I think you should just do: if (FFA_MAJOR_VERSION(ffa_req_version) != 1) ... > + /* > + * If the client driver tries to downgrade the version, we need to ask > + * first if TEE supports it. > + */ > + if (FFA_MINOR_VERSION(ffa_req_version) < FFA_MINOR_VERSION(current_version)) { Similarly here, I don't think 'current_version' is what we should expose. Rather, we should be returning the highest version that the proxy supports in the host, which is 1.0 at this point in the patch series. > + arm_smccc_1_1_smc(FFA_VERSION, ffa_req_version, 0, > + 0, 0, 0, 0, 0, > + res); Hmm, I'm struggling to see how this is supposed to work per the spec. The FF-A spec says: | ... negotiation of the version must happen before an invocation of | any other FF-A ABI. and: | Once the caller invokes any FF-A ABI other than FFA_VERSION, the | version negotiation phase is complete. | | Once an FF-A version has been negotiated between a caller and a | callee, the version may not be changed for the lifetime of the | calling component. The callee must treat the negotiated version as | the only supported version for any subsequent interactions with the | caller. So by the time we get here, we've already settled on our version with the Secure side and the host cannot downgrade. That's a bit rubbish if you ask me, but I think it means we'll have to defer some of the proxy initialisation until the host calls FFA_VERSION, at which point we'll need to negotiate a common version between the host, the proxy and Secure. Once we've done that, our FFA_VERSION handler will just return that negotiated version. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel