Security issues when using SDP shared memory

[YogzZ]

No description provided.

[YogzZ]

I am a new researcher on OS and TEE and I have some question about SDP:

1. My understand about the process about shared memory is that
   ------(a) CA allocate the ION buffer "fd" by function "allocate_ion_buffer()";
   ------(b) CA use TEEC_SharedMemory "shm_ref" refer to "fd" by function "tee_register_buffer()";
   ------(c) CA tansfer "shm_ref" to TA by function "TEEC_InvokeCommand()";
   ------(d) "fd" will be kept until the CA ends the process.
   ------Is my understand correct?
2. If 1. (d) is correct, how to ensure the safety of "fd" in CA?
3. Will ION take over all the heap include TA heaps?
4. How to understand
   ------(a) "SMA mechanism assume non-secure world manipulates the secure memory reference in clear form."
   ------(b) "The defined ION secure heap type allocation algorithm ○ None of the natively supported ION heaps offer the service expected by a secure memory allocator ○ Need to allocate a physical region of memory the allocator cannot access." Is it means that CA only holds virtual addresses and cannot correspond to actual physical addresses, but TA can do it?
   ------(c) "OP-TEE chose the Linux kernel native “dma-buf” framework to reference SDP memory buffers: ○ Linux user-space, SDP buffer referred to by a dma-buf file descriptor ○ Linux kernel-space, SDP buffer referred to by a dma-buf handle." Is it because dma-buf is only used in kernel mode, so SDP buffer ensure security in user mode? How is the security in the kernel mode guaranteed?

[etienne-lms]

Hello @YogzZ,
I understand you refer to "bud17-400: Secure Data Path with OPTEE".
Note: I don't think SMA is a widely used acronym. In OP-TEE we refer to SDP, using ION UNMAP heaps.
Maybe have a look at san19-107 that details how a platform uses OP-TEE SDP to provide a secure video streaming path.

1. ...
   ------Is my understand correct?

Your description looks right.

If 1. (d) is correct, how to ensure the safety of "fd" in CA?

Safety of the fd value itself in CA should not be needed, from protected content security point of view.
CA could change fd value, non-secure OS & secure world should be resilient to that: fd values are owned by contexts & sessions.

3. Will ION take over all the heap include TA heaps?

ION does not see the TA heap (where TA does malloc() etc...).
ION sees only a small area (maybe not that small) of the secure physical memory, the SDP pool, the memory assigned to SDP protected data.

Is it means that CA only holds virtual addresses and cannot correspond to actual physical addresses, but TA can do it?

CA does not hold any virtual address for a SDP buffer. CA manipulates fd abstract scalar value, likely 0, 1, 2, 3, ...
In Linux kernel, this fd value relates to a so-called dma-buf reference.
Linux ion-unmap-heap driver can convert the reference into a physical memory address range (base address & byte size).
Linux optee driver converts the dma-buf reference into a physical reference (thanks to dma-buf+ion+unmap_heap). The physical address is then used to pass the SDP buffer reference to secure world.
In secure world, OP-TEE core maps the SDP buffer when the TA in invoked. OP-TEE core allows only SDP capable TAs is get SDP pool secure memory references as memref parameters when invoked by a non-secure world client.
On TA side, the buffer is mapped, TA can access it using a valid virtual address.

A last comment to your attention:
OP-TEE SDP was built using ION unmap heap, itself based on ION drivers. However it seems ION drivers will not longer be supported in future Linux kernels. See lvc21-120 "Moving to DMA BUF Heaps: Now is the time!". Maybe have a look at linaro-swg/linux#91.

[YogzZ]

Thank you for your answer~ I still have some question about SDP:

1. You say "Linux ion-unmap-heap driver can convert the reference into a physical memory address." Is the physical address on secure memory or unsecured memory? Can the REE end convert the physical address and use it? If not, what key elements are missing?
2. Are there any modules on OPTEE responsible for managing shared memory permissions? Or can TA be used as long as the shared memory parameter is passed from the REE side?
3. Thank you for your final reminder, it is very helpful for me to arrange the next research work. So dma-buf heap will replace ion and the shared memory module on OPTEE will use new technology to regain a new life in the future?

[etienne-lms]

Is the physical address on secure memory or unsecured memory?

The physical address (and size) points a secure address range meaningful to optee_os (thanks to macro register_sdp_mem()).

Can the REE end convert the physical address and use it?

REE knows the physical address but cannot access the memory.
REE kernel could modify the address and invoke OP-TEE with such a modified value. OP-TEE secure world, including the TA should be resilient to that.

2. Are there any modules on OPTEE responsible for managing shared memory permissions?

In secure side, core_memprot.h defines the resources used by OPTEE to identify memory.
See core/include/mm/core_memprot.h in pre-3.13.0,
or core/arch/arm/include/mm/core_memprot.h in 3.12.0 or older.
SDP memory pools are referred to by CORE_MEM_SDP_MEM.
As for the HW memory firewalls configuration, this is platform specific.

Or can TA be used as long as the shared memory parameter is passed from the REE side?

TAs without TA_FLAG_SECURE_DATA_PATH accept memref params only inside non-secure memory.
TAs with TA_FLAG_SECURE_DATA_PATH accept memref params in both non-secure and SDP memory pools.
An SDP TA will access an SDP buffer only if REE invokes the TA with the buffer passed as a memref parameter.

So dma-buf heap will replace ion and the shared memory module on OPTEE will use new technology to regain a new life in the future?

True.
The Linux driver (drivers/tee/optee/) already relies on dma-buf API for managing SHM references. It does not really care who from ION, dma-buf heap, or else created the dma-buf instance. Libteec from optee_client also should not be impacted. The library only gets a fd as argument of TEEC_RegisterSharedMemoryFileDescriptor(), whoever got this fd.

The part that will need to upgrade is the test part. Optee_test will need to upgrade as a regression test relies on ION and the unmapped heap. Linux source tree also where the OP-TEE fork has some commits to enable ION and implement unmap heaps.

[etienne-lms]

@YogzZ, I have this document that describes the extensions to GPD TEE Client API and GPD TEE Internal Core API for SDP.
It dates a bit but is still relevant: OP-TEE GP TEE Extensions for Secure Data Path.pdf.

[YogzZ]

@etienne-lms Thank you! You are so considerate!