Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

Hi Paul, Julien, Volodymyr,

This is another bug fix that I would like to get in 4.14. It doesn't
look like we need any changes to this patch, assuming that it is
accurate to the spec.

It would be nice if Volodymyr could provide more info on the spec side,
but honestly I trust his experience on this.

Paul, are you OK with this going into 4.14?



On Sat, 6 Jun 2020, Julien Grall wrote:
> (+Paul)
> 
> Hi,
> 
> On 18/05/2020 02:53, Volodymyr Babchuk wrote:
> > Trusted Applications use popular approach to determine required size
> > of buffer: client provides a memory reference with the NULL pointer to
> > a buffer. This is so called "Null memory reference".  TA updates the
> 
> NIT: You use double space after '.' here but all the others use a single
> space.
> 
> > reference with the required size and returns it back to client. Then
> > client allocates buffer of needed size and repeats the operation.
> > 
> > This behavior is described in TEE Client API Specification, paragraph
> > 3.2.5. Memory References.
> 
> From the spec, it is not a clear cut that NULL will always used as fetching
> the required size of an output buffer. In particular, they suggest to refer to
> the protocol.
> 
> In your commit message you indirectly point to an example where 0/NULL would
> have a different meaning depending on the flags. This is not explained in the
> TEE Client API Specification. Do you have some pointer I could use to check
> the behavior?
> 
> > 
> > OP-TEE represents this null memory reference as a TMEM parameter with
> > buf_ptr == NULL. This is the only case when we should allow TMEM
> > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag.
> 
> IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer at
> address 0" but with the flag cleared, it would mean "return the size". Am I
> correct?
> 
> > 
> > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
> The code looks to match your commit message, but I wasn't able to match it
> with the spec. Do you have other pointer I could use to check the behavior?
> 
> I assume this wants to be part of Xen 4.14. The change is only for OP-TEE
> which is a tech preview feature. So the risk is very limited.