This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Non-Secure Software installing SG instructions into Secure Memory

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.

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?

Parents
  • Even if SAU/IDAU are setup correctly, Secure software could potentially have other bugs that can lead to vulnerabilities. For example, a stack corruption (e.g. buffer overflow) could lead to branching to a different Secure address during function return, and if that memory location is accessible from Non-secure world and is executable, then an attacker could compromise the system.

    There are of course other ways to inject data into Secure memory space (e.g. some Secure functions might need to copy Non-secure data into Secure memory for processing). While the MPU could help as you can mark those address Non-executable, but some devices might not have Secure MPU.  So it is important to have high quality in Secure software to reduce these risks.

    regards,

    Joseph

Reply
  • Even if SAU/IDAU are setup correctly, Secure software could potentially have other bugs that can lead to vulnerabilities. For example, a stack corruption (e.g. buffer overflow) could lead to branching to a different Secure address during function return, and if that memory location is accessible from Non-secure world and is executable, then an attacker could compromise the system.

    There are of course other ways to inject data into Secure memory space (e.g. some Secure functions might need to copy Non-secure data into Secure memory for processing). While the MPU could help as you can mark those address Non-executable, but some devices might not have Secure MPU.  So it is important to have high quality in Secure software to reduce these risks.

    regards,

    Joseph

Children