+cc Alex
On Tue, 26 Sept 2023 at 08:16, Jens Wiklander <
jens.wiklander@linaro.org> wrote:
>
> Hi,
>
> [+cc Arnd]
>
> On Tue, Sep 26, 2023 at 8:00?AM Sumit Garg <
sumit.garg@linaro.org> wrote:
> >
> > +cc Jens
> >
> > > In a virtual environment, an application running in guest VM may want
> > > to delegate security sensitive tasks to a Trusted Application (TA)
> > > running within a Trusted Execution Environment (TEE). A TEE is a trusted
> > > OS running in some secure environment, for example, TrustZone on ARM
> > > CPUs, or a separate secure co-processor etc.
> >
> > I have been exploring this area quite recently with an effort to have a common VIRIO interface which can support different trusted OS implementations. I guess you intend to test it with AMD-TEE, right? Any plans to test it with OP-TEE? As currently we have these two supported upstream.
> >
> > Do you currently have any virtio frontend/backend implementations for this?
> >
> > >
> > > A virtual TEE device emulates a TEE within a guest VM. Such a virtual
> > > TEE device supports multiple operations such as:
> > >
> > > VIRTIO_TEE_CMD_OPEN_DEVICE – Open a communication channel with virtio
> > > TEE device.
> > > VIRTIO_TEE_CMD_CLOSE_DEVICE – Close communication channel with virtio
> > > TEE device.
> > > VIRTIO_TEE_CMD_GET_VERSION – Get version of virtio TEE.
> > > VIRTIO_TEE_CMD_OPEN_SESSION – Open a session to communicate with
> > > trusted application running in TEE.
> > > VIRTIO_TEE_CMD_CLOSE_SESSION – Close a session to end communication
> > > with trusted application running in TEE.
> > > VIRTIO_TEE_CMD_INVOKE_FUNC – Invoke a command or function in trusted
> > > application running in TEE.
> > > VIRTIO_TEE_CMD_CANCEL_REQ – Cancel an ongoing command within TEE.
> > >
> >
> > How about shared memory support? We would like to register guest pages with the trusted OS.
>
> Coincidently Arnd and I (among others) discussed this in person last
> week and the conclusion was that only temporary shared memory is
> possible with virtio. So the shared memory has to be set up and torn
> down by the host during each operation, typically open-session or
> invoke-func.
Agree as I was part of those discussions. But I would like to
understand the reasoning behind it. Is there any restriction by VIRTIO
specification that we can't register guest page PAs to a device (TEE
in our case) to allow for zero copy transfers?
Alex mentioned some references to virtio GPU device. I suppose I need
to dive into its implementation to see if there are any similarities
to our use-case.
> That might not be optimal if trying to maximize
> performance, but it is portable.
IMO, the ABI should be flexible enough to support a TEE with optimum
performance.
-Sumit
>
> Cheers,
> Jens
>
> >
> > -Sumit
> >
> > > We would like to reserve device ID 46 for Virtio-TEE device.
> > >
> > > Signed-off-by: Jeshwanth Kumar <
jeshwanthkumar.nk@amd.com>
> > > ---
> > > content.tex | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/content.tex b/content.tex
> > > index 0a62dce..644aa4a 100644
> > > --- a/content.tex
> > > +++ b/content.tex
> > > @@ -739,6 +739,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > > \hline
> > > 45 & SPI master \\
> > > \hline
> > > +46 & TEE device \\
> > > +\hline
> > > \end{tabular}
> > >
> > > Some of the devices above are unspecified by this document,