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

trustzone translation table

Note: This was originally posted on 15th November 2011 at http://forums.arm.com

After reading the documents in the website, i am quite puzzled about the trustzone feature.
1. Can i disable trustzone extension?
2. Each world has its own virtual processor, virtual mmu and translation table. How to make sure that the normal world can't access the secure world memory? The normal world can't see the physical address of the secure world? Or it can translate the virtual address to the physical address of the secure world, but it can't access that region of memory?
3. Normal world ignores the NS bit in the translation table. So it can access all the physical memory in normal world?
I have read the book: ARM Security Technology: Building a Secure System Using TrustZone Technology, ARM Architecure Reference Manual and ARM Cortex-A programming guide. Did i miss the important part? Can anyone advise me some books regarding the arm cortex-a architecture? I am a beginner at ARM. Thanks.
  • Note: This was originally posted on 15th November 2011 at http://forums.arm.com

    Thanks for your answer, ttfn.
    I am still puzzled at the translation table.
    1. Does the two world have different translation tables?
    2. Can the normal world translate the virtual address to the physical address, while this physical address is secure according to the translation table in the secure world? If so, the normal world can modify that region of memory.
    3. In the manual ARM Architecture Reference Manual ARMv7-A and ARMv7-R Edition, there is one section B3.5 Secure and Non-secure address spaces, i am confused by the following words.


    The Non-secure translation table entries can only translate a virtual address to a physical address in the Non-secure physical address space. Secure translation table entries can translate a virtual address to a physical addresses in either the Secure or the Non-secure address space. Selection of which physical address space to use is managed by the NS field in the first-level descriptors, see First-level descriptors on page B3-8:

    while constructing the translation table, there is no first-level descriptors, how come it can divides the physical memory according to the  NS bit in the first-level?

    Thanks.
  • Note: This was originally posted on 15th November 2011 at http://forums.arm.com

    [color=#222222][size=2]Thanks for your answer, ttfn.[/size][/color]
    [size=2]1. for the second answer, how does the system know it's a secure access. because you mention that all accesses are non-secure in the normal world, though the physical memory is marked as secure in the secure world.[/size]
    [size=2]2. for the third, i mean how to initialize the translation table. If you want initialize the translation table, you should divide the physical space into secure and non-secure. and if you want divide the physical address, you should refer to the NS bit in the translation table. I am confused about this initialization.[/size]
    [size=2]
    [/size]
    [size=2]Thanks.[/size]
  • Note: This was originally posted on 16th November 2011 at http://forums.arm.com

    Thanks, ttfn.
    I have one more question.

    since the normal world can only see the non-secure physical address space, so the normal can address 4G space. the secure world can see the secure and non-secure physical address space, so it can address 8G space. is that right?
    for example, you want to access a virtual address in the secure world and that virtual address is marked as secure in the translation table in the secure world. my question is: how to access the same virtual address which is marked as non-secure in the secure world?

    By the way, i can't find any resources about what you have said about trustzone. Could you provide me some materials?

    Thanks
  • Note: This was originally posted on 15th November 2011 at http://forums.arm.com

    1) Not exactly.  The Security Extensions will either be present in a processor - or they won;t be.  In the case of the Cortex-A processors, they all have it.  That said, you don't have to use it.  If your not interested in TrustZone, after a couple of steps you can switch into the Normal world and ignore the Secure world from then on.

    3) TrustZone provides the concept of secure memory and non-secure memory.  In the Secure world the NS bit in the translation tables define whether to access secure or non-secure memory.  In the Normal world the NS bit is ignored BECAUSE ALL ACCESSES WILL BE NON-SECURE.

    2) It kind of depends on what you mean by secure memory.  The processor will generate a "secure" or "non-secure" access on the bus.  If your interested, its the AxPROT signal that reflects the access type.  Its up to the memory system what to do with this information.  Typically the memory system would just abort a non-secure access to secure memory.
  • Note: This was originally posted on 15th November 2011 at http://forums.arm.com

    1) Yes.  The two worlds each have their own copies of the TTBR{n} registers.  When you're in the Secure world, you see/use the secure copy.  When in the Normal world, you see/use the non-secure copy.

    2) The Normal world can NEVER generate a secure access.  What this means in practise is any bus access (or cache look up) will be marked as non-secure.  It is up to the memory system to use that information to prevent non-secure accesses to secure memory.

    3) I am not sure what you mean by "constructing the translation table" :-(
  • Note: This was originally posted on 16th November 2011 at http://forums.arm.com

    1) secure physical address 0x8000 is considered to be a different location to non-secure physical address 0x8000.

    What the NS bit in the Secure world's page tables is doing is selecting which of the two different addresses the virtual address maps to.  In the Normal world you have no choice, it always maps to the non-secure address space.

    The processor tells the memory system is via a signal on the bus.  When it specifies the address of a read/write it also specifies secure/non-secure.  The memory system _could_ use this to direct the access to somewhere else, it _could_ use it as a form of access control, or it _could_ just ignore it.  it depends on what the system designers decided.  If you want to use TrustZone you hope they didn't ignore it and did seomthing useful! :-)

    2) Ah ok... I think you have this the wrong way round

    It is the system designer who decides which memories/peripherals are secure or non-secure (or in some cases configurable).  This information would be specified in the data sheet that came with a specific part.  When you set up the page tables you are describing the memory system to the processor. That is this memory IS secure so the processor MUST generate secure accesses.
  • Note: This was originally posted on 17th November 2011 at http://forums.arm.com


    since the normal world can only see the non-secure physical address  space, so the normal can address 4G space. the secure world can see the  secure and non-secure physical address space, so it can address 8G  space. is that right?


    Basically - yes.  Although you are assuming that both physical address spaces are fully populated.  In most systems this is not the case.


    for example, you want to access a virtual address in the secure world  and that virtual address is marked as secure in the translation table in  the secure world. my question is: how to access the same virtual  address which is marked as non-secure in the secure world?

    Each world has it own virtual space - which are entirely independent of each other.  Just taking the Secure world, the translation tables tell the processor which physical address a given virtual address translates to.  With the NS bit in the table entry defining whether it is a secure or non-secure physical address. 

    So the secure-ness is not known until the address is translated.  The processor (the bit that does the work) deals with the virtual address space - not the physical address space.  So it does not know - or care - what kind of address (secure/non-secure) the virtual address will eventually translate to.