From: Marc Zyngier <maz@kernel.org>
To: Snehal Koukuntla <snehalreddy@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
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
Subject: Re: [PATCH] KVM: arm64: Add memory length checks before it is xfered
Date: Fri, 06 Sep 2024 17:35:39 +0100 [thread overview]
Message-ID: <86ed5wvixw.wl-maz@kernel.org> (raw)
In-Reply-To: <20240906092732.113152-1-snehalreddy@google.com>
Hi Snehal,
On Fri, 06 Sep 2024 10:27:32 +0100,
Snehal Koukuntla <snehalreddy@google.com> wrote:
>
> From: Snehal <snehalreddy@google.com>
>
> Check size during allocation to fix discrepancy in memory reclaim path.
> Currently only happens during memory reclaim, inconsistent with mem_xfer
Can you please elaborate? It doesn't seem to fail at allocation time
here, as everything is pre-allocated. Some context would greatly help,
as my FFA-foo is as basic as it gets (I did read the spec once and ran
away screaming).
>
> Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
The From: and Signed-off-by: tags do not match. You may want to add a
[user] section to your .gitconfig with your full name so that this
issue is sorted once and for all.
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index e715c157c2c4..e9223cc4f913 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -461,6 +461,11 @@ static __always_inline void do_ffa_mem_xfer(const u64 func_id,
/facepalm: why do we have this __always_inline here? Nothing to do
with your patch, but definitely worth understanding why it is
required.
> goto out_unlock;
> }
>
> + if (len > ffa_desc_buf.len) {
> + ret = FFA_RET_NO_MEMORY;
> + goto out_unlock;
> + }
> +
It took some digging to understand how the various queues are sized,
and a comment explaining the relation between ffa_desc_buf and the
other queues would be very welcome.
I also notice that we have other places (apparently dealing with
fragments) that do not have such checks. Do they need anything else?
> buf = hyp_buffers.tx;
> memcpy(buf, host_buffers.tx, fraglen);
>
Finally, this probably deserves a Fixes: tag and a Cc: stable so that
it can be backported.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-09-06 16:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-06 9:27 [PATCH] KVM: arm64: Add memory length checks before it is xfered Snehal Koukuntla
2024-09-06 16:35 ` Marc Zyngier [this message]
2024-09-09 7:16 ` Sebastian Ene
2024-09-09 13:04 ` Snehal Koukuntla
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=86ed5wvixw.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=sebastianene@google.com \
--cc=snehalreddy@google.com \
--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.