In "System Design with ARMv8M, Section 1.6 Block-based Gate", a Block-based gate is described.
The document describes 2 hard requirements for a Block-base Gate followed by an explanation for the 2nd requirement.
The gate has two hard requirements: 1. It must not-permit Non-secure transactions to read/write blocks that the controls mark as Secure. 2. It must not-permit Secure transactions to read blocks that the controls mark as Non-secure. In addition to other less obvious attack vectors, requirement 2 is designed to prevent Non-secure software using the aliasing to install code, including SG instructions into Secure memory and then calling into it.
The gate has two hard requirements:
1. It must not-permit Non-secure transactions to read/write blocks that the controls mark as Secure.
2. It must not-permit Secure transactions to read blocks that the controls mark as Non-secure.
In addition to other less obvious attack vectors, requirement 2 is designed to prevent Non-secure
software using the aliasing to install code, including SG instructions into Secure memory and then
calling into it.
How is the scenario regarding the need for the 2nd requirement possible if the SAU/IDAU sections are programmed correctly?
Is this more of a precaution against incorrect SAU/IDAU programming?
One comment on Joseph's reply:
In fact, it's not allowed to put any literal data into NSC if you are rigorous about system security.
Even secure veneers are using MOVW and MOVT to encode target branch address into OPCODE, so the NSC could be put into eXecute-Only memory (Instruction Fetch Only memory). This implies that attackers cannot get the actual addresses of target functions of secure API.
--------------------
One famous attack scheme is trying to find a way to
a. Disable SAU
b. Mark entire 4G address space as Secure
so the original non-secure code will be able to access secure resources freely.
By taking this into consideration, putting NSC into physically eXecute-Only memory has significant security meaning.