Hi, On Wed, Mar 5, 2025 at 2:06 PM Jens Wiklander <jens.wiklan...@linaro.org> wrote: > > Hi, > > This patch set allocates the restricted DMA-bufs from a DMA-heap > instantiated from the TEE subsystem. > > The TEE subsystem handles the DMA-buf allocations since it is the TEE > (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the > restrictions for the memory used for the DMA-bufs. > > The DMA-heap uses a restricted memory pool provided by the backend TEE > driver, allowing it to choose how to allocate the restricted physical > memory. > > The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD > before they can be passed as arguments when requesting services from the > secure world. > > Three use-cases (Secure Video Playback, Trusted UI, and Secure Video > Recording) has been identified so far to serve as examples of what can be > expected. The use-cases has predefined DMA-heap names, > "restricted,secure-video", "restricted,trusted-ui", and > "restricted,secure-video-record". The backend driver registers restricted > memory pools for the use-cases it supports.
When preparing a v7 of this patch set, I'll switch to "protected" instead of "restricted" based on Nicolas Dufresne's comment [1], unless someone objects. [1] https://lore.kernel.org/lkml/32c29526416c07c37819aedabcbf1e562ee98bf2.ca...@ndufresne.ca/ Cheers, Jens > > Each use-case has it's own restricted memory pool since different use-cases > requires isolation from different parts of the system. A restricted memory > pool can be based on a static carveout instantiated while probing the TEE > backend driver, or dynamically allocated from CMA and made restricted as > needed by the TEE. > > This can be tested on a RockPi 4B+ with the following steps: > repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ > -b prototype/sdp-v6 > repo sync -j8 > cd build > make toolchains -j$(nproc) > make all -j$(nproc) > # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that > # Connect a monitor to the RockPi > # login and at the prompt: > gst-launch-1.0 videotestsrc ! \ > aesenc key=1f9423681beb9a79215820f6bda73d0f \ > iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ > aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ > kmssink > > The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream > into restricted DMA-bufs which are consumed by the kmssink. > > The primitive QEMU tests from previous patch set can be tested on RockPi > in the same way with: > xtest --sdp-basic > > The primitive test are tested on QEMU with the following steps: > repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ > -b prototype/sdp-v6 > repo sync -j8 > cd build > make toolchains -j$(nproc) > make SPMC_AT_EL=1 all -j$(nproc) > make SPMC_AT_EL=1 run-only > # login and at the prompt: > xtest --sdp-basic > > The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at > S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test > without FF-A using the original SMC ABI instead. Please remember to do > %rm -rf ../trusted-firmware-a/build/qemu > for TF-A to be rebuilt properly using the new configuration. > > https://optee.readthedocs.io/en/latest/building/prerequisites.html > list dependencies needed to build the above. > > The tests are pretty basic, mostly checking that a Trusted Application in > the secure world can access and manipulate the memory. There are also some > negative tests for out of bounds buffers etc. > > Thanks, > Jens > > Changes since V5: > * Removing "tee: add restricted memory allocation" and > "tee: add TEE_IOC_RSTMEM_FD_INFO" > * Adding "tee: implement restricted DMA-heap", > "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", > "tee: add tee_shm_alloc_cma_phys_mem()", > "optee: pass parent device to tee_device_alloc()", and > "tee: tee_device_alloc(): copy dma_mask from parent device" > * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced > with a struct tee_rstmem_pool abstraction. > * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API > > Changes since V4: > * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the > GStreamer demo > * Removing the dummy CPU access and mmap functions from the dma_buf_ops > * Fixing a compile error in "optee: FF-A: dynamic restricted memory > allocation" > reported by kernel test robot <l...@intel.com> > > Changes since V3: > * Make the use_case and flags field in struct tee_shm u32's instead of > u16's > * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file > * Import namespace DMA_BUF in module tee, reported by l...@intel.com > * Added a note in the commit message for "optee: account for direction > while converting parameters" why it's needed > * Factor out dynamic restricted memory allocation from > "optee: support restricted memory allocation" into two new commits > "optee: FF-A: dynamic restricted memory allocation" and > "optee: smc abi: dynamic restricted memory allocation" > * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic > restricted memory allocate if CMA isn't configured > > Changes since the V2 RFC: > * Based on v6.12 > * Replaced the flags for SVP and Trusted UID memory with a u32 field with > unique id for each use case > * Added dynamic allocation of restricted memory pools > * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory > * Added support for FF-A with FFA_LEND > > Changes since the V1 RFC: > * Based on v6.11 > * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC > > Changes since Olivier's post [2]: > * Based on Yong Wu's post [1] where much of dma-buf handling is done in > the generic restricted heap > * Simplifications and cleanup > * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap > support" > * Replaced the word "secure" with "restricted" where applicable > > Etienne Carriere (1): > tee: new ioctl to a register tee_shm from a dmabuf file descriptor > > Jens Wiklander (9): > tee: tee_device_alloc(): copy dma_mask from parent device > optee: pass parent device to tee_device_alloc() > optee: account for direction while converting parameters > optee: sync secure world ABI headers > tee: implement restricted DMA-heap > tee: add tee_shm_alloc_cma_phys_mem() > optee: support restricted memory allocation > optee: FF-A: dynamic restricted memory allocation > optee: smc abi: dynamic restricted memory allocation > > drivers/tee/Makefile | 1 + > drivers/tee/optee/Makefile | 1 + > drivers/tee/optee/call.c | 10 +- > drivers/tee/optee/core.c | 1 + > drivers/tee/optee/ffa_abi.c | 194 +++++++++++- > drivers/tee/optee/optee_ffa.h | 27 +- > drivers/tee/optee/optee_msg.h | 65 ++++- > drivers/tee/optee/optee_private.h | 55 +++- > drivers/tee/optee/optee_smc.h | 71 ++++- > drivers/tee/optee/rpc.c | 31 +- > drivers/tee/optee/rstmem.c | 329 +++++++++++++++++++++ > drivers/tee/optee/smc_abi.c | 190 ++++++++++-- > drivers/tee/tee_core.c | 147 +++++++--- > drivers/tee/tee_heap.c | 470 ++++++++++++++++++++++++++++++ > drivers/tee/tee_private.h | 7 + > drivers/tee/tee_shm.c | 199 ++++++++++++- > include/linux/tee_core.h | 67 +++++ > include/linux/tee_drv.h | 10 + > include/uapi/linux/tee.h | 29 ++ > 19 files changed, 1781 insertions(+), 123 deletions(-) > create mode 100644 drivers/tee/optee/rstmem.c > create mode 100644 drivers/tee/tee_heap.c > > > base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6 > -- > 2.43.0 >
