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
  • 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.

    --------------------

Reply
  • 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.

    --------------------

Children
No data