In the example system design shown previously, a block-based gate is used to protect and allocate regions of memory which are subdivided into blocks. A control is implemented for each block which identifies whether the block is treated as Secure or Non-secure. At reset, or unless configured using alternative means, all blocks revert to Secure access only, and rely on Secure software to assign blocks as Non-secure. The control also determines in which alias a particular block appears.
The gate has two hard requirements:
- It must not-permit Non-secure transactions to read/write blocks that the controls mark as Secure.
- 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.
In addition to the two hard requirements, it is also permissible to not permit Secure writes to Non-secure blocks.
Within the example system, the rejection method that is used for non-permitted transactions is to ignore writes and to return zero on reads, along with providing event information to the system security controller, which in turn would generate an interrupt to the ARM®v8‑M processor. Alternative mechanisms, such as generating bus aborts, are also feasible though potentially less desirable, in particular if an alternative rejected read default value is chosen it must never be the SG instruction.
Although this mechanism is suitable for protecting the read interface of a flash controller, extra care must be taken with the programming interface.