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?
Hi Joseph,
To summarize, the strict requirement that Secure Transactions only read secure memory/peripherals is in place to protect against low quality software.
It's up to the Hardware implementer to enforce this at the bus level.
If the implementer does not enforce this, then the burden is put on the SW team to ensure extreme high quality code.