Message-ID: <PA4PR04MB75207FF08A6C2EEC1944FFFE88D79@PA4PR04MB7520.eurprd04.prod.outlook.com>
Date:   Fri, 3 Feb 2023 14:13:53 +0000
From:   Cyrille Fleury <cyrille.fleury@....com>
To:     Jerome Forissier <jerome.forissier@...aro.org>,
        Etienne Carriere <etienne.carriere@...aro.org>,
        Olivier Masse <olivier.masse@....com>
CC:     "sumit.garg@...aro.org" <sumit.garg@...aro.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "fredgc@...gle.com" <fredgc@...gle.com>,
        "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
        "afd@...com" <afd@...com>,
        "op-tee@...ts.trustedfirmware.org" <op-tee@...ts.trustedfirmware.org>,
        "jens.wiklander@...aro.org" <jens.wiklander@...aro.org>,
        "joakim.bech@...aro.org" <joakim.bech@...aro.org>,
        "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        Peter Griffin <peter.griffin@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Clément Faure <clement.faure@....com>,
        "christian.koenig@....com" <christian.koenig@....com>
Subject: RE: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm
 from a dmabuf file descriptor



-----Original Message-----
From: Jerome Forissier <jerome.forissier@...aro.org>
Sent: Friday, February 3, 2023 1:32 PM
To: Etienne Carriere <etienne.carriere@...aro.org>; Olivier Masse <olivier.masse@....com>
Cc: sumit.garg@...aro.org; linux-media@...r.kernel.org; fredgc@...gle.com; linaro-mm-sig@...ts.linaro.org; afd@...com; op-tee@...ts.trustedfirmware.org; jens.wiklander@...aro.org; joakim.bech@...aro.org; sumit.semwal@...aro.org; Cyrille Fleury <cyrille.fleury@....com>; Peter Griffin <peter.griffin@...aro.org>; linux-kernel@...r.kernel.org; dri-devel@...ts.freedesktop.org; Clément Faure <clement.faure@....com>; christian.koenig@....com
Subject: Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor

On 2/3/23 15:12, Cyrille Fleury wrote:
Hi all,

>On 2/3/23 12:37, Etienne Carriere wrote:
>> Hell all,
>>
>> +jerome f.
>>
>> On Fri, 3 Feb 2023 at 12:01, Olivier Masse <olivier.masse@....com> wrote:
>>>
>>> On jeu., 2023-02-02 at 10:58 +0100, Etienne Carriere wrote:
>>>> Caution: EXT Email
>>>>
>>>> On Thu, 2 Feb 2023 at 09:35, Sumit Garg <sumit.garg@...aro.org>
>>>> wrote:
>>>>> Hi Cyrille,
>>>>>
>>>>> Please don't top post as it makes it harder to follow-up.
>>>>>
>>>>> On Thu, 2 Feb 2023 at 13:26, Cyrille Fleury <cyrille.fleury@....com
>>>>>> wrote:
>>>>>> Hi Sumit, all
>>>>>>
>>>>>> Upstream OP-TEE should support registering a dmabuf since a while, 
>>>>>> given how widely dmabuf is used in Linux for passing buffers 
>>>>>> around between devices.
>>>>>>
>>>>>> Purpose of the new register_tee_shm ioctl is to allow OPTEE to use 
>>>>>> memory allocated from the exiting linux dma buffer. We don't need 
>>>>>> to have secure dma-heap up streamed.
>>>>>>
>>>>>> You mentioned secure dma-buffer, but secure dma-buffer is a dma- 
>>>>>> buffer, so the work to be done for secure or "regular" dma buffers 
>>>>>> by the register_tee_shm ioctl is 100% the same.
>>>>>>
>>>>>> The scope of this ioctl is limited to what existing upstream dma- 
>>>>>> buffers are:
>>>>>>         -> sharing buffers for hardware (DMA) access across 
>>>>>> multiple device drivers and subsystems, and for synchronizing 
>>>>>> asynchronous hardware access.
>>>>>>        -> It means continuous memory only.
>>>>>>
>>>>>> So if we reduce the scope of register tee_shm to exiting dma- 
>>>>>> buffer area, the current patch does the job.
>>>>>
>>>>> Do you have a corresponding real world use-case supported by 
>>>>> upstream OP-TEE? AFAIK, the Secure Data Path (SDP) use-case is the 
>>>>> one supported in OP-TEE upstream but without secure dmabuf heap [1] 
>>>>> available, the new ioctl can't be exercised.
>>>>>
>>>>> [1] 
>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>>>>> ithub.com%2FOP-TEE%2Foptee_test%2Fblob%2Fmaster%2Fhost%2Fxtest%2Fsd
>>>>> p_basic.h%23L15&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962fb5
>>>>> 8f6401c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>>>>> 7C638110243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>>>>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=
>>>>> UNB88rvmhQ5qRoIGN%2FpS4cQTES5joM8AjoyAAYzPKl0%3D&reserved=0
>>>>
>>>> OP-TEE has some SDP test taht can exercice SDP: 'xtest 
>>>> regression_1014'.
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>>>> thub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fregr
>>>> ession_1000.c%23L1256&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff9
>>>> 62fb58f6401c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
>>>> 7C0%7C638110243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
>>>> a=e%2B40rwWvtvVFG8aWZNeu%2FgjMXXvZ3pRhJfHLkdurovs%3D&reserved=0
>>>>
>>>> The test relies on old staged ION + local secure dmabuf heaps no 
>>>> more maintained, so this test is currently not functional.
>>>> If we upgrade the test to mainline dmabuf alloc means, and apply the 
>>>> change discussed here, we should be able to regularly test SDP in 
>>>> OP-TEE project CI.
>>>> The part to update is the userland allocation of the dmabuf:
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>>>> thub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fsdp_
>>>> basic.c%23L91&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962fb58f6
>>>> 401c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
>>>> 8110243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
>>>> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5rPV1j
>>>> qzqjVh2N5pdUW41YwF6EkgIDwfhyfYkgmtdZI%3D&reserved=0
>>>>
>>>>
>>>
>>> the test was already updated to support secure dma heap with Kernel 
>>> version 5.11 and higher. the userland allocation could be find here:
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>> hub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fsdp_ba
>>> sic.c%23L153&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962fb58f640
>>> 1c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63811
>>> 0243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01H96n47K6R
>>> mBKZQhRdcqX3nE5VBHOXNfGuMmmkVSvc%3D&reserved=0
>>>
>>
>> Oh, right. So fine, optee_test is ready for the new flavor of secure 
>> buffer fd's.
>>
>>
>>> This upgrade need a Linux dma-buf patch:
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
>>> e.kernel.org%2Fall%2F20220805154139.2qkqxwklufjpsfdx%40000377403353%2
>>> FT%2F&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962fb58f6401c59780
>>> 8db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638110243232
>>> 457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>>> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yCS%2BDcuGp%2BafAL
>>> tpw74O1bI0K%2Fwnt%2FOw5ob1ngfDA0E%3D&reserved=0
>>
>> @Jens, @Jerome, do we want to pick the 2 necessary Linux patches in 
>> our Linux kernel fork (github.com/linaro-swg/linux.git) to exercise 
>> SDP in our CI and be ready if dma-buf secure heaps (ref right above) 
>> is accepted and merged in mainline kernel?.
>
>How would that help? I mean, when the kernel patches are merged and if things break we can make the necessary adjustments in the optee_test app or whatever, but in the meantime I don't see much point. I suppose the people who are actively developing the patches do make sure it works with OP-TEE ;-)
>
>Regards,
>--
>Jerome

As mentioned in the cover letter, this IOCTL got tested by Jens Wiklander <jens.wiklander@...aro.org>, using Linaro reference board from Hikey 6620:
https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmware.org/thread/I3TZN4TBDOUVE567VMMN2TAXGWZNY7S3/
It also works on i.MX8M EVK boards.

My understanding today is we are good to upstream this patch, knowing:
     - Upstream OPTEE driver should support registering a dmabuf since a while, given how widely dmabuf is used in Linux for passing buffers around between devices.
     - review is OK 
     - test environment is already available in optee-test
     - it has been tested on 2 different platforms
     - the scope of the new ioctl is limited to existing feature in dma-buffer
     
What is missing from this list preventing to upstream ? 
Who do we still need to convince ?

Regards.

Powered by blists - more mailing lists