Typical architecture design scheme for autonomous driving based on NVIDIA chips

The Cortex-R5F processor, also known as the Cryptographic Hardware Security Module (CHSM), is used to run cryptographic and security use cases such as Secure In-Car Communications (SecOC) over the CAN interface.

The entire FSI mechanism generally includes the following security instructions and control interface information:

1. Security and CHSM CPU Tightly coupled memory, instruction, and data caches for each core.

2. There is a total of 5MB of on-chip dedicated RAM in the safety island to ensure that code execution and data storage can remain within the FSI.

3. The island has a dedicated I/O interface for communicating with external components, including 1 UART and 4 GPIO ports.

4. Hardware security mechanisms, such as DLS, CRC, ECC, parity check, timeout, etc. for all IPs within FSI.

Dedicated thermal, voltage and frequency monitors.

5. Logical isolation, ensuring sufficient error recovery time FFI with other parts of the SoC.

FSI example analysis 1:

Here, this article will use an example to illustrate the design of FSI and describe the corresponding error handling mechanism, including the processing mode of the following process:

1. Various methods for debugging CSI capture errors on Xavier-based platforms.

2. How to determine which method to use for debugging.

3. How to identify errors.

4. Possible root causes of the error.

The layers where errors may occur during camera capture are as follows:

Whenever an error is encountered while decoding CSI packets received on the SoC CSI interface and writing raw frame data to memory, the VI hardware engine notifies the RCE of these errors. The capture stack running on CCPLEX can query the capture status from the RCE and display: the ID of the CSI data stream, the VC ID where the error occurred, the error type, and detailed errors for each error type. The error status provides a good starting point to determine the root cause and determine next steps. If the VI engine does not successfully capture the frame and does not encounter an error and report the error to the RCE, a frame start or end timeout error message prompt is displayed. This may be due to one of two reasons:

1. The deserializer does not stream data.

2. The VI channel is not configured to capture the correct data type/VC id.

4. How does NVIDIA consider information security in its chip series?

For NVIDIA chips, effective information security is mainly guaranteed through two levels: one is the information security chip kernel module Tegra. Although this chip also had a security vulnerability in 2018. Extreme hackers used a vulnerability in the NVIDIA Tegra X1 chip to crack the Switch console. This vulnerability allows anyone to run arbitrary code on it, which means that homemade systems and pirated software can run at will. However, through continuous internal optimization, NVIDIA has largely completed the vulnerability patching.

For example, on the original Nintendo Switch console, which uses the same Tegra X1 CPU, a vulnerability was found in the ROM bootloader, which was fixed via recovery mode and buffer overflow. NVIDIA can address this type of fix by storing the patch in the internal ROM using built-in programmable fuses. This takes into account both weak links and security, reducing code bugs.

As another example, the nature of the hardware design means that certain internal hardware modules cannot be accessed by CCPLEX, and only BPMP can manipulate them. All low-level boot steps, including u-boot, can be secured by signed binaries. Their keys can be stored in one-time programmable fuses in the CPU. U-boot itself can be configured to use a signed FIT image, providing a secure boot chain all the way to Linux

The kernel, the initial ROM bootloader, and TegraBoot also support fully redundant boot paths.

Tegra is a unique information security chip core in NVIDIA chips. Tegra Security Controller (TESC) is an information security subsystem with its own trusted root ROM, IMEM, DMEM, Crypto accelerators (AES, SHA, RNG, PKA), key links and key storage. TSEC provides an on-chip TEE (Trusted Execution Environment) that can run NVIDIA-labeled unprocessed code. TSEC is a typical secure video playback solution that downloads the HDCP1.x and 2.x connection authorization and complete line-end connection detection required for information security operation.

In general, TSEC can support:

1) HDCP 1.4 on line-side HDMI 1.4 and HDCP 2.0 2.1 on line-side HDMI 2.3;

HDCP connection management does not expose protected content and does not require a software key running on the CPU. Two software programmable independent command queues (up to 16 instructions) for HDCP link management; the entire chip is able to disable HDMI output when the HDCP status check fails, independent of the player.

2) Platform safety controller;

It is a high-security subsystem that can protect and manage assets (keys, fuses, functions, features) in the SOC, provide trusted services, enhance freedom from attacks on the SOC, and improve the level of protection against software and hardware attacks on the subsystem itself.

3) Key management and protection;

The PSC will be the only mechanism that can access the most critical keys in the chip. This subsystem represents the highest level of protection in Orin-x, and the subsystem itself is highly resilient to a variety of software and hardware attacks.

4) Credit services;

For example, during SOC secure boot, key PSC services can complete valid secure authentication, provision additional keys/IDs/data, key access and management, random number generation, and trusted time reporting.

5) Information security monitoring.

The PSC will be responsible for regular security management tasks, including continuously assessing the security status of the SOC, proactively monitoring known or potential attack modes (e.g., voltage failures or thermal attacks), mitigating the risk of hardware attacks, and taking effective action if an attack is detected. The PSC will be able to accept various software updates as workarounds to improve the robustness of field systems.

The second is the application of the security engine (SE), which can provide hardware acceleration for encryption algorithms.

There are two cases where the Security Engine SE is useful for software use. First, TZ-SE can only be accessed by trusted zone software. Second, NS/TZ-SE can be configured to be accessed by trusted software zone or non-secure software. The Security Engine SE can provide hardware acceleration and hardware-backed key protection for various cryptographic algorithms. The cryptographic algorithms provided by SE can be used by software to establish cryptographic protocols and security features. All cryptographic operations are based on cryptographic algorithms approved by the International Institute of Standards and Technology (NIST).

NVIDIA's Security Engine SE supports all information security capabilities including the following:

NIST compliant symmetric and asymmetric encryption and hashing algorithms, side channel countermeasures (AES/RSA/ECC), independent parallel channels, hardware key access control (KAC) (rule-based, symmetric keys to enhance hardware access control), 16xAES, 4xRSA/ECC keyholes, hardware key isolation (AES keyhole only), read protection (AES keyhole only), hardware keyhole functions, key wrapping/unwrapping functions (AES->AES keyhole), key separation from keyhole (KDF->AES keyhole), random key generation (RNG->AES keyhole).

5. Summary

This article fully analyzes the main features and strategic advantages of NVIDIA chips in the application process from the perspectives of core architecture, functional safety, and information security. For how to use NVIDIA series chips for development, it is particularly important to fully consider their internal architecture and combine their functional safety and information security capabilities for the entire development and tuning. Subsequent articles will conduct detailed strategic analysis from the perspectives of hardware development and software development respectively.