Pitfalls for Security Isolation in Multi-CPU Systems

Pitfalls for Security Isolation in Multi-CPU Systems

Speakers: Simeon Hoffmann

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=6SM7Ezr5B6A

Overview

As IoT devices demand more computational power without increasing power consumption, manufacturers have turned to multi-CPU architectures -- multiple processors on a single chip, each running independent firmware. This talk presents the first systematic security assessment of these multi-CPU embedded systems, revealing that the assumed security boundary between CPUs is largely illusory. The researchers identified four attack vectors across memory, bus, peripheral, and CPU communication domains, and found that more than half of the top 10 MCU manufacturers' multi-CPU device families are vulnerable.

Most alarmingly, the research demonstrates a practical exploit against the Samsung Galaxy Ring, which uses a Nordic NRF5340 dual-CPU microcontroller. By exploiting the lack of security isolation between the application core and network core, a vulnerability in the network core firmware can be used to leak data from kernel mode on the application core -- even when the application core's own firmware runs in user mode. The vendors' response has been a cycle of blame-shifting: Samsung says it's Nordic's problem, Nordic says they solved it in hardware, and the Zephyr RTOS says multi-CPU security is not their threat model.

Background

▶ Watch: Multi-CPU IoT trend: more power without more power consumption (0:00)

Traditional IoT devices use a single CPU connected to all memories and peripherals. Adding a second CPU creates an asymmetric system where different CPUs may have access to different subsets of hardware resources. For example, CPU-A might be connected to all memories and peripherals, while CPU-B is restricted to a subset. This architecture is used for power optimization (one low-power CPU runs constantly, one high-power CPU runs on demand), functional separation (application logic vs. network stack), and independent firmware updates.

The top 10 MCU manufacturers have adopted this design, with 11 multi-CPU device families identified across the market. While one device family may contain over 60 unique, actively maintained devices, no prior research had systematically assessed the security implications of the multi-CPU architecture. The threat model assumes one CPU's firmware is compromised and asks: what can the attacker do on the other CPU? Are there meaningful security boundaries?

Key Findings

▶ Watch: FreeRTOS TOCTOU attack on STM32H755 shared queue (4:00)

Four attack vectors were identified across four domains:

Unsynchronized Communication Channels (presented in detail): CPUs coordinate resource access via shared memory structures (e.g., queue structures in FreeRTOS). Unlike operating systems where a kernel can enforce mutual exclusion, there is no lower-level software entity to enforce synchronized access between two CPUs. Hardware semaphores exist on some devices (e.g., STM32H755), but a compromised CPU can simply ignore them -- there is no enforcement mechanism. This enables classic time-of-check-to-time-of-use (TOCTOU) attacks where the attacker manipulates shared memory while the victim CPU is processing it.

Confused Deputy Peripheral (presented in detail): Even when memory regions are physically disconnected from one CPU, shared peripherals (like DMA controllers) connected to both CPUs and the restricted memory can be used as confused deputies. The attacker CPU configures the shared peripheral to copy data from the restricted memory to an accessible region, bypassing the physical memory isolation.

MPU Policy Disorganization and Non-Exclusive Peripheral Access were also identified but not presented in detail due to time constraints.

The vulnerability assessment found that of 11 multi-CPU device families from top-10 manufacturers: NXP devices are entirely vulnerable, Infineon/Cypress devices are not vulnerable (they implement proper hardware countermeasures), and STMicroelectronics shows a generational evolution with newer devices having fewer vulnerabilities.

Technical Deep Dive

▶ Watch: Vulnerability assessment: NXP all vulnerable, Infineon all safe (8:00)

The unsynchronized communication channel attack was demonstrated on the STM32H755 running FreeRTOS. The shared queue structure contains a read pointer, write pointer, and data field. In a normal ping-pong communication, the attacker writes "hello" and updates the write pointer; the victim reads it, updates the read pointer, and writes "bye" back.

The attack works by manipulating the write pointer to point to an authentication variable in the victim's protected memory. When the victim writes its response ("bye"), it inadvertently writes to the authentication variable instead of the data buffer, granting unauthorized access. This is a textbook TOCTOU attack, but the key insight is that hardware semaphores do not help: the victim can take the semaphore before reading, but the attacker can ignore the semaphore entirely because there is no enforcement entity. The attacker simply accesses the shared memory directly, bypassing the lock.

The confused deputy peripheral attack exploits the asymmetry between CPU memory access and peripheral memory access. If CPU-A stores a secret in memory alpha (not connected to CPU-B), but a peripheral (e.g., DMA controller) is connected to both memory alpha and CPU-B, then CPU-B can program the peripheral to copy the secret to a region CPU-B can directly access. This completely bypasses the intended memory isolation.

The Samsung Galaxy Ring analysis revealed the device runs the Zephyr RTOS on both the application core and network core of the Nordic NRF5340. The application core runs sensing in user mode, while the network core runs a basic BLE setup in kernel mode (close to the Zephyr reference implementation). A vulnerability in the network core can access data from any domain on the application core, including kernel mode resources, because there is no hardware-enforced security boundary between the two cores.

Demo / Proof of Concept

▶ Watch: Samsung Galaxy Ring exploit: kernel mode data leak via network core (10:00)

Rather than fully reverse-engineering the Galaxy Ring firmware, the researchers demonstrated the vulnerability on a Nordic NRF5340 development kit. They flashed the same BLE sample identified in the Galaxy Ring firmware directly onto the network core and placed dummy firmware with kernel-mode secrets on the application core. They then injected a vulnerability in the network core and exploited it to access kernel-mode data on the application core, proving the attack is practical.

The disclosure process was notable for the blame-shifting: ST Microelectronics published a security advisory but did not update their security note that explicitly claims a security boundary exists between the two CPUs. Samsung said it's a hardware problem (Nordic's responsibility). Nordic said they solved it in hardware and it's a software problem (Samsung should fix it). Zephyr explicitly stated that multi-CPU security is not their threat model, despite supporting the NRF5340.

Defensive Implications

▶ Watch: Hardware countermeasures: queues, bus access management, enforced semaphores (14:00)

Software countermeasures can partially mitigate the unsynchronized communication channel attack: reducing metadata in shared memory narrows the attack window, and moving shared data to asymmetrically accessible memory (where only one CPU can write) eliminates the TOCTOU condition. However, not all devices have the required memory asymmetry.

Hardware countermeasures are needed for complete protection:

• Hardware queues (as implemented by Raspberry Pi RP2040/RP2350) where one CPU has the write side and the other has the read side, eliminating the shared-state problem entirely
• Bus-level access management (as implemented by Infineon) that enforces memory access policies in hardware, preventing the confused deputy attack
• Semaphores with enforced data access (as implemented by Infineon) where a data field can only be accessed while holding the semaphore, providing true mutual exclusion

The core lesson for IoT product developers is: do not assume a security boundary exists between CPUs in a multi-CPU MCU unless the hardware explicitly enforces it. Check the specific device family against the vulnerability assessment, and implement defense-in-depth at both the software and hardware levels.

Key Takeaways

• Multi-CPU IoT architectures create an assumed security boundary between CPUs that is largely unenforceable without specific hardware support
• More than half of the top-10 MCU manufacturers' multi-CPU device families are vulnerable to cross-CPU attacks
• Hardware semaphores do not provide security isolation because a compromised CPU can simply ignore them
• The Samsung Galaxy Ring (Nordic NRF5340) has no meaningful security boundary between its application and network cores
• Vendor responsibility is diffused: chip vendors, RTOS vendors, and device manufacturers each claim it's someone else's problem
• Infineon devices demonstrate that proper hardware countermeasures (bus-level access management, enforced semaphores) can eliminate these vulnerabilities
• Newer device generations (STMicroelectronics) show evolutionary improvement, suggesting manufacturers are slowly recognizing the problem

About the Speaker(s)

Simeon Hoffmann presented the research with exceptional clarity, navigating complex hardware architecture concepts with accessible examples. He engaged extensively with audience questions about trusted execution environments on the NRF5340, STM32 TrustZone limitations, and the specific hardware countermeasures employed by non-vulnerable devices. His answers demonstrated deep knowledge of the actual hardware implementations beyond what was in the paper, including vendor disclosure responses and the practical limitations of TEEs in multi-CPU contexts.