Am Mittwoch, dem 17.08.2022 um 10:29 -0400 schrieb Nicolas Dufresne: > Hi Folks, > > Le mardi 16 août 2022 à 11:20 +0000, Olivier Masse a écrit : > > Hi Brian, > > > > > > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote: > > > Caution: EXT Ema > > > > > [...] > > > > > > > Interesting, that's not how the devices I've worked on operated. > > > > > > Are you saying that you have to have a display controller driver > > > running in the TEE to display one of these buffers? > > > > In fact the display controller is managing 3 plans : UI, PiP and > > video. The video plan is protected in secure as you can see on slide > > 11: > > https://static.linaro.org/connect/san19/presentations/san19-107.pdf > > > > just wanted to highlight that all the WPE/GStreamer bit in this presentation is > based on NXP Vendor Media CODEC design, which rely on their own i.MX VPU API. I > don't see any effort to extend this to a wider audience. It is not explaining > how this can work with a mainline kernel with v4l2 stateful or stateless drivers > and generic GStreamer/FFMPEG/Chromium support. > > I'm raising this, since I'm worried that no one cares of solving that high level > problem from a generic point of view. In that context, any additions to the > mainline Linux kernel can only be flawed and will only serves specific vendors > and not the larger audience. > > Another aspect, is that this design might be bound to a specific (NXP ?) > security design. I've learn recently that newer HW is going to use multiple > level of MMU (like virtual machines do) to protect the memory rather then > marking pages. Will all this work for that too ? > I have not looked in any of this for quite a while, but IIRC the plan was something like that: The NXP RDC hardware is able to segment the DDR memory into sections and define access policies for all masters in the system. So for example for the secure VPU to display controller path you would define such a section, where only the VPU is able to write and DCSS is able to read from. CPU or other masters are not allowed to use this section. This then gets exposed to Linux as a DMA heap. The VPU driver could then allocate capture buffers from this heap and share them via dma-buf to the DCSS driver. Both drivers can live in non-trusted userspace and even the address allocation for the DMA heap can be done from Linux. Non-trusted Linux kernel/userspace just has no way to access the buffers directly. The more interesting question is on the VPU side: how do you make sure that the capture buffer is located in secure memory when the output buffer containing the secret bitstream is also in a secure heap? I guess you need some kind of TEE application to validate those settings, which means you can't give the non-trusted driver direct MMIO access to the VPU. Regards, Lucas
