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

Non Secure malicious access handling...

Hello,

I'm new in the forum. I'm starting to work on Cortex-M project using trustzone (IDAU/SAU/MPU). 

I have a look to a lot of webinars and documents and I have a question regarding Non-Secure code access. In my configuration, I could set IDAU/SAU/MPU, internal ram of chip is banked to be accessed either by Non Secure state or Secure state and could be executable. In terms of mapping it could be for instance that NS access to internal RAM is 0x01XXXXXX and NSC/S access to internal RAM is 0x02XXXXXX through IDAU/SAU.

At this step, how we could avoid a malicious attack from NS region. I mean I have loaded secure code and data at address 0x02000110. This address access in NS region is 0x01000110. So what happens if NS try to read data at this address 0x01000110. It should access to Secure code / data ? I guess I miss something and would like to get some clarity on it.

Thanks,

Best Regards.

Parents
  • Hi TexCor JC,

    As I understand from your explanation, at a system level memory map, you are expecting that a physical RAM should be either configured as Secure or Non-secure attribute. 

    In Armv8-M based systems, it is highly recommended that duplication of memory mapped components in both Secure and Non-secure regions is strictly avoided. To elaborate, the intention is not to make a physical memory location accessible simultaneously at two separate addresses. Instead it will only be accessible in either a secure or a non-secure region at any point in time. At a system level, it is recommended to have gate components to completely remove this duplication so that each physical memory location is only visible in either a secure region or a non-secure region. 

    The gate component should act like a system security controller. The system security controller is a peripheral component that is accessible only by Secure transactions. The system security controller holds all of the register fields used to modify the configurable aspects of the system security, for example: boundary between Secure and Non-secure memory in RAM.

    Hence in your system, you will need to introduce a system security controller that acts as a gate component that filters the Secure vs Non-secure transactions to make sure that each memory address is dedicated only for either Secure or Non-secure at a give point of time.

    Thanks,

    Uma

     

     

     

Reply
  • Hi TexCor JC,

    As I understand from your explanation, at a system level memory map, you are expecting that a physical RAM should be either configured as Secure or Non-secure attribute. 

    In Armv8-M based systems, it is highly recommended that duplication of memory mapped components in both Secure and Non-secure regions is strictly avoided. To elaborate, the intention is not to make a physical memory location accessible simultaneously at two separate addresses. Instead it will only be accessible in either a secure or a non-secure region at any point in time. At a system level, it is recommended to have gate components to completely remove this duplication so that each physical memory location is only visible in either a secure region or a non-secure region. 

    The gate component should act like a system security controller. The system security controller is a peripheral component that is accessible only by Secure transactions. The system security controller holds all of the register fields used to modify the configurable aspects of the system security, for example: boundary between Secure and Non-secure memory in RAM.

    Hence in your system, you will need to introduce a system security controller that acts as a gate component that filters the Secure vs Non-secure transactions to make sure that each memory address is dedicated only for either Secure or Non-secure at a give point of time.

    Thanks,

    Uma

     

     

     

Children