Lock Your SoC with On-Chip Network Services for Security and Error Management

An on-chip network offers a set of services that allow chip designers and architects to optimize the design to meet the real world requirements of today’s devices, including those in IoT, medical, automotive, and defense applications.

Today’s SoCs face a series of design challenges distributed across many sub-portions of the chip. This article provides an overview of security and error management support to explain how an on-chip network (NoC) solves these distributed problems with a single IP solution.

Because it has visibility into all of the sub-portions of the design, the NoC in the SoC is in a unique position to facilitate system wide services such as:

  • Security – also called protection mechanism or firewalls
  • Error Management

The following table lists NoC features that enable chip designers to configure SoCs to suit the needs of the application.

Table 1: NoC services

Security Mechanism
An on-chip network has a broad set of security features that can be used in conjunction with error management to enable content protection, core hijacking prevention and denial-of-service protection. The protection mechanism allows for access restrictions to user-specified targets using flexible, user-defined protection regions. The initiator access can be additionally qualified with the use of in-band qualifiers.

Either the initiator ID or the network user-defined bits can be used to form the protection mechanism’s protection groups, which determine read or write permissions for the protection region.

Additionally, the user bits can be used to provide a role (such as CPU in supervisor mode) associated with the request, which determines whether the region may be accessed at all.

Access control at the target agent is based on the following attributes of each request:

  • Address: The address is used to determine the protection region. Because the initiator agent can do address fill-in and/or multi-channel operations, the address received by a target agent may not be the same as the address sent by the initiator.
  • Initiator ID: Used to determine protection groups.
  • Command: Used to determine if a read or write is requested (the ReadEx command is evaluated as both a read and a write).
  • User Signals: Separate portions of user defined signals can be used to determine the protection group and the role associated with the request.
Sonics Lock your Soc 1
Figure 1: Protection management architecture

The incoming request at the target is qualified using the address, the user bits, the initiator id and the type of command to determine whether the request is granted. The access rights are stored in a table of run-time configurable registers—these registers reside in a protected region.

The request address and protection group are used to look up read, write and role permissions from a table of protection regions.

The following two tests are then made on the selected table entry:

1. Is the incoming request type (read, or write, or both) allowed according to the read and write permissions?

ReadEx is treated as both read and write to ensure that both halves of the atomic ReadEx/Write sequence can proceed. Access checking is performed on the ReadEx transfer only. If it is successful, both the ReadEx and the subsequent write transfer are allowed to proceed. For targets that do not support ReadEx, the mapping of ReadEx commands to Reads results in mapped initiator ReadEx commands being checked as only read-type, and being issued to the target as Reads. If the closing write fails protection checking, it will not reach the target core but will release the ReadEx lock in the network.

2. Are the role bits of the incoming request within the allowed pattern established by the user defined network permission bits?

If both tests are true, the request is allowed to access the target. Permissions are only checked for the first transfer in a burst. However, if the initiator burst-chopping mechanism results in a burst being chopped into smaller bursts, the permissions for each smaller burst are individually checked on the first transfer of each burst.

An example of a CPU in multiple mode access is shown in Figure 2.

Sonics Lock your Soc 2
Figure 2: CPU access example

Although the CPU core is a single device, access to the various memory regions is controlled by the state of the software running on it. For example, a user mode access using addresses that correspond to the operating system code is rejected by the firewall because it is trying to access a region only allowed to the CPU in supervisor mode (leftmost green/red arrows). The red box indicates that the default (i.e., reset) behavior for the system is that memory accesses of any kind are only allowed by the CPU in supervisory mode until after the firewall is run-time programmed.

Error Management

An on-chip network can provide mechanisms for the detection, logging and distribution of errors as detected by the core and the internal network. The hardware captures elements of the transaction to assist in the detection of the error type and source. The system software is responsible for clean up if it requires complex sequences to recover the corrupted core.

Error-handling mechanisms can be adjusted to match the needs of the system. In a minimally configured implementation (without timeout, error-logging and error-recovery features) all error signals follow fixed routes and no error-logging or error-recovery support is available.

A fully configured implementation provides extensive error-detection and logging functions. Hardware-supported mechanisms are present that allow system error-recovery software to take individual cores off-line and restore core operating conditions without impacting the rest of the system.

Error Conditions Captured

Table 2 details the types of errors that can be detected and logged with a brief description of the usage model for the condition.

Table 2: Error Management

SoC Threat Vectors

Error management in conjunction with the protection mechanism helps address many SoC security vulnerabilities such as information extraction, core hijacking and denial-of-service attacks.

Information extraction

Information extraction is defined as obtaining key information from the chip such as cryptographic keys, passwords, private info (bank, etc.) or digital rights avoidance. The protection needs can be sub-classified into:

  • Address-based protection – access control privileges based on address and initiator as done by Sonics networks.
  • Data-based protection – finer grained access control by limiting the data values going to a location (memory or control registers) based upon the application/core being run and its authority level
  • Sequence-based protection – complex checks based upon a sequence of transactions (performed in software).

An on-chip network offers a solution for information extraction based on address protection as both protection violations and unsupported commands are managed. These errors can be reported in-band (synchronous to the transaction) to the initiator or out-of-band (asynchronous to all transaction boundaries) to a security-manager core.

Core hijacking

Core hijacking occurs when malicious source code runs on a core to alter the system behavior. Two threat vectors need to be considered:

  • Impaired core where the affected core is self-consumed by malicious code. As this attack is self-contained in the IP core, no network based protection is available.
  • System attack where the affected core impairs other system components. For example, a graphics core accessing the security engine, or an attempt to fill up queues by sending data to invalid cores or to cores that have been overly generously connected.

A correctly designed on-chip network inherently protects the system from phishing attacks to non-existent cores or wrong cores as the initiator agent prevents address hole transactions (non-existent targets) from entering the network.

Note: Some commercially available NoCs direct this traffic to an “error core” for detection and logging. This poor error recovery behavior floods the network with unproductive transactions.

Denial-of-service attacks

Denial-of-service attacks attempt to break the communications infrastructure (on-chip or off-chip) by transaction flooding to create degraded performance and increased power consumption or by creating deadlock or live-lock scenarios.

An on-chip network architecture prevents all deadlock and live-lock scenarios by maintaining transaction information in the agents and strict rules on ordering and active transactions.


Today’s SoCs are extremely complex. This complexity is further manifested when dynamic traffic conditions cause contention in the system. An on-chip network offers a set of services that allow chip designers and architects to optimize the design to meet the real world requirements of today’s devices.

SoC threat vectors can be addressed by the intelligent combination of the error management facilities and the protection mechanism. Market-leading SoCs must avail themselves of the full complement of services in the NoC to successfully compete.

Sonics Rray Brinks-Headshot resizeRaymond G Brinks is Senior Vice President of Operations after having served as Vice President of Engineering at Sonics from November 2004 to June 2013. Mr. Brinks works closely with Sales, Marketing and Engineering to streamline the activities within the organization.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: ,

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.