Performing Security Handover

Note

This document is only applicable to devices AM64.

AM64 SOC is targeted towards usecases with limited runtime security operations in steady state operation. When runtime security operations are complete, it supports releasing the security resources to a host designated via board configuration. This feature is called security handover.

On AM64 device, security code uses the last 128 KB of MCUSRAM Bank 7 along with some portion of DMSC internal memory. Security code also maintains control of the security configuration region on the device from 0x45000000 to 0x45FFFFFF. After the system initialization and all runtime security operations are complete, a designated host on the system can trigger security handover operation. After the security handover is complete, the memory used by security code in MCUSRAM bank 7 is wiped and released to the system. Of all security functionality, only processor boot control functionality is left running out of DMSC IRAM. Control of system firewalls not protecting any secrets is handed over to a designated host.

This document describes the steps that need to be performed for security handover. This document must be read along side

  1. Security Handover Message Description and
  2. Security Board Configuration, specifically Security Handover

Board configuration

Security handover is controlled by board configuration Security Board Configuration, specifically Security Handover.

There are two entries that the user needs to compulsorily specify.

  1. ID of the host who will trigger the security handover.
  2. ID of the host who will take control of a portion of the system firewalls.

If the security handover functionality is not desired, both the above fields must be set to 0. 0 corresponds to the DMSC host ID. Both these host ID’s are validated during security board configuration processing. Please ensure that these fields are initialized correctly.

../_images/sec_handover_boardcfg.svg

Normal runtime operation

During normal runtime operation, System Firmware processes all runtime security messages as described in the TISCI documentation. Once all the runtime security operations are complete, the host described in board configuration can trigger security handover.

Triggering security handover

../_images/sec_handover_during.svg

Security handover is triggered by TISCI_MSG_SEC_HANDOVER. This TISCI message can only sent by the host specified in the board configuration. The TISCI message request and response take no additional arguments as the required information is included in the board configuration.

The above diagram shows the sequence of operation in M3 when the security handover TISCI message is received. In the diagram, we are assuming that R5 has been specified as the sender of the handover message.

In the last step in the diagram labelled as “Open firewall protecting the firewall configuration”, the firewall is programmed to only allow the host specified in the security board configuration handover_to_host_id.

Post Security handover

../_images/sec_handover_after.svg

As most of the security functionality is removed to free up memory, processor control functionality is the only security feature available after handover. In processor control, secure boot API is not available. Any security TISCI messages other than processor control functionality are NACKED.

Below is the list of supported processor control API.

TISCI Message ID Message Name
0xC000 TISCI_MSG_PROC_REQUEST.
0xC001 TISCI_MSG_PROC_RELEASE.
0xC005 TISCI_MSG_PROC_HANDOVER.
0xC100 TISCI_MSG_PROC_SET_CONFIG
0xC101 TISCI_MSG_PROC_SET_CONTROL
0xC400 TISCI_MSG_PROC_GET_STATUS
0xC401 TISCI_MSG_PROC_WAIT_STATUS

The below processor control feature is not supported.

TISCI Message ID Message Name
0xC120 TISCI_MSG_PROC_AUTH_BOOT

System Firmware continues to process and clear firewall exceptions to avoid distributing this functionality among multiple cores.

On HS devices, System Firmware firewalls the SA2UL for use during secure boot. This firewall is not opened by System Firmware during security handover. However the host specified in the security board configuration can open the SA2UL firewalls as required.

Any resource management ring configuration API are also unavailable after security handover as they internally invoke ISC configuration API.

Warning

Any resource management ring configuration API are also unavailable after security handover as they internally invoke ISC configuration API.