Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Hi Cyrille, On Mon, Feb 13, 2023 at 1:41 PM Cyrille Fleury wrote: > > Hi, > > >> > >> > >> -Original Message- > >> From: Jerome Forissier > >> Sent: Friday, February 3, 2023 1:32 PM > >> To: Etienne Carriere ; Olivier Masse > >> > >> Cc: sumit.g...@linaro.org; linux-me...@vger.kernel.org; > >> fre...@google.com; linaro-mm-...@lists.linaro.org; a...@ti.com; > >> op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > >> joakim.b...@linaro.org; sumit.sem...@linaro.org; Cyrille Fleury > >> ; Peter Griffin ; > >> linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Clément > >> Faure ; christian.koe...@amd.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 > >> >> 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 > >> >>>> 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 > >> >>>>> >> >>>>>> 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%2F&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C057d956d144a41e > >> >>>>> dd81808db0db1c7f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 > >> >>>>> 38118829451030288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > >> >>>>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> >>>>> ta=tBh3qNiinzTn%2BgqE8IvGw%2BYvRvo8ztDt4W4O0noEkk8%3D&reserved=0 > >> >>>>> ithub.com%2FOP-TEE%2Foptee_test%2Fblob%2Fmaster%2Fhost%2Fxtest%2 > >>
RE: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Hi, >> >> >> -Original Message- >> From: Jerome Forissier >> Sent: Friday, February 3, 2023 1:32 PM >> To: Etienne Carriere ; Olivier Masse >> >> Cc: sumit.g...@linaro.org; linux-me...@vger.kernel.org; >> fre...@google.com; linaro-mm-...@lists.linaro.org; a...@ti.com; >> op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; >> joakim.b...@linaro.org; sumit.sem...@linaro.org; Cyrille Fleury >> ; Peter Griffin ; >> linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Clément >> Faure ; christian.koe...@amd.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 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 >> >>>> 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 >> >>>>> > >>>>>> 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%2F&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C057d956d144a41e >> >>>>> dd81808db0db1c7f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 >> >>>>> 38118829451030288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC >> >>>>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda >> >>>>> ta=tBh3qNiinzTn%2BgqE8IvGw%2BYvRvo8ztDt4W4O0noEkk8%3D&reserved=0 >> >>>>> ithub.com%2FOP-TEE%2Foptee_test%2Fblob%2Fmaster%2Fhost%2Fxtest%2 >> >>>>> Fsd >> >>>>> p_basic.h%23L15&data=05%7C01%7Ccyrille.fleury%40nxp.com%7C9ff962 >> >>>>> fb5 >> >>>>> 8f6401c597808db05e2a64b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 >> >>>>> C0% >> >>>>> 7C638110243232457377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA >> >>>>> iLC >> >>>>> JQIjoiV2luMzIiLCJBT
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Hi, On Fri, Feb 03, 2023 at 02:13:53PM +, Cyrille Fleury wrote: > > > -Original Message- > From: Jerome Forissier > Sent: Friday, February 3, 2023 1:32 PM > To: Etienne Carriere ; Olivier Masse > > Cc: sumit.g...@linaro.org; linux-me...@vger.kernel.org; fre...@google.com; > linaro-mm-...@lists.linaro.org; a...@ti.com; > op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > joakim.b...@linaro.org; sumit.sem...@linaro.org; Cyrille Fleury > ; Peter Griffin ; > linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Clément Faure > ; christian.koe...@amd.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 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 > >>>> 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 >>>>>> 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=
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 Sent: Friday, February 3, 2023 1:32 PM To: Etienne Carriere ; Olivier Masse Cc: sumit.g...@linaro.org; linux-me...@vger.kernel.org; fre...@google.com; linaro-mm-...@lists.linaro.org; a...@ti.com; op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; joakim.b...@linaro.org; sumit.sem...@linaro.org; Cyrille Fleury ; Peter Griffin ; linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Clément Faure ; christian.koe...@amd.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 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 >>>> 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 >>>>> 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
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
On 2/3/23 12:37, Etienne Carriere wrote: > Hell all, > > +jerome f. > > On Fri, 3 Feb 2023 at 12:01, Olivier Masse 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 >>> 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 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://github.com/OP-TEE/optee_test/blob/master/host/xtest/sdp_basic.h#L15 >>> >>> OP-TEE has some SDP test taht can exercice SDP: 'xtest >>> regression_1014'. >>> https://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/regression_1000.c#L1256 >>> >>> 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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L91 >>> >>> >> >> 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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L153 >> > > 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://lore.kernel.org/all/20220805154139.2qkqxwklufjpsfdx@000377403353/T/ > > @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
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
On Fri, 3 Feb 2023 at 16:31, Olivier Masse 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 > > 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 > > > 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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2Fmaster%2Fhost%2Fxtest%2Fsdp_basic.h%23L15&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eNUbc0uaKjfmxau8L7ZB8u%2BtYdUxT4pIS%2Fht29uwRKg%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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fregression_1000.c%23L1256&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BOtAlVOq7%2Fi6SloSTZuwa5VtlC5RqtcJ4fGtio0YI8A%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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fsdp_basic.c%23L91&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K2NB2Bj7V3CXNsM9fZy95OEjF3EzqU4mgmM1PTY3J1Y%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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L153 > > This upgrade need a Linux dma-buf patch: > https://lore.kernel.org/all/20220805154139.2qkqxwklufjpsfdx@000377403353/T/ > I would suggest you to club this new ioctl patch with this secure dmabuf heap series so that you can provide a complete SDP use-case picture with a working SDP xtest case. -Sumit > > > br, > > etienne > > > > > > > -Sumit > > > > > > > Regards. > > > > > > > > -----Original Message- > > > > From: Sumit Garg
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Hell all, +jerome f. On Fri, 3 Feb 2023 at 12:01, Olivier Masse 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 > > 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 > > > 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://github.com/OP-TEE/optee_test/blob/master/host/xtest/sdp_basic.h#L15 > > > > OP-TEE has some SDP test taht can exercice SDP: 'xtest > > regression_1014'. > > https://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/regression_1000.c#L1256 > > > > 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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L91 > > > > > > 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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L153 > 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://lore.kernel.org/all/20220805154139.2qkqxwklufjpsfdx@000377403353/T/ @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?. Br, etienne > > > > br, > > etienne > > > > > > > -Sumit > > > > > > > Regards. > > > > > > > > -Original Message----- > > > > From: Sumit Garg > > > > Sent: Wednesday, February 1, 2023 6:34 AM > > > > To: Olivier Masse > > > > Cc: fre...@google.com; linux-me...@vger.kernel.org; > > > > linaro-mm-...@lists.linaro.org; a...@ti.com; > > > > op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > > > > joakim.b...@linaro.org; sumit.sem...@linaro.org; Peter Griffin < > > > > peter.grif...@linaro.org>; linux-ker...@vger.kernel.org; > > > > etienne.carri...@linaro.org; dri-devel@lists.freedesktop.org; > > > > christian.koe...@amd.com; Clément Faure ; > > > > Cyrille Fleury > > > > Subject: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register > > > > tee_shm from a dmabuf file descriptor > > > > > > > > Caution: EXT Email > > > > > > > > Hi Olivier, > > > > > > > > On Fri, 27 Jan 2023 at 16:24, Olivier Masse
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
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 > 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 > > 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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2Fmaster%2Fhost%2Fxtest%2Fsdp_basic.h%23L15&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eNUbc0uaKjfmxau8L7ZB8u%2BtYdUxT4pIS%2Fht29uwRKg%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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fregression_1000.c%23L1256&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BOtAlVOq7%2Fi6SloSTZuwa5VtlC5RqtcJ4fGtio0YI8A%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%2Fgithub.com%2FOP-TEE%2Foptee_test%2Fblob%2F3.20.0%2Fhost%2Fxtest%2Fsdp_basic.c%23L91&data=05%7C01%7Colivier.masse%40nxp.com%7Ca27f690d9d7244c2bcff08db05040f11%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638109287211847995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K2NB2Bj7V3CXNsM9fZy95OEjF3EzqU4mgmM1PTY3J1Y%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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L153 This upgrade need a Linux dma-buf patch: https://lore.kernel.org/all/20220805154139.2qkqxwklufjpsfdx@000377403353/T/ > br, > etienne > > > > -Sumit > > > > > Regards. > > > > > > -Original Message- > > > From: Sumit Garg > > > Sent: Wednesday, February 1, 2023 6:34 AM > > > To: Olivier Masse > > > Cc: fre...@google.com; linux-me...@vger.kernel.org; > > > linaro-mm-...@lists.linaro.org; a...@ti.com; > > > op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > > > joakim.b...@linaro.org; sumit.sem...@linaro.org; Peter Griffin < > > > peter.grif...@linaro.org>; linux-ker...@vger.kernel.org; > > > etienne.carri...@linaro.org; dri-devel@lists.freedesktop.org; > > > christian.koe...@amd.com; Clément Faure ; > > > Cyril
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
On Thu, 2 Feb 2023 at 09:35, Sumit Garg 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 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://github.com/OP-TEE/optee_test/blob/master/host/xtest/sdp_basic.h#L15 OP-TEE has some SDP test taht can exercice SDP: 'xtest regression_1014'. https://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/regression_1000.c#L1256 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://github.com/OP-TEE/optee_test/blob/3.20.0/host/xtest/sdp_basic.c#L91 br, etienne > > -Sumit > > > > > Regards. > > > > -Original Message- > > From: Sumit Garg > > Sent: Wednesday, February 1, 2023 6:34 AM > > To: Olivier Masse > > Cc: fre...@google.com; linux-me...@vger.kernel.org; > > linaro-mm-...@lists.linaro.org; a...@ti.com; > > op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > > joakim.b...@linaro.org; sumit.sem...@linaro.org; Peter Griffin > > ; linux-ker...@vger.kernel.org; > > etienne.carri...@linaro.org; dri-devel@lists.freedesktop.org; > > christian.koe...@amd.com; Clément Faure ; Cyrille > > Fleury > > Subject: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from > > a dmabuf file descriptor > > > > Caution: EXT Email > > > > Hi Olivier, > > > > On Fri, 27 Jan 2023 at 16:24, Olivier Masse wrote: > > > > > > Hi Joakim, > > > Hi Etienne, > > > > > > Let me bring back this pull request for OPTEE Linux driver. > > > > > > Last feedback was from Christian König and Sumit Garg. > > > From Christian: > > > > Just two comments: > > > > > > > > 1. Dmitry is working on a change which renames some functions and > > > > makes it mandatory to call them with the dma_resv lock held. > > > > > > > > Depending on how you want to upstream this change you will certainly > > > > run into conflicts with that. > > > > > > Is there any update on these changes ? > > > > > > > > > > > 2. Would it be possible to do this dynamically? In other words does > > > > the tee driver has a concept of buffers moving around? > > > > > > We do not support dynamic secure memory heap. > > > > > > From Sumit: > > > > What limits you to extend this feature to non-contiguous memory > > > > buffers? I believe that should be possible with OP-TEE dynamic > > > > shared memory which gives you the granularity to register a list of > > > > pages. > > > > > > Our solution use a fixed protected reserved memory region and do not > > > rely on a dynamic protection managed in secure. > > > > > > The scope of this implementation rely on a static memory region > > > handled by a specific DMA Heap type. > > > > > > > AFAIR, the last review for v2 is here [1]. So we need to hav
Re: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
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 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://github.com/OP-TEE/optee_test/blob/master/host/xtest/sdp_basic.h#L15 -Sumit > > Regards. > > -Original Message- > From: Sumit Garg > Sent: Wednesday, February 1, 2023 6:34 AM > To: Olivier Masse > Cc: fre...@google.com; linux-me...@vger.kernel.org; > linaro-mm-...@lists.linaro.org; a...@ti.com; > op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; > joakim.b...@linaro.org; sumit.sem...@linaro.org; Peter Griffin > ; linux-ker...@vger.kernel.org; > etienne.carri...@linaro.org; dri-devel@lists.freedesktop.org; > christian.koe...@amd.com; Clément Faure ; Cyrille > Fleury > Subject: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a > dmabuf file descriptor > > Caution: EXT Email > > Hi Olivier, > > On Fri, 27 Jan 2023 at 16:24, Olivier Masse wrote: > > > > Hi Joakim, > > Hi Etienne, > > > > Let me bring back this pull request for OPTEE Linux driver. > > > > Last feedback was from Christian König and Sumit Garg. > > From Christian: > > > Just two comments: > > > > > > 1. Dmitry is working on a change which renames some functions and > > > makes it mandatory to call them with the dma_resv lock held. > > > > > > Depending on how you want to upstream this change you will certainly > > > run into conflicts with that. > > > > Is there any update on these changes ? > > > > > > > > 2. Would it be possible to do this dynamically? In other words does > > > the tee driver has a concept of buffers moving around? > > > > We do not support dynamic secure memory heap. > > > > From Sumit: > > > What limits you to extend this feature to non-contiguous memory > > > buffers? I believe that should be possible with OP-TEE dynamic > > > shared memory which gives you the granularity to register a list of pages. > > > > Our solution use a fixed protected reserved memory region and do not > > rely on a dynamic protection managed in secure. > > > > The scope of this implementation rely on a static memory region > > handled by a specific DMA Heap type. > > > > AFAIR, the last review for v2 is here [1]. So we need to have this secure DMA > heap upstream in order for ioctl added by this patch to be usable. > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trustedfirmware.org%2Farchives%2Flist%2Fop-tee%40lists.trustedfirmware.org%2Fmessage%2FM3WLO7RNG22OR4744BY6XNG2GLIYMNHN%2F&data=05%7C01%7Ccyrille.fleury%40nxp.com%7Cb24461a4e7284314dff408db0415f23e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638108264533221384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6pRAqnMlJ0TX000YmlgTkPKn411VBC%2Bj29O9KhJjJOg%3D&reserved=0 > > -Sumit > > > Best regards, > > Olivier MASSE > > > > > > On ven., 2022-08-12 at 16:30 +0200, Olivier Masse wrote: > > > From: Etienne Carriere > > > > > > This change allows userland to create a tee_shm object that refers > > > to a dmabuf reference. > > > > > > Userland provides a dmabuf file descriptor as buffer reference. > > > The created tee_shm object exported as a brand new dmabuf reference > > > used to provide a clea
RE: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
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. Regards. -Original Message- From: Sumit Garg Sent: Wednesday, February 1, 2023 6:34 AM To: Olivier Masse Cc: fre...@google.com; linux-me...@vger.kernel.org; linaro-mm-...@lists.linaro.org; a...@ti.com; op-...@lists.trustedfirmware.org; jens.wiklan...@linaro.org; joakim.b...@linaro.org; sumit.sem...@linaro.org; Peter Griffin ; linux-ker...@vger.kernel.org; etienne.carri...@linaro.org; dri-devel@lists.freedesktop.org; christian.koe...@amd.com; Clément Faure ; Cyrille Fleury Subject: [EXT] Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor Caution: EXT Email Hi Olivier, On Fri, 27 Jan 2023 at 16:24, Olivier Masse wrote: > > Hi Joakim, > Hi Etienne, > > Let me bring back this pull request for OPTEE Linux driver. > > Last feedback was from Christian König and Sumit Garg. > From Christian: > > Just two comments: > > > > 1. Dmitry is working on a change which renames some functions and > > makes it mandatory to call them with the dma_resv lock held. > > > > Depending on how you want to upstream this change you will certainly > > run into conflicts with that. > > Is there any update on these changes ? > > > > > 2. Would it be possible to do this dynamically? In other words does > > the tee driver has a concept of buffers moving around? > > We do not support dynamic secure memory heap. > > From Sumit: > > What limits you to extend this feature to non-contiguous memory > > buffers? I believe that should be possible with OP-TEE dynamic > > shared memory which gives you the granularity to register a list of pages. > > Our solution use a fixed protected reserved memory region and do not > rely on a dynamic protection managed in secure. > > The scope of this implementation rely on a static memory region > handled by a specific DMA Heap type. > AFAIR, the last review for v2 is here [1]. So we need to have this secure DMA heap upstream in order for ioctl added by this patch to be usable. [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trustedfirmware.org%2Farchives%2Flist%2Fop-tee%40lists.trustedfirmware.org%2Fmessage%2FM3WLO7RNG22OR4744BY6XNG2GLIYMNHN%2F&data=05%7C01%7Ccyrille.fleury%40nxp.com%7Cb24461a4e7284314dff408db0415f23e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638108264533221384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6pRAqnMlJ0TX000YmlgTkPKn411VBC%2Bj29O9KhJjJOg%3D&reserved=0 -Sumit > Best regards, > Olivier MASSE > > > On ven., 2022-08-12 at 16:30 +0200, Olivier Masse wrote: > > From: Etienne Carriere > > > > This change allows userland to create a tee_shm object that refers > > to a dmabuf reference. > > > > Userland provides a dmabuf file descriptor as buffer reference. > > The created tee_shm object exported as a brand new dmabuf reference > > used to provide a clean fd to userland. Userland shall closed this > > new fd to release the tee_shm object resources. The initial dmabuf > > resources are tracked independently through original dmabuf file > > descriptor. > > > > Once the buffer is registered and until it is released, TEE driver > > keeps a refcount on the registered dmabuf structure. > > > > This change only support dmabuf references that relates to > > physically contiguous memory buffers. > > > > New tee_shm flag to identify tee_shm objects built from a registered > > dmabuf: TEE_SHM_EXT_DMA_BUF. Such tee_shm structures are flagged > > with TEE_SHM_EXT_DMA_BUF. > > > > Co-Developed-by: Etienne Carriere > > Signed-off-by: Olivier Masse > > Reported-by: kernel test robot > > From: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >
