From: Sebastian Ene <sebastianene@google.com>
To: Vincent Donnefort <vdonnefort@google.com>
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, will@kernel.org,
yuzenghui@huawei.com, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO_GET
Date: Wed, 10 Apr 2024 09:15:30 +0000 [thread overview]
Message-ID: <ZhZYsuqggl_Hzv8X@google.com> (raw)
In-Reply-To: <ZhVpmF2js1NJp1qF@google.com>
On Tue, Apr 09, 2024 at 05:15:20PM +0100, Vincent Donnefort wrote:
> Hi Seb,
>
> On Tue, Apr 09, 2024 at 03:19:08PM +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@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 49 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 320f2eaa14a9..72fc365bc7a8 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -67,6 +67,7 @@ struct kvm_ffa_buffers {
> > */
> > static struct kvm_ffa_buffers hyp_buffers;
> > static struct kvm_ffa_buffers host_buffers;
> > +static u32 ffa_version;
> >
> > static void ffa_to_smccc_error(struct arm_smccc_res *res, u64 ffa_errno)
> > {
> > @@ -640,6 +641,49 @@ static bool do_ffa_features(struct arm_smccc_res *res,
> > return true;
> > }
> >
> > +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);
> > + 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;
>
> Looking at the table 13.34, it seems what's in "count" depends on the flag.
> Shouldn't we check its value, and only memcpy into the host buffers if the flag
> is 0?
>
When the flag is `1` the count referes to the number of partitions
deployed. In both cases we have to copy something unless count == 0.
> > +
> > + if (ffa_version > FFA_VERSION_1_0) {
> > + buf_sz = sz = res->a3;
> > + if (sz > sizeof(struct ffa_partition_info))
> > + buf_sz = sizeof(struct ffa_partition_info);
>
> What are you trying to protect against here? We have to trust EL3 anyway, (as
> other functions do).
>
> The WARN() could be kept though to make sure we won't overflow our buffer. But
> it could be transformed into an error? FFA_RET_ABORTED?
>
>
I think we can keep it as a WARN_ON because it is not expected to have
a return code of FFA_SUCCESS but the buffer to be overflown. The TEE is
expected to return NO_MEMORY in w2 if the results cannot fit in the RX
buffer.
Thanks,
Seb
> > + } else {
> > + /* FFA_VERSION_1_0 lacks the size in the response */
> > + buf_sz = sz = 8;
> > + }
> > +
> > + WARN_ON((count - 1) * sz + buf_sz > PAGE_SIZE);
> > + for (off = 0; off < count * sz; off += sz)
> > + memcpy(host_buffers.rx + off, hyp_buffers.rx + off, buf_sz);
> > +out_unlock:
> > + hyp_spin_unlock(&host_buffers.lock);
> > +}
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_res res;
> > @@ -686,6 +730,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_MEM_FRAG_TX:
> > do_ffa_mem_frag_tx(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_PARTITION_INFO_GET:
> > + do_ffa_part_get(&res, host_ctxt);
> > + break;
> > }
> >
> > if (ffa_call_supported(func_id))
> > @@ -726,6 +773,8 @@ int hyp_ffa_init(void *pages)
> > if (FFA_MAJOR_VERSION(res.a0) != 1)
> > return -EOPNOTSUPP;
> >
> > + ffa_version = res.a0;
> > +
> > arm_smccc_1_1_smc(FFA_ID_GET, 0, 0, 0, 0, 0, 0, 0, &res);
> > if (res.a0 != FFA_SUCCESS)
> > return -EOPNOTSUPP;
> > --
> > 2.44.0.478.gd926399ef9-goog
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-10 9:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 15:19 [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO_GET Sebastian Ene
2024-04-09 16:15 ` Vincent Donnefort
2024-04-10 9:15 ` Sebastian Ene [this message]
2024-04-10 9:53 ` Vincent Donnefort
2024-04-10 10:18 ` Sebastian Ene
2024-04-10 17:10 ` Vincent Donnefort
2024-04-11 9:03 ` Sebastian Ene
2024-04-10 14:57 ` Lorenzo Pieralisi
2024-04-11 8:52 ` Sebastian Ene
2024-04-11 9:05 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZhZYsuqggl_Hzv8X@google.com \
--to=sebastianene@google.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=jean-philippe@linaro.org \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=qwandor@google.com \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).