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

[Paul Durrant <xadimgnik@gmail.com>]

> -----Original Message-----
> From: Stefano Stabellini <sstabellini@kernel.org>
> Sent: 18 June 2020 23:27
> To: xadimgnik@gmail.com; paul@xen.org; pdurrant@amazon.com
> Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>; sstabellini@kernel.org; xen-
> devel@lists.xenproject.org; paul@xen.org; julien@xen.org
> Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address
> 
> 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?
> 

In principle, yes. It appears, from Julien's comments though, that the commit message may need a little expansion (for the benefit
of those mining this code in future).

  Paul

> 
> 
> 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@epam.com>
> > 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.