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 or PPROT and block the transaction if it is an instruction fetch?
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?
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.
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 .
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.
View all questions in TrustZone for Armv8-M forum