Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
Control MMU for TrustZone
Jump...
Cancel
Locked
Locked
Replies
9 replies
Subscribers
119 subscribers
Views
8266 views
Users
0 members are here
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
Control MMU for TrustZone
thiet pv
over 12 years ago
Note: This was originally posted on 20th July 2011 at
http://forums.arm.com
Dear all,
I am a new bie about TrustZone. I arm learning the effect of TrustZone to MMU. I have some problems about the mechanism to manage secure/non-secure region by MMU.
Please help me to understand about them.
My dubious point described as below:
When translation virtual address to physical address, system will use TLB table. I know that, when have a miss occur on TLB, it will find physical page from page table.
From table index of virtual address and table base address, will have first-level descriptor, the first-level descriptor will be input for page table to get physical page table from page table
then fill it to TLB table.
If page table miss, it will find physical page form external memory (RAM) and fill it to page table with it's attribute.
So when cpu stay in secure world, and access to secure physical memory
How to know the address that cpu access include secure physical memory region or no-secure physical memory region?
How to partition the physical memory into secure and non-secure regions?
and if know secure attribute of secure region then
How to fill secure attribute to page table?
Please help me.
Thank you very much,
Parents
Martin Weidmann
over 12 years ago
Note: This was originally posted on 22nd July 2011 at
http://forums.arm.com
" think when the secure world makes a table walk that walk can be secure or non-secure, it depends on the physical page on page table mapped secure or non-secure."
When in the secure world, the walk of the l1 table will _always_ be done using secure accesses. Why? Well, because the processor only has a pointer to the L1 tables (TTBR0/1). It is the tables which define whether secure or non-secure accesses will be used for a particular address range. Therefore until it reads the table it has no way of knowing whether to use secure or non-secure accesses. So, while in the Secure world, the processor will always use secure accesses for the table walk.
Does this matter?
Well, first why would you want the page tables for the Secure world in memory accessible by the Normal world? This seems like a bit of flaw in your software!
Also, the processor does not know whether the target address accepts secure or non-secure (or both!) accesses. The target memory doesn't support the generated access type it will return an error, and the processor will take an abort. There is no auto-sensing system for the processor to discover the kind of access to use.
Cancel
Vote up
0
Vote down
Cancel
Reply
Martin Weidmann
over 12 years ago
Note: This was originally posted on 22nd July 2011 at
http://forums.arm.com
" think when the secure world makes a table walk that walk can be secure or non-secure, it depends on the physical page on page table mapped secure or non-secure."
When in the secure world, the walk of the l1 table will _always_ be done using secure accesses. Why? Well, because the processor only has a pointer to the L1 tables (TTBR0/1). It is the tables which define whether secure or non-secure accesses will be used for a particular address range. Therefore until it reads the table it has no way of knowing whether to use secure or non-secure accesses. So, while in the Secure world, the processor will always use secure accesses for the table walk.
Does this matter?
Well, first why would you want the page tables for the Secure world in memory accessible by the Normal world? This seems like a bit of flaw in your software!
Also, the processor does not know whether the target address accepts secure or non-secure (or both!) accesses. The target memory doesn't support the generated access type it will return an error, and the processor will take an abort. There is no auto-sensing system for the processor to discover the kind of access to use.
Cancel
Vote up
0
Vote down
Cancel
Children
No data