From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Wei-Lin Chang <r09922117@csie.ntu.edu.tw>,
Snehal Koukuntla <snehalreddy@google.com>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Sebastian Ene <sebastianene@google.com>,
Vincent Donnefort <vdonnefort@google.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v3] KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer
Date: Tue, 10 Sep 2024 20:49:28 +0100 [thread overview]
Message-ID: <86r09r70hj.wl-maz@kernel.org> (raw)
In-Reply-To: <ZuCNge74gVpJi2Sf@linux.dev>
On Tue, 10 Sep 2024 19:18:41 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
>
> On Wed, Sep 11, 2024 at 12:32:29AM +0800, Wei-Lin Chang wrote:
> > Hi everyone,
> >
> > On Mon, Sep 09, 2024 at 06:01:54PM GMT, Snehal Koukuntla wrote:
> > > When we share memory through FF-A and the description of the buffers
> > > exceeds the size of the mapped buffer, the fragmentation API is used.
> > > The fragmentation API allows specifying chunks of descriptors in subsequent
> > > FF-A fragment calls and no upper limit has been established for this.
> > > The entire memory region transferred is identified by a handle which can be
> > > used to reclaim the transferred memory.
> > > To be able to reclaim the memory, the description of the buffers has to fit
> > > in the ffa_desc_buf.
> > > Add a bounds check on the FF-A sharing path to prevent the memory reclaim
> > > from failing.
> > >
> > > Also do_ffa_mem_xfer() does not need __always_inline
> > >
> > > Fixes: 634d90cf0ac65 ("KVM: arm64: Handle FFA_MEM_LEND calls from the host")
> > > Cc: stable@vger.kernel.org
> > > Reviewed-by: Sebastian Ene <sebastianene@google.com>
> > > Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index e715c157c2c4..637425f63fd1 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -426,7 +426,7 @@ static void do_ffa_mem_frag_tx(struct arm_smccc_res *res,
> > > return;
> > > }
> > >
> > > -static __always_inline void do_ffa_mem_xfer(const u64 func_id,
> > > +static void do_ffa_mem_xfer(const u64 func_id,
> >
> > I am seeing a compilation error because of this.
>
> Thanks for reporting this. Looks like the __always_inline was slightly
> more load bearing...
>
> Marc, can you put something like this on top?
>
>
> From c2712eaa94989ae6457baad3ec459cf363ec5119 Mon Sep 17 00:00:00 2001
> From: Oliver Upton <oliver.upton@linux.dev>
> Date: Tue, 10 Sep 2024 16:45:30 +0000
> Subject: [PATCH] KVM: arm64: Drop BUILD_BUG_ON() from do_ffa_mem_xfer()
>
> __always_inline was recently discarded from do_ffa_mem_xfer() since it
> appeared to be unnecessary. Of course, this was ~immediately proven
> wrong, as the compile-time check against @func_id depends on inlining
> for the value to be known.
>
> Just downgrade to a WARN_ON() instead of putting the old mess back in
> place. Fix the wrapping/indentation of the function parameters while at
> it.
>
> Fixes: 39dacbeeee70 ("KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer")
> Reported-by: Wei-Lin Chang <r09922117@csie.ntu.edu.tw>
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 637425f63fd1..316d269341f3 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -426,9 +426,8 @@ static void do_ffa_mem_frag_tx(struct arm_smccc_res *res,
> return;
> }
>
> -static void do_ffa_mem_xfer(const u64 func_id,
> - struct arm_smccc_res *res,
> - struct kvm_cpu_context *ctxt)
> +static void do_ffa_mem_xfer(const u64 func_id, struct arm_smccc_res *res,
> + struct kvm_cpu_context *ctxt)
> {
> DECLARE_REG(u32, len, ctxt, 1);
> DECLARE_REG(u32, fraglen, ctxt, 2);
> @@ -440,8 +439,10 @@ static void do_ffa_mem_xfer(const u64 func_id,
> u32 offset, nr_ranges;
> int ret = 0;
>
> - BUILD_BUG_ON(func_id != FFA_FN64_MEM_SHARE &&
> - func_id != FFA_FN64_MEM_LEND);
> + if (WARN_ON(func_id != FFA_FN64_MEM_SHARE && func_id != FFA_FN64_MEM_LEND)) {
> + ret = SMCCC_RET_NOT_SUPPORTED;
> + goto out;
> + }
I'm not overly on the WARN_ON(), as it has pretty fatal effects on
pKVM (it simply panics). What do you think of this instead, which
compiles with my prehistoric version of clang (14.0.6):
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 637425f63fd1b..e433dfab882aa 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -426,9 +426,9 @@ static void do_ffa_mem_frag_tx(struct arm_smccc_res *res,
return;
}
-static void do_ffa_mem_xfer(const u64 func_id,
- struct arm_smccc_res *res,
- struct kvm_cpu_context *ctxt)
+static void __do_ffa_mem_xfer(const u64 func_id,
+ struct arm_smccc_res *res,
+ struct kvm_cpu_context *ctxt)
{
DECLARE_REG(u32, len, ctxt, 1);
DECLARE_REG(u32, fraglen, ctxt, 2);
@@ -440,9 +440,6 @@ static void do_ffa_mem_xfer(const u64 func_id,
u32 offset, nr_ranges;
int ret = 0;
- BUILD_BUG_ON(func_id != FFA_FN64_MEM_SHARE &&
- func_id != FFA_FN64_MEM_LEND);
-
if (addr_mbz || npages_mbz || fraglen > len ||
fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -517,6 +514,13 @@ static void do_ffa_mem_xfer(const u64 func_id,
goto out_unlock;
}
+#define do_ffa_mem_xfer(fid, res, ctxt) \
+ do { \
+ BUILD_BUG_ON((fid) != FFA_FN64_MEM_SHARE && \
+ (fid) != FFA_FN64_MEM_LEND); \
+ __do_ffa_mem_xfer((fid), (res), (ctxt)); \
+ } while (0);
+
static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
struct kvm_cpu_context *ctxt)
{
It preserves the build-time assertion, which was the intention of the
original author.
I can easily squash that in the original commit, avoiding the headache
of backporting both patch to stable.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-09-10 19:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 18:01 [PATCH v3] KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer Snehal Koukuntla
2024-09-09 22:36 ` Oliver Upton
2024-09-10 7:23 ` Marc Zyngier
2024-09-10 16:32 ` Wei-Lin Chang
2024-09-10 18:18 ` Oliver Upton
2024-09-10 19:49 ` Marc Zyngier [this message]
2024-09-10 19:53 ` Oliver Upton
2024-09-10 20:11 ` Marc Zyngier
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=86r09r70hj.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=jean-philippe@linaro.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=r09922117@csie.ntu.edu.tw \
--cc=sebastianene@google.com \
--cc=snehalreddy@google.com \
--cc=stable@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.