On Mon, Sep 18, 2023 at 11:33 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi Jason, CK, > > On Tue, 19 Sept 2023 at 04:04, Jason-JH.Lin <jason-jh.lin@xxxxxxxxxxxx> wrote: > > The patch series provides drm driver support for enabling secure video > > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > > > [...] > > > > Memory Usage in SVP: > > The overall flow of SVP starts with encrypted video coming in from an > > outside source into the REE. The REE will then allocate a 'secure > > buffer' and send the corresponding 'secure handle' along with the > > encrypted, compressed video data to the TEE. The TEE will then decrypt > > the video and store the result in the 'secure buffer'. The REE will > > then allocate a 'secure surface'. The REE will pass the 'secure > > handles' for both the 'secure buffer' and 'secure surface' into the > > TEE for video decoding. The video decoder HW will then decode the > > contents of the 'secure buffer' and place the result in the 'secure > > surface'. The REE will then attach the 'secure surface' to the overlay > > plane for rendering of the video. > > > > Everything relating to ensuring security of the actual contents of the > > 'secure buffer' and 'secure surface' is out of scope for the REE and > > is the responsibility of the TEE. > > > > DRM driver handles allocation of gem objects that are backed by a 'secure > > surface' and for displaying a 'secure surface' on the overlay plane. > > This introduces a new flag for object creation called > > DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure > > surface'. All changes here are in MediaTek specific code. > > To be honest, it seems strange that DRM is being used as the allocator > for buffers which will mostly be used by codec hardware which is not > mentioned here. I can understand that minigbm and gbm_gralloc make > this easy to implement, but it's not really right to add this all to > mtk-drm just to support some codec features. The buffers allocated are used as the output for secure video decoding and then rendering as well. So they aren't just used by the codec HW, they're also used for display on the overlay plane. And I'm the user of all the secure video path patches Mediatek has been posting, this is for secure video playback on ChromeOS ARM devices. (just mentioning so you know my context in this all) > > NXP posted a patchset a while ago to add secure-memory support to > dma-heaps[0]. This would be much cleaner (e.g. avoiding strcmp on > allocating name, avoiding mtk-drm being a render node when it can't > render) I think, and also allow common secure-path semantics between > different vendors. > Yes, I saw that now. I agree that having a common secure-path solution is preferable. But the two issues you mention with this patchset aren't directly related to the dma-buf heap implementation I think. The ugly strcmp can be removed from this patchset...because it doesn't actually need to check the heap name, it only ever invokes mtk_drm_gem_create_from_heap for secure memory allocations...so that should just be renamed mtk_drm_gem_create_from_secure_heap. The RENDER flag can also be removed. IIUC, that's an artifact of how ChromeOS is doing the allocations and that it's performing it on a render node. That can be removed from this patchset and we can address that problem on the ChromeOS side instead. Going back to the NXP implementation...the main difference between that one and what Mediatek is proposing (aside from all their vendor specific naming of things) is that the NXP patchset does all the allocation in the kernel itself and the kernel is handing out physical addresses from the reserved range w/ no virtual address mapping. I think that would mean you have to always allocate contiguous blocks, which would be prone to fragmentation. In the Mediatek implementation, they are doing the allocations from the heap in the TEE, so they can deal with physical memory fragmentation through virtual addresses since they can do SG lists to allocate from fragmented memory in the TEE. > Having common secure-path semantics between different vendors would be > very helpful, because the first question when we add new uAPI is > 'where is the open-source userspace?'. If there is at least a common > interface through e.g. dma-heaps, then we could have some standard > cross-vendor userspace code which would work well with the standard > interface. > Thanks for your feedback, I definitely want to work to get this to something more usable by a wider range. > Cheers, > Daniel > > [0]: https://lore.kernel.org/lkml/20220805135330.970-2-olivier.masse@xxxxxxx/
