linux-kernel - Re: [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 10 Apr 2024 10:53:31 +0100
From: Vincent Donnefort <vdonnefort@...gle.com>
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, will@...nel.org, yuzenghui@...wei.com,
	kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO_GET

[...]

> > > +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.

I see "Return the count of partitions deployed in the system corresponding to
the specified UUID in w2"

Which I believe means nothing has been copied in the buffer?

> 
> > > +
> > > +	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.

WARN() is crashing the hypervisor. It'd be a shame here as we can easily recover
by just sending an error back to the caller.