linux-kernel - Re: [PATCH v3 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWDkCQ7m1-w8e-Py@google.com>
Date: Fri, 9 Jan 2026 11:18:33 +0000
From: Sebastian Ene <sebastianene@...gle.com>
To: Will Deacon <will@...nel.org>
Cc: perlarsen@...gle.com, Marc Zyngier <maz@...nel.org>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Yeoreum Yun <yeoreum.yun@....com>, Ben Horgan <ben.horgan@....com>,
	Oliver Upton <oupton@...nel.org>,
	Armelle Laine <armellel@...gle.com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] KVM: arm64: Support FFA_MSG_SEND_DIRECT_REQ in
 host handler

On Thu, Jan 08, 2026 at 03:26:21PM +0000, Will Deacon wrote:

Hi Will,

> On Wed, Nov 19, 2025 at 02:07:53AM +0000, Per Larsen via B4 Relay wrote:
> > From: Sebastian Ene <sebastianene@...gle.com>
> > 
> > Allow direct messages to be forwarded from the host. The host should
> > not be sending framework messages so they are filtered out.
> > 
> > Signed-off-by: Sebastian Ene <sebastianene@...gle.com>
> > Reviewed-by: Yeoreum Yun <yeoreum.yun@....com>
> > Signed-off-by: Per Larsen <perlarsen@...gle.com>
> > ---
> >  arch/arm64/kvm/hyp/nvhe/ffa.c | 22 ++++++++++++++++++++++
> >  include/linux/arm_ffa.h       |  3 +++
> >  2 files changed, 25 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 58b7d0c477d7fce235fc70d089d175c7879861b5..a38a3ab497e5eac11777109684a33f02d88d09a1 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -862,6 +862,23 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
> >  	hyp_spin_unlock(&host_buffers.lock);
> >  }
> >  
> > +static void do_ffa_direct_msg(struct arm_smccc_1_2_regs *res,
> > +			      struct kvm_cpu_context *ctxt,
> > +			      u64 vm_handle)
> > +{
> > +	DECLARE_REG(u32, flags, ctxt, 2);
> > +
> > +	struct arm_smccc_1_2_regs *args = (void *)&ctxt->regs.regs[0];
> > +
> > +	/* filter out framework messages */
> > +	if (FIELD_GET(FFA_MSG_FLAGS_MSG_TYPE, flags)) {
> 
> Wouldn't we be better off just checking that flags is 0? The rest of it
> is SBZ or MBZ in the current spec.

Yes, we can simplify it in this way.

> 
> > +		ffa_to_smccc_error(res, FFA_RET_INVALID_PARAMETERS);
> > +		return;
> > +	}
> > +
> > +	arm_smccc_1_2_smc(args, res);
> > +}
> > +
> >  bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> >  {
> >  	struct arm_smccc_1_2_regs res;
> > @@ -920,6 +937,11 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> >  	case FFA_PARTITION_INFO_GET:
> >  		do_ffa_part_get(&res, host_ctxt);
> >  		goto out_handled;
> > +	case FFA_MSG_SEND_DIRECT_REQ:
> > +	case FFA_FN64_MSG_SEND_DIRECT_REQ:
> > +
> 
> Weird whitespace addition ^^
> 

Let me clear this space out.


> > +		do_ffa_direct_msg(&res, host_ctxt, HOST_FFA_ID);
> 
> What's the point of passing HOST_FFA_ID here? Is that supposed to end up
> in the Sender ID bits of W1?

I can remove it, this doesn't bring too much for upstream but on the
android kernel with guest-ffa it makes sense because we need to validate
the sender to prevent impersonation.

> 
> Will

Thanks,
Sebastian