Accessing Normal World Memory Space from TA

[matzedav]

Hey,

I am trying to access the memory address space of the normal world from the trusted application. I found similar issues but I think I miss something.

This is my code for mapping the virtual addresses into physical addresses:
register_phys_mem(MEM_AREA_RAM_NSEC, 0x10d8d, 0x01);

I access the struct from TA with:
_phys_mem_0x10d8d.addr

I get the address but I cant access to the value. This is the error if I try to:
DMSG("[TA] ADDRESS VALUE: %i\n", *(uint32_t *)__phys_mem_0x10d8d.addr);

DEBUG: [0x0] TEE-CORE:abort_handler:555: [abort] abort in User mode (TA will panic)
ERROR: TEE-CORE:
ERROR: TEE-CORE: user TA data-abort at address 0x10d8d (translation fault)

So my question is: Am I missing something to access the value of this address?
Your help is much appreciated. Thank you!

[jenswi-linaro]

register_phys_mem() isn't available for TAs.

[matzedav]

Is there a possibilty to access normal world address space from TA during runtime?

[jenswi-linaro]

Only what's supplied as memory parameters.

[prime-zeng]

@jenswi-linaro I have the same problem, what about considering it in the mainline?

• The typical usecase is :
  For example, we use the dma-buf in the normal world, and passed the sglist(non-contiguous physic pages ) which represents the dma-buf from normal world to TA, then the TA need to map the sglist to it's virtual address and then access.

• My thoughts about the problem:
  We have now the core_mmu_map_pages to do this now, but this function can only handle the kernel space mapping, and we have implemented a core_mmu_map_user_pages which is almost the same as the core_mmu_map_pages. But this still some questions to be discussed:
  1)what is the life cycle of the dynamic mapping? Is it the same as memory parameters or the same as the TA code?
  2)How the virtual memory space is managed (TA Code/data/stack, Memory parameters, Dynamic TA mappings)?

[jenswi-linaro]

@prime-zeng
We have #1631 (see at the end of the comments for PRs in other gits) which supports non-contiguous physical memory. This enables mapping more less any user space memory in a memory parameter. Is that enough to solve your problem?

[prime-zeng]

@jenswi-linaro I know this patch, it can solve some problems, but it's limited to memory parameters, and the mapping is passive from the TA view of point, the life cycle for this type of mapping is limited to this invoke_cmd call. Sometimes active mapping is needed for a TA, I mean the TA owns the memory handle physic address of the memory(or sglist of the non-contiguous physic memory) , and do the mapping through a syscall.

[jenswi-linaro]

To help me better understand what's needed, can you provide an example use case? I'd like to understand when a memory parameter isn't sufficient.

[matzedav]

My use case is, that I have a host program (NW) that sends two addresses, like a start address of a function and the end (return) address of the function. The TA should read the two values (this actually works fine!) and all values of the addresses in between this start end address.

[jenswi-linaro]

@xNado Why can't this be done with a memory reference in a parameter to the TA?

[matzedav]

I tried to do this with a memory reference. I actually get zeros in between. The value of the first address is the same as the value of the normal world. My Output is:

DEBUG: USER-TA:check_memory_region:298: [TA] 11573173
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0
DEBUG: USER-TA:check_memory_region:298: [TA] 0

... and so on

My main.c code:

op.params[0].tmpref.buffer = &memory_region_check;
op.params[0].tmpref.size = sizeof(&memory_region_check);

My TA code:

for (int i = 0; i <= params[2].value.a; i++)
	{
		DMSG("[TA] %i\n", *((uint32_t *)params[0].memref.buffer+i));
	}

[jenswi-linaro]

Looks like expected result. sizeof(&memory_region_check) is 4, right?

[matzedav]

Yes, the sizeof(&memory_region_check) is 4.

[matzedav]

Thank you for your help @jenswi-linaro!
You gave me an idea to realize this with shared memory.

[LisShen]

Hi,
I read this issue and discussion, and I got some similar questions.
when I used TEE OS v2.1, I use register_phys_mem() to register a normal memory space.
And I write a system call for TA to translate a physical address from CA.
I use tee_mmu_user_pa2va_helper() to translate the physical address to virtual address for TA.

But when I upgrade to TEE OS v2.5, I found that does not work anymore.
tee_mmu_user_pa2va_helper() will not search what register_phys_mem() registered region.
Is that changes is correct?

My use case is that I got about 200M byte encrypt data , and I need TEE OS to do decryption to the secure memory. I can not do any memory copy. what should I do?
Thanks.

[etienne-lms]

tee_mmu_user_pa2va_helper() looks into the user space TA mapping info for a matching pa. register_phys_mem() is used to map in the TEE core, not in the user TA space.

[LisShen]

Hi @etienne-lms
Thank you for answer.
I found some solutions to achieve my goal.
Now I don't have any question.

[saeedm92]

@LisShen Could you please tell us how you added a mapping of NW memory for userspace TA? Thanks,