• State Accepted Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 349 subscribers
  • Views 15696 views
  • Users 0 members are here
Options
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

Instruction Fetches from Peripheral Memory Space

kappajacko

Is it possible to use the MPU to configure the Peripheral Memory Space as Execute?

It looks possible via the MPU_RBAR.XN bit.

If this is the case, is it fair to say that TrustZone aware select gates need to monitor HPROT[0] or PPROT[2] and block the transaction if it is an instruction fetch?

  • 0

    Peripheral Memory Space being 0x40000000-0x5FFFFFFF.

  • 0 Arm Employee Badge

    Hi

    could you possibly elaborate on what you are trying to protect from?

    is the scenario that someone configure peripheral space as executable then jumps to that code to bypass secure/non secure?

    thanks 

  • 0 in reply to Diya Soubra

    Sorry for the vagueness.

    The scenario you describe is exactly what I am concerned about.

    If the MPU can mark the Peripheral Space (0x40000000-0x5FFFFFFF) as Executable, an attacker can write an SG instruction in that space and execute it.

    I am not that knowledgeable on the MPU and want to confirm that the MPU can reconfigure the Peripheral space from Execute Never to Execute.

    If so, I believe this is a valid attack scenario. 

  • 0 Arm Employee Badge in reply to kappajacko

    Regardless of MPU settings

    the SG instruction must reside in a specific region type called 

    Non Secure Callable   NSC

    jumping to an SG instruction not in an NSC region results in a secure fault 

    only code in the secure side can configure a memory region as NSC using the SAU control registers 

    hence scenario is under control .

  • +1 Arm Employee Badge in reply to kappajacko

    You wrote:
    > I am not that knowledgeable on the MPU and want to confirm that the MPU can reconfigure
    > the Peripheral space from Execute Never to Execute.

    Yes, privileged code can reconfigure the MPU to mark the Peripheral space as Executable.  

    Note that there are two MPUs with the Security Extension (one for the Non-secure state, MPU_NS, and one for the Secure state, MPU_S).  

    An ARMv8-M processor like Cortex-M33, which includes the Security Extension, will firstly check the security attribution (Secure or Non-secure) of the address being accessed to determine which MPU to use.  For any non-secure accesses the processor will check MPU_NS, whereas for secure accesses the processor will check MPU_S.

    I believe that the scenario you've described is:

    1. Privileged non-secure code re-configures MPU_NS to mark the Peripheral space as Executable.
    2. Non-secure code attempts to write an SG opcode into the Peripheral space now marked as executable.
    3. Non-secure code attempts to jump to the address of the SG opcode.

    If secure code has already marked the Peripheral space as Secure & Non-secure Callable (NSC), the write (step 2 above) would fail because non-secure code is not permitted to access secure memory, so step 3 wouldn't even happen.

  • 0 Arm Employee Badge in reply to kappajacko

    by the way, for those interested, ARM does offer training on developing SW for TrustZone for ARMv8-M

    This course is designed for Software Engineers who already have development experience on ARMv6-M and/or ARMv7-M platforms and wish to gain experience of the TrustZone Security Extension introduced in ARMv8-M. This a public virtual training course that will help you to gain knowledge of the new feature...

    https://developer.arm.com/support/training