On Tue, 26 Sept 2023 at 12:53, Rijo Thomas <rijo-john.tho...@amd.com> wrote:
>
> On 9/26/2023 12:14 PM, Sumit Garg wrote:
> > +cc Alex
> >
> > On Tue, 26 Sept 2023 at 08:16, Jens Wiklander <jens.wiklan...@linaro.org>
> > wrote:
> >>
> >> Hi,
> >>
> >> [+cc Arnd]
> >>
> >> On Tue, Sep 26, 2023 at 8:00 AM Sumit Garg <sumit.g...@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.
> >>>
> Yes, we have tested with AMD-TEE. We have not yet tested with OP-TEE. Sure,
> we will try it out.
Glad to hear that. I can help get it tested with OP-TEE as well.
>
> >>> Do you currently have any virtio frontend/backend implementations for
> >>> this?
> >>>
>
> Yes, we have. Frontend is a Linux virtio-TEE driver, and backend is
> virtio-TEE device emulated in QEMU.
> We used the Xen hypervisor.
Can you share corresponding references? I can give it a try using Qemu with KVM.
>
> >>>>
> >>>> 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.
> We have a command VIRTIO_TEE_CMD_REGISTER_MEM for registering shared memory
> buffer with Trusted OS.
I suppose the commit message has to be appended then. Do you have the
draft virtio-tee device specification ready for review? I would be
interested to review that.
>
> In this command, the guest pages are copied into a shadow buffer in the host
> OS. And this shadow
> buffer is mapped with Trusted OS. So, buffer-copy is involved.
>
> One limitation, that we had was that the guest pages were non-contiguous. So,
> the number of physical
> pages that had to be mapped with Trusted OS was exceeding 64 entries when we
> were testing out the
> registering of guest pages. AMD-TEE Trusted OS can map a physically
> non-contiguous buffer, but the
> number of sg entries for such a buffer must be less than 64. So, we resorted
> to using a shadow buffer
> that is allocated within host, and gets mapped with Trusted OS.
I don't think OP-TEE OS has such a limitation on non-contiguous pages.
So I would suggest you to keep VIRTIO_TEE_CMD_REGISTER_MEM as part of
the ABI. It can be an optional feature for a particular trusted OS
implementation to support.
-Sumit
>
> Thanks,
> Rijo
>
> >>
> >> 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...@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,
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
