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?
The Secure veneer (in NSC) usually only contain SG and a branch instruction to the actual Secure API, and the checking of pointer would be carried out inside the Secure API.
We keep the Secure veneer as small as possible to reduce chance that the code could contain a SG instruction by accident (due to constant/literal data).
The other steps looks fine.
regards,
Joseph