From: Rijo Thomas <Rijo-john.Thomas@amd.com>
To: Sumit Garg <sumit.garg@linaro.org>,
Jens Wiklander <jens.wiklander@linaro.org>
Cc: jeshwanthkumar.nk@amd.com, Devaraj.Rangasamy@amd.com,
Mythri.Pandeshwarakrishna@amd.com, Nimesh.Easow@amd.com,
babulu.ellune@amd.com, virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org,
"Arnd Bergmann" <arnd.bergmann@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [virtio-dev] [PATCH v2] virtio-tee: Reserve device ID 46 for TEE device
Date: Tue, 26 Sep 2023 13:03:00 +0530 [thread overview]
Message-ID: <13b4d5a6-7e3f-e5cd-900a-694a076e7cf9@amd.com> (raw)
In-Reply-To: <CAFA6WYOsPhFkyrG0P7B6Ec=AnDvoUaerLocM89KtmybLmKbsaw@mail.gmail.com>
On 9/26/2023 12:14 PM, Sumit Garg wrote:
> +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.
>>>
Yes, we have tested with AMD-TEE. We have not yet tested with OP-TEE. Sure, we will try it out.
>>> 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 Xen hypervisor.
>>>
>>>>
>>>> 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.
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.
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.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,
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-09-26 7:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 11:17 [virtio-dev] [PATCH v2] virtio-tee: Reserve device ID 46 for TEE device jeshwank
2023-09-25 15:38 ` Parav Pandit
2023-09-26 4:52 ` NK, JESHWANTHKUMAR
2023-09-26 5:09 ` NK, JESHWANTHKUMAR
2023-09-26 5:12 ` NK, JESHWANTHKUMAR
2023-09-26 6:00 ` Sumit Garg
[not found] ` <CAHUa44GzHPkntr=sFYYzokW0=9CCN7n6Ch1i6J7L7Uhh5U5P3A@mail.gmail.com>
2023-09-26 6:44 ` Sumit Garg
2023-09-26 7:33 ` Rijo Thomas [this message]
[not found] ` <b15e849c-f424-1afb-4b99-ae2df954a044@amd.com>
2023-09-26 7:49 ` Sumit Garg
2023-09-26 8:17 ` Rijo Thomas
2023-09-26 12:32 ` Sumit Garg
2023-09-26 13:46 ` Rijo Thomas
[not found] ` <CAKWjNY-tixKn=N2_5vcjZHEuh0bBE9BpFXwRV7Y5MDDLsPYzfw@mail.gmail.com>
[not found] ` <CAFA6WYMraufRMwK=u+5pn4r2a4g-RzcLFiJiNa+t=CjjAE+_xA@mail.gmail.com>
[not found] ` <CAKWjNY-Gf-Kf1Ldsni6oXp2+POghFWWg36WYtvZcnUXqhurcLw@mail.gmail.com>
2023-09-28 14:48 ` Sumit Garg
[not found] ` <8124dd4b-d69d-46ca-8b39-7d0aacb078f7@app.fastmail.com>
2023-10-06 8:00 ` Sumit Garg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13b4d5a6-7e3f-e5cd-900a-694a076e7cf9@amd.com \
--to=rijo-john.thomas@amd.com \
--cc=Devaraj.Rangasamy@amd.com \
--cc=Mythri.Pandeshwarakrishna@amd.com \
--cc=Nimesh.Easow@amd.com \
--cc=alex.bennee@linaro.org \
--cc=arnd.bergmann@linaro.org \
--cc=babulu.ellune@amd.com \
--cc=jens.wiklander@linaro.org \
--cc=jeshwanthkumar.nk@amd.com \
--cc=sumit.garg@linaro.org \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox