Support Direct Physical Memory Mapping to TA Address Space

[yemiaobing]

Background

In secure media processing scenarios, we have hardware-protected memory regions (enforced by hardware firewall) that need to be accessed by Trusted Applications (TAs). The typical use case is:

1. Hardware demux writes audio/video data directly to a secure memory buffer
2. REE (Normal World) CPU cannot access this memory due to hardware firewall protection
3. REE only knows the physical address and passes it to the TA
4. TA needs to access this memory for decoding/processing

Current Limitations

Currently, OP-TEE's mobj mechanism has strict restrictions on memory types:

1. mobj_phys_alloc() only supports 4 predefined memory types:

enum buf_is_attr {
    CORE_MEM_TEE_RAM,
    CORE_MEM_TA_RAM,
    CORE_MEM_NSEC_SHM,
    CORE_MEM_SDP_MEM,
};

For arbitrary hardware-protected physical memory regions (e.g., secure audio/video buffers allocated by hardware), none of these types apply.

2. mobj_reg_shm_alloc() only accepts non-secure memory:

/* Only Non-secure memory can be mapped there */
if (!core_pbuf_is(CORE_MEM_NON_SEC, mobj_reg_shm->pages[i],
                  SMALL_PAGE_SIZE))
    goto err;

This prevents mapping secure physical memory regions.

3. Cannot use shared memory approach:

• REE cannot access the memory (hardware firewall)
• Even if mapped as non-cacheable, REE's CPU cache might leak sensitive data
• Violates the security model

Current Workaround

We currently work around this by implementing a PTA-based proxy:

// PTA maps physical memory in kernel space
static TEE_Result xdev_map_phys_region(uint32_t instance_id, ...) {
    kva = (vaddr_t)core_mmu_add_mapping(MEM_AREA_RAM_SEC, pa, len);
    // Store kva, TA accesses via PTA read/write calls
}

// TA calls PTA for each read/write operation
utee_xdev_read_phys_region(handle, offset, buf, len);
utee_xdev_write_phys_region(handle, offset, buf, len);

Drawbacks:

• Every memory access requires a trap to secure world (performance overhead)
• Cannot directly access memory from TA
• More complex code structure

Proposed Solution

Add support for mapping arbitrary physical memory regions directly to TA address space, with proper security controls.

Option 1: Extend mobj_phys_alloc() with a new memory type

enum buf_is_attr {
    CORE_MEM_TEE_RAM,
    CORE_MEM_TA_RAM,
    CORE_MEM_NSEC_SHM,
    CORE_MEM_SDP_MEM,
    CORE_MEM_SECURE_DEVICE,  // New: for hardware-protected regions
};

Option 2: Add a new API for arbitrary physical memory mapping

/**
 * mobj_phys_alloc_unchecked() - Create mobj for arbitrary physical memory
 * @pa:         Physical address
 * @size:       Size in bytes
 * @mem_type:   Memory type attributes (cache, etc.)
 * 
 * This function creates an mobj for arbitrary physical memory without
 * security checks. Caller (PTA) is responsible for ensuring the physical
 * address is valid and accessible in secure world.
 */
struct mobj *mobj_phys_alloc_unchecked(paddr_t pa, size_t size, 
                                       uint32_t mem_type);

Option 3: Add PTA helper for mapping to TA address space

/**
 * pta_map_phys_to_ta() - Map physical memory to calling TA's address space
 * @pa:         Physical address
 * @size:       Size in bytes
 * @prot:       Protection flags (TEE_MATTR_UR, TEE_MATTR_UW)
 * @flags:      Mapping flags (cached/non-cached)
 * @va:         [out] Virtual address in TA's address space
 * 
 * Returns TEE_SUCCESS or error code
 */
TEE_Result pta_map_phys_to_ta(paddr_t pa, size_t size, uint32_t prot,
                               uint32_t flags, vaddr_t *va);

Use Case Example

// In TA:
TEE_Result decode_audio(uint64_t secure_audio_pa, uint32_t size) {
    void *audio_buffer;
    
    // Map physical memory directly to TA address space
    TEE_Result res = map_secure_phys_region(secure_audio_pa, size,
                                             TEE_MATTR_UR,
                                             &audio_buffer);
    if (res != TEE_SUCCESS)
        return res;
    
    // Direct access - no PTA calls needed
    uint8_t *data = (uint8_t *)audio_buffer;
    parse_audio_frame(data, size);
    decode_audio_frame(data, size);
    
    unmap_secure_phys_region(audio_buffer);
    return TEE_SUCCESS;
}

Security Considerations

1. Access Control: Only PTAs should be able to create such mappings, not TAs directly
2. Validation: PTA should validate that the physical address is within allowed ranges
3. Isolation: Each TA session should only access its own mapped regions
4. Cleanup: Automatic cleanup when TA session closes

Benefits

1. Performance: Zero-copy, direct memory access from TA
2. Simplicity: Cleaner code, no PTA proxy needed for every access
3. Flexibility: Supports various hardware-protected memory scenarios (DRM, secure camera, etc.)
4. Standard: Aligns with how other TEE implementations handle secure memory

Questions

1. Is there a security reason why arbitrary physical memory mapping is not supported?
2. Would any of the proposed solutions be acceptable?
3. Are there alternative approaches we should consider?

Environment

• OP-TEE Version: 4.1.0
• Platform: ARM64
• Use Case: Secure audio/video processing with hardware firewall protection

Thank you for considering this feature request!

[jenswikl]

Please check a more recent version of OP-TEE. I believe that #7516 addresses some of your concerns.
Which platform do you consider for this? Do you represent a vendor? Anything else that would be good to know to understand better your point of view or where you come from?

[yemiaobing]

Thanks for pointing to #7516, we've reviewed it carefully.

Our setup:

• Platform: ARM64, production use case
• The secure memory buffer is written by hardware (DSP/demux), and neither the input nor the decoded output can be exposed to REE
• DSP performance is insufficient for decoding, so we must use the TEE CPU
• Decoding must be done inside a TA (not in optee_os kernel), as the decoding logic and keys are TA-managed

#7516 gets us most of the way there, but there's one blocker: mobj_protmem_inc_map() in mobj_dyn_shm.c unconditionally returns TEE_ERROR_BAD_PARAMETERS, which prevents the TA from mapping the lent memory into its virtual address space for CPU access.

We understand this was intentional for hardware-access-only use cases (e.g. passing PA to a hardware decoder). However, for software decoding in a TA, the CPU must be able to read the bufferdirectly.

Would it be possible to allow mapping for certain use_case values? For example, a new MOBJ_USE_CASE_SEC_AUDIO_DECODE (or a flag on the existing use cases) where inc_map delegates to the same
logic as mobj_reg_shm_inc_map instead of returning an error.

[jenswikl]

Thanks for pointing to #7516, we've reviewed it carefully.

Our setup:

• Platform: ARM64, production use case

Yeah, that was pretty obvious. So I guess we're dealing with a no-name platform.

• The secure memory buffer is written by hardware (DSP/demux), and neither the input nor the decoded output can be exposed to REE
• DSP performance is insufficient for decoding, so we must use the TEE CPU
• Decoding must be done inside a TA (not in optee_os kernel), as the decoding logic and keys are TA-managed

#7516 gets us most of the way there, but there's one blocker: mobj_protmem_inc_map() in mobj_dyn_shm.c unconditionally returns TEE_ERROR_BAD_PARAMETERS, which prevents the TA from mapping the lent memory into its virtual address space for CPU access.

That only prevents S-EL1 to map it as an argument struct and such. It can still be mapped for TAs with the TA_FLAG_SECURE_DATA_PATH flag set.

We understand this was intentional for hardware-access-only use cases (e.g. passing PA to a hardware decoder). However, for software decoding in a TA, the CPU must be able to read the bufferdirectly.

Would it be possible to allow mapping for certain use_case values? For example, a new MOBJ_USE_CASE_SEC_AUDIO_DECODE (or a flag on the existing use cases) where inc_map delegates to the same logic as mobj_reg_shm_inc_map instead of returning an error.

This is already more or less supported. A secure audio decode use case sounds interesting.

[yemiaobing]

Thanks for the clarification! We'll upgrade to OP-TEE 4.10.0 or backport the patch to resolve our issue.

Just a small question about the use_case enum: I noticed it uses specific names like MOBJ_USE_CASE_SEC_VIDEO_PLAY and MOBJ_USE_CASE_TRUSED_UI. I'm curious about the design rationale here - could there be other use cases beyond video and UI (like audio, image processing, etc.) that might need this feature?

From what I can see in the code, the use_case is mainly passed to platform-specific hooks. Would more generic names like MOBJ_USE_CASE_PROTECTED_BUFFER be more flexible for different scenarios, or is there a specific reason for the current naming?

(Also spotted a small typo: TRUSED_UI → TRUSTED_UI)

[yemiaobing]

One security concern: currently any TA with TA_FLAG_SECURE_DATA_PATH can access all lent protected memory, regardless of which TA it was intended for. Is there a mechanism to bind lent memory to a specific TA UUID or session? Otherwise, a malicious (but signed) SDP TA could read sensitive data from other use cases.

[jenswikl]

The enum mobj_use_case should be extended with use cases as needed. One purpose of enum mobj_use_case is for the platform-specific code to know how the memory firewall, etc, should be configured.
We don't expect vendors to sign malicious TAs. But if it's important to limit SDP-TAs to specific use cases, I guess that can be added. However, I'd prefer to add it because there's a real need.

Do you want to make a PR to fix the typo?

[yemiaobing]

I'd be happy to submit a PR for the typo fix!

Regarding the security concern, I'd like to share our use case to provide more context.

We are a chip vendor. The OP-TEE OS is signed, encrypted, and distributed by us. OP-TEE runs multiple TAs simultaneously:

• Some TAs are developed and signed by us (the chip vendor)
• Some TAs are developed and signed by third-party companies
• Each TA uses a different OTP Root RSA Key

So TAs from different vendors are essentially mutually untrusting.

In this setup, if our audio decoding TA lends protected memory and processes sensitive data, a third-party TA that also has TA_FLAG_SECURE_DATA_PATH could potentially access that same memory. Third-party vendors typically have strict requirements around memory isolation between TAs from different vendors.

In this context, binding lent memory to a specific TA UUID seems like a natural way to enforce isolation - since the UUID, combined with the trust chain, is what distinguishes one vendor's TA from another's. Such a mechanism could be fully backward-compatible, only enforced when explicitly requested during LEND_PROTMEM.

Just sharing this as a real-world scenario that might be worth considering.

[jenswikl]

Thanks for the background information. It's very helpful.
Do you use subkeys to separate the vendors?
How would you bind a certain TA UUID to a protected memory use-case?

[yemiaobing]

Our use case assumes that the REE side is not trusted.

In our products, the REE kernel/driver is integrated by OEMs. Even if we do not ship the source code, the OEM can still modify the REE binary or kernel module. Because of that, we do not want the REE side to decide which TA a protected memory object is bound to.

Our approach is therefore:

• plat_set_protmem_range() is only used for platform-specific memory protection changes
• the TA binding is decided inside secure world, based on a secure policy
• when protected memory is lent/assigned, OP-TEE determines the allowed TA UUID from that policy
• later, when the memory is about to be mapped as a TA parameter, OP-TEE checks that the target TA UUID matches the stored owner UUID, and rejects the mapping otherwise

So from our perspective, the REE may request a protected-memory use case, but it must not be able to decide the final TA binding by itself.

This is mainly to prevent an OEM-modified REE from lending the same protected memory to a different SDP-capable TA than the one intended by the secure-world policy.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

[jenswikl]

That makes sense. How do you manage the TA UUIDs? Are they hardcoded in the source code?