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

TZC-400 Region Secure Access Discussion

Hi experts,

I know for the TZC-400 each region has an attribute register which has two bits:  s_wr_en  and s_wr_en for controlling secure access. On the other hand, these control registers could be changed by secure access.

In this case, it looks like even one secure application / OS operation is blocked by these two bits, application / OS could also modify the bits for their requirement so I don't understand why does the TZC-400 need these two bits.

Any discussion is welcomed.

Thank you.

Simon

Parents
  • Hi Simon,

    The idea here is to prevent the Secure world from making Secure accesses to memory that it shouldn't, for example via a dangling pointer, stack overflow, buffer overrun, etc, which can help to reduce the potential attack surface of a system.

    You can see this in the ARM Trusted Firmware code. Note how region 1 is marked as TZC_REGION_S_RDWR but no NSAIDs are specified, while regions 2 & 3 are marked as TZC_REGION_S_NONE but do specify a number of NSAIDs (PLAT_ARM_TZC_NS_DEV_ACCESS). In other words, ARM Trusted Firmware deliberately prevents Secure accesses to any region that is accessible to the Normal.

    The Secure world can still make Non-secure accesses to those regions (via the NS bit in the processor's translation table descriptors), so it's still possible to share data between the worlds, but because the Secure world will have had to deliberately map those regions as Non-secure it knows not to trust any of the data it sees there, will perform additional verification of pointers, etc.

    You're right that the Trusted OS could reprogram these bits, but we'd expect the Trusted OS and EL3 firmware to be co-operating seeing as their both running in the Secure world and thus should be trusted

    Hope that helps,

    Ash.

Reply
  • Hi Simon,

    The idea here is to prevent the Secure world from making Secure accesses to memory that it shouldn't, for example via a dangling pointer, stack overflow, buffer overrun, etc, which can help to reduce the potential attack surface of a system.

    You can see this in the ARM Trusted Firmware code. Note how region 1 is marked as TZC_REGION_S_RDWR but no NSAIDs are specified, while regions 2 & 3 are marked as TZC_REGION_S_NONE but do specify a number of NSAIDs (PLAT_ARM_TZC_NS_DEV_ACCESS). In other words, ARM Trusted Firmware deliberately prevents Secure accesses to any region that is accessible to the Normal.

    The Secure world can still make Non-secure accesses to those regions (via the NS bit in the processor's translation table descriptors), so it's still possible to share data between the worlds, but because the Secure world will have had to deliberately map those regions as Non-secure it knows not to trust any of the data it sees there, will perform additional verification of pointers, etc.

    You're right that the Trusted OS could reprogram these bits, but we'd expect the Trusted OS and EL3 firmware to be co-operating seeing as their both running in the Secure world and thus should be trusted

    Hope that helps,

    Ash.

Children
No data