[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240503150114.GB18656@willie-the-truck>
Date: Fri, 3 May 2024 16:01:16 +0100
From: Will Deacon <will@...nel.org>
To: Sebastian Ene <sebastianene@...gle.com>
Cc: catalin.marinas@....com, james.morse@....com, jean-philippe@...aro.org,
maz@...nel.org, oliver.upton@...ux.dev, qperret@...gle.com,
qwandor@...gle.com, sudeep.holla@....com, suzuki.poulose@....com,
tabba@...gle.com, yuzenghui@...wei.com, lpieralisi@...nel.org,
kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH 2/4] KVM: arm64: Add support for FFA_PARTITION_INFO_GET
On Thu, Apr 18, 2024 at 04:30:24PM +0000, Sebastian Ene wrote:
> Handle the FFA_PARTITION_INFO_GET host call inside the pKVM hypervisor
> and copy the response message back to the host buffers. Save the
> returned FF-A version as we will need it later to interpret the response
> from the TEE.
>
> Signed-off-by: Sebastian Ene <sebastianene@...gle.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 46 +++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 023712e8beeb..d53f50c73acb 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -674,6 +674,49 @@ static void do_ffa_version(struct arm_smccc_res *res,
> hyp_spin_unlock(&host_buffers.lock);
> }
>
> +static void do_ffa_part_get(struct arm_smccc_res *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, uuid0, ctxt, 1);
> + DECLARE_REG(u32, uuid1, ctxt, 2);
> + DECLARE_REG(u32, uuid2, ctxt, 3);
> + DECLARE_REG(u32, uuid3, ctxt, 4);
> + DECLARE_REG(u32, flags, ctxt, 5);
> + u32 off, count, sz, buf_sz;
> +
> + hyp_spin_lock(&host_buffers.lock);
> + if (!host_buffers.rx) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
This should be FFA_RET_BUSY per the spec.
> + goto out_unlock;
> + }
> +
> + arm_smccc_1_1_smc(FFA_PARTITION_INFO_GET, uuid0, uuid1,
> + uuid2, uuid3, flags, 0, 0,
> + res);
> +
> + if (res->a0 != FFA_SUCCESS)
> + goto out_unlock;
> +
> + count = res->a2;
> + if (!count)
> + goto out_unlock;
> +
> + if (host_buffers.ffa_version > FFA_VERSION_1_0) {
The spec says that the size field is populated based on the flags
parameter. Why aren't you checking that instead of the version number?
> + buf_sz = sz = res->a3;
> + if (sz > sizeof(struct ffa_partition_info))
> + buf_sz = sizeof(struct ffa_partition_info);
I don't think this is right, as if the payload really is bigger than
'struct ffa_partition_info' we'll truncate the data (and you don't
adjust res->a3 afaict).
Can't we just copy the whole thing back to the host? We're not
interpreting the thing, so we can just treat it like a stream of bytes.
> + } else {
> + /* FFA_VERSION_1_0 lacks the size in the response */
> + buf_sz = sz = 8;
Can you define that as a constant in arm_ffa.h, please? It's the size of
a 1.0 partition info structure.
> + }
> +
> + WARN_ON((count - 1) * sz + buf_sz > PAGE_SIZE);
We should bounds-check against 'KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE' and
return an error (FFA_RET_ABORTED) if the size is over that.
> + for (off = 0; off < count * sz; off += sz)
> +
> + memcpy(host_buffers.rx + off, hyp_buffers.rx + off, buf_sz);
I think this is wrong if bit 0 of 'flags' is set to 1. In that case, I
think you just get back the number of partitions and that's it, so we
shouldn't be going near the mailboxes.
Will
Powered by blists - more mailing lists