Is Your Memory Protected? Uncovering Hidden Vulnerabilities in Automotive MPU Mechanisms

Introduction

As you’re reading these very lines on your computer screen, it is certain that the very device facilitating this interaction is equipped with a Memory Management Unit (MMU). Often overlooked but indispensably important, MMUs are the unsung heroes of modern computing, silently managing memory resources and ensuring the smooth operation of the software we rely on daily, including the one you are using to read these lines now. From your smartphone to the powerful servers that drive the Internet, MMUs are at the heart of it all, orchestrating memory allocation, optimizing performance, and safeguarding against security vulnerabilities.
Unfortunately, this blog post will not be about MMUs, simply because MMUs are usually not implemented in the micro-controller units (MCUs) which are at the heart of the majority of Automotive Electronic Control Units (ECUs).
Instead, this blog post is about the MPU, or Memory Protection Unit, which may be likened to the younger, underrated, sibling of the MMU. While MMUs often receive more attention due to their central role in memory management of Central Processing Units (CPUs), MPUs play a crucial but sometimes overlooked role in enforcing memory protection, preventing unauthorized access, and safeguarding against security threats. 

This blog post is structured as follows: 

• Functionality of the Modern MPU: Explanation of the modern Memory Protection Unit (MPU) and its special role in securing the automotive domain.
• Types of MPUs Used in Modern MCUs: Discussion on the different types of MPUs used in modern Microcontroller Units (MCUs).
• Discovered Vulnerabilities: Detailed description of the vulnerabilities we discovered (CVE-2023-48010 and CVE-2024-33882).
• Responsible Disclosure Processes: Overview of the responsible disclosure processes with the chip vendors.
• Suggested Mitigations: Suggestions for mitigations to address the vulnerabilities.

Background

From MMUs to MPUs

In modern Central Processing Units MMUs are typically hardware devices used as virtual address space managers, mapping virtual addresses to physical ones. MMUs generally perform additional memory-related tasks as well. MMU’s memory protection is designed to block attempts by a program to access memory it has not previously requested, which prevents a misbehaving program from using up all memory or malicious code from reading and writing data of other programs.

Early microprocessor designs, such as the IBM System 360 from 1965 and the Apple Macintosh from 1986 all included MMUs for handling virtual memory mapping and memory access permissions.

Smaller microcontrollers, however, did not require the virtual memory mapping overhead of the MMU, but one weakness of microcontroller’s architecture was the use of a common memory for operating system, user software and variables. This became even more difficult when multiple core microcontrollers began storming the market, where multiple applications in different security and safety levels are using the same common memory.

Those applications that required a higher level of security, such as the Automotive industry, implemented a downsized version of the MMU that only managed memory access permissions. This was the beginning of the Memory Protection Unit, or MPU.

The MPU: A Modern Day Cyber Sentinel

A Memory Protection Unit (MPU) is a programmable hardware unit that acts as a gatekeeper of memory. It enables the user to divide the memory into different regions and set memory access permissions (privileged access only or full access, etc.) and memory attributes (Read/Write/eXecute) to each of these regions.

In very basic terms, MPUs oversee access control to the memory resource, while Access Control is defined as a “security technique that regulates who or what can view or use resources in a computing environment.”¹ It is a fundamental concept in security that minimizes risk to organizations.

In a broad sense, as mentioned in Computer Security, Principles and Practice:

“… all computer security is concerned with access control… Access control implements a security policy that specifies who or what may have access to each specific system resource and the type of access that is permitted in each instance.”²

In that sense, an MPU is one of the main safeguards of security in general, and in embedded systems (Automotive included) in particular. One research, FROM MMU TO MPU: ADAPTATION OF THE PIP KERNEL TO CONSTRAINED DEVICES³, demonstrated that although activating an MPU in a microcontroller causes a 16% overhead on both performance and energy consumption, it reduces the attack surface of the accessible application memory from 100% down to 2%⁴!

An attempt to access unauthorized memory results in a hardware fault, which effectively stops the potential attack and handles the unauthorized access, e.g. by resetting the system and “shaking off” the attacker.

An MPU, once enabled, may restrict execution access on Random Access Memories (RAMs). So, although a first stage of attack, writing the malicious exploit code into Target’s ECU stack memory using the stack buffer overflow vulnerability, is successful, execution of that code on the stack memory area failed due to MPU protection.

Protection Units in the Automotive Domain

Memory Protection Units play a crucial role in the automotive market by enhancing the security, reliability, and safety of embedded systems within vehicles. Here’s a summary of their role:

• MPUs contribute to securing Automotive systems by implementing and enforcing memory protection mechanisms. These help prevent unauthorized access, data corruption or unintended execution of code, safeguarding critical information and functions from external threats.
  
• MPUs can differentiate between different privilege levels and strictly  enforce pre-determined access control policies.
  Automotive applications frequently use components with different privilege levels, such as the Hardware Security Module (HSM), the Boot Loader application, Secure Boot processes and 3rd party applications. The ability to block memory accesses directed to the HSM memory by unauthorized applications, for example, is a crucial security tool in the hands of the Automotive system architect.
• Safety is enhanced by MPUs. MPUs assist in creating safety-critical systems by enforcing memory protection policies, isolating critical software components, and reducing the risk of errors or malicious interference that could compromise vehicle safety.
  
• MPUs enable the isolation of different applications within the vehicle’s embedded systems. Each application or software module can be allocated its own protected memory space, preventing unintended interference or data corruption between applications. This isolation is essential for maintaining the integrity of critical functions and ensuring that successful attacks on one application do not impact others in the same system.
  
• Memory Protection Units play a pivotal role in managing and securing the interactions of bus masters within a system, including cores, Direct Memory Access (DMA) controllers and core-external peripheral controllers, such as CAN, USB, GPUs and so on. In the context of bus masters, MPUs act as critical components ensuring the integrity and security of data transfers. By providing memory protection mechanisms, MPUs enable the isolation of different bus masters, preventing unintended interference and potential conflicts in accessing shared memory. This capability is especially crucial in multi-core systems where various cores may concurrently access memory resources. MPUs contribute to the establishment of secure and well-defined boundaries, allowing each bus master to operate within its allocated memory space. MPUs enforce access controls to safeguard against unauthorized or malicious activities, ensuring the confidentiality and integrity of data during high-speed, extra-core  transfers. 

Types of MPUs

Not all Memory Protection Units are cut of the same cloth, and depending on architecture we may see a variety of them. However, we can generalize and describe the three main types below, as shown in the following example block diagram:

Core MPU (CMPU)

CMPU, also known as Core MPU or CPU MPU, is a Memory Protection Unit integrated directly into each of the cores of the microcontroller. It operates at the core level, providing fine-grained memory protection and access control mechanisms. The CMPU enables the enforcement of memory protection policies for code and data accesses initiated by the core itself. It typically supports setting access permissions (read, write and execute) and privilege levels per each multiple memory regions. CMPUs are essential for securing memory access of individual software processes running on each of the microcontroller’s cores.

System MPU (SMPU)

SMPU, also known as System MPU, is a Memory Protection Unit designed to protect the entire system memory space. Unlike CMPU, which provides protection from the core’s perspective, SMPU operates at the system level and provides memory protection from bus transactions⁵ within the system. While Core MPUs monitor and control bus transactions originating from software code running on the cores, the System MPU enforces control over bus transactions across the entire system, including hardware related mechanisms, such as Direct Memory Access (DMA), HSM etc. The SMPU address regions are usually defined by the source of the bus transaction. For example, the SMPU may be configured to allow access to a specific address range in shared memory to the HSM, while blocking all other bus transactions originating from other sources.

Peripheral Protection Unit (PPU)

PPU, also known as Peripheral MPU, is a specialized Memory Protection Unit dedicated to protecting memory-mapped registers within the embedded system. PPU provides access control and security features specifically tailored for peripherals, such as communication interfaces, timers, and I/O ports. It allows for the enforcement of access permissions and restrictions on peripheral accesses initiated by the processor cores or external bus masters. PPU enhances the security and reliability of peripheral interactions, preventing unauthorized or malicious access to critical system peripherals.

CVE-2023-48010 and CVE-2024-33882

A carefully configured Memory Protection Unit would prove to be a strong opposition to any attacker. However, as the cliche says: “Any chain is as weak as its weakest link”. If an attacker is capable of disabling a perfectly configured MPU, naturally, the protecting characteristics of the MPU simply fade away.

These two vulnerabilities, CVE-2023-48010 and CVE-2024-33882 are both hardware vulnerabilities we identified relating to a specific design of PowerPC microcontrollers. They allow a privileged attacker to shut off the entire SMPU (System Memory Protection Unit), and so allow read and write access to protected memory areas. Although, according to the datasheet of the PowerPC microcontroller, a certain hardware feature should have ensured that the SMPU remained enabled after its initial configuration, even if an attacker attempted to disable the SMPU, it has become apparent that this feature is not actually implemented in the silicon as claimed, thus leaving the SMPU vulnerable to such attacks.
Consequently, the software’s designer may remain under the impression that by taking the measures detailed in the datasheet they are protected, completely unaware of the actual lack of protection and the risk to their system.

Some background: The PowerPC architecture

The first PowerPC microcontroller was manufactured by Motorola, which later became Freescale Semiconductor, in the mid-1990s. These microcontrollers, known as the MPC5xx series, marked the initial foray of PowerPC architecture into the embedded systems market, including automotive applications. The roots of the MPC5xx family can be traced back to the collaborative efforts of IBM, Apple, and Motorola in the early 1990s.
With its RISC-based design offering a blend of performance and efficiency, the first PowerPC processors found their way into automotive systems by the late 1990s. Initially employed for tasks like engine and transmission control, their real-time processing capabilities and robustness in harsh conditions quickly made them indispensable for a wide array of applications, from infotainment systems to advanced driver assistance systems (ADAS). 

Around the mid-2000s, a joint collaboration between STMicroelectronics and Freescale Semiconductor (now NXP Semiconductors) resulted in the development of the MPC56xx/SPC56x family based on the PowerPC architecture, specifically designed for automotive applications⁶. In both manufacturers, the packages are pin-to-pin compatible and the microcontrollers are almost identical.

The Vulnerabilities

(1) CVE-2023-48010

On top of penetration testing and security research, we at PlaxidityX design and develop security products and solutions for automotive systems. In our case, we developed a Proof-of-concept (PoC) for a future product. As part of the evaluations we do before choosing a system to work with, we based the PoC on the PowerPC SPC58N family of microprocessors from STMicroelectronics, mainly because, as said above, these microcontrollers have been specifically designed for automotive applications and are extensively used.

The SPC58N is a triple core 32-bit ‘Power Architecture⁷’ microcontroller for automotive ASIL-D⁸ and security applications. 

Here is the block diagram of the chip from the chip’s datasheet:

At the bottom of the diagram we have the chip’s memories: Flash and EEPROM marked in gray, and Static RAM marked in blue. These memories are, by definition, commonly accessible by all cores and peripherals.
At the upper part of the diagram are the cores, each with their own Core Memory Protection Unit (CMPU – marked by the red rectangles), and 64 DMA channels in between the cores (marked green).

In between the cores, DMA channels and memories, in the yellow rectangle, is the System Memory Protection Unit (SMPU).

Knowing in advance that many different applications would be running on the cores, each with its own safety and security levels, we set out to meticulously define the CMPU and SMPU configurations.

The Core MPU and its Limitations

Each of the Core MPUs (CMPU) monitors all instruction fetches and data memory accesses originating from each of the cores. The CMPU is a hardware facility that system software uses to define memory regions and their associated access permissions. The CMPU triggers an exception if software attempts to access a memory region in violation of its permissions, allowing the system designer to intervene and handle the exception as appropriate.

Security-wise, the CMPU is a very important part of the overall security posture because of two main points:

1. The CMPU is the only entity in a microprocessor architecture capable of detecting stack buffer overflows. A stack buffer overflow occurs when a program writes more data to a buffer located on the stack than the buffer can hold, leading to the overflow of adjacent memory addresses. This can happen when input data is not properly validated or bounded by the program, allowing an attacker to overwrite the return address of a function or other important data on the stack. As a result, the attacker can potentially execute malicious code on the stack and disrupt the program’s normal behavior, eventually gaining arbitrary code execution.
   By carefully defining stack areas for all applications running on the microcontroller, the designer can configure the CMPU to block execution on those stack areas, thus considerably limiting the attack surface.
2. The CMPU effectively limits application’s read / write operations.This makes certain that if an attacker gains code execution on any of the cores (e.g. by running from a malicious third-party code), a properly configured CMPU is there to detect a malicious memory access and disrupt the attacker’s move.
   
   Or does it?

Looking back at the block diagram above, we can see that although having a properly configured CMPU on each of the cores does help prevent memory accesses from the cores themselves, it does nothing to prevent an attacker on the cores from accessing memories by exploiting special peripherals, such as Direct Memory Access (DMA), Ethernet, HSM and more.

To effectively defend against these types of attacks, we have the SMPU.

The System MPU (SMPU)

On first glance the SMPU is very similar to the CMPU. It is a hardware facility that system software uses to define memory regions and their associated access permissions, and upon violation of its permissions, allows the system designer to intervene and handle an exception thrown.

However, the SMPU has one special feature that the CMPU does not have: the SMPU concurrently monitors and evaluates memory accesses per bus master.

This is the list of available bus masters for the SPC58N:

Each bus master has its own read/write/none flags, that manage its access to a specified memory region. For example, the SMPU may be set up such that a specific memory region may be accessed by the HSM only, while all other masters are to be rejected. In that case, although the CMPU does not block access to those specific HSM addresses, any attempt to read or write to HSM memory would be effectively blocked by the SMPU.

Another example is DMA access: An application running on Core1 may be specifically blocked from accessing a memory region by Core1’s CMPU. However, an attacker may use the DMA hardware to gain read / write access to that forbidden memory region, and by doing that circumvent the CMPU prohibition.

It seems, therefore, that one of the SMPU’s crucial features is its ability to block memory access by the originating master, and as a consequence, to block other masters from accessing the memory.

To summarize: In the microcontroller architecture, Core MPUs (CMPUs) play a critical role in monitoring and regulating memory accesses from each core. They enforce memory regions and their permissions, triggering exceptions when violations occur. This capability is pivotal for security, e.g. in preventing stack buffer overflows, a common attack vector, from becoming arbitrary code executions.
While CMPUs address core-based memory accesses, they don’t cover attacks exploiting special peripherals like Direct Memory Access (DMA). This gap is filled by the System Memory Protection Unit (SMPU), which extends protection to various bus masters. SMPUs concurrently monitor and evaluate memory accesses per master, enabling granular control over memory permissions. In essence, the SMPU’s unique capability to regulate access by the originating masters enhances overall system security, thwarting potential exploits leveraging peripheral hardware.

Configuring the SMPU 

In the previous paragraph we learned of the importance of properly configuring both the CMPU, to prevent application code running on the cores from directly accessing forbidden memory areas (due to security or safety reasons), and the SMPU, to prevent indirect memory access.

The SPC58N chip that we were using had 24 region registers that allowed the designer to set read/write access control permissions per each of the 16 bus masters.

Each SMPU region is composed of a 32-bit start address and an end address, which is the protected address area and region format registers. These define, per the 16 bus masters, the allowed access permissions (read, read/write or no access allowed).

Each region has its own valid bit, and a Read Only bit. But before delving into the read only bit in the next section, let’s first address another important SMPU register, the CESR0 register. 

Once everything is properly configured, the Global Valid (GVLD) bit in the Control/Error Status Register 0 (CESR0) has to be set, and the SMPU is enabled and ready to counter any potential attack, as shown below:

The Region Read Only Bit

Now, going back to the read only bit. Let’s look at the datasheet:

The Read Only (RO) bit serves the purpose of preventing unintended alterations to the region descriptor. When the RO bit is set, writes to any location in the region registers are ignored. That’s perfectly understandable and important. We want the region to be protected from accidental or malicious writes once it is set. But there’s also a note with the RO bit description:

 Source:  RM0452 SPC58H, p. 536

The above note says that once the RO bit is set, all the region is locked and cannot be changed until a system reset, at which time the region valid bit and the global valid bit (GVLD) has no effect, meaning they cannot be changed until the system reset.

This is a smart defensive trick: once the SMPU region information is configured and the RO bits are set, the global valid bit (GVLD) cannot be manipulated and therefore an attacker would not be able to disable the SMPU. The only way to disable the SMPU would be after the next system reset, so the attacker would lose any grip they had on the device-under-attack.

The SMPU Vulnerability

After we finished setting up the SMPU we can now start testing the entire system. The product was configured such that one core was running the safety (ASIL-D) application and the second core was running 3rd party applications. Naturally, the two cores shared memories.

The SMPU was configured to protect the memory area of the safety application (Flash, EEPROM and SRAM) against reads and writes from the application core. Furthermore, the RO bits were all set, so it wouldn’t allow any changes to the SMPU protections until a system reset.

During penetration testing, we simulated an attacker on the application core. 

We soon found out that, although the datasheet of the SPC58 specifically mandated that the GVLD bit would have no effect on the SMPU after setting the RO bits, this hardware mechanism was not implemented in the silicon, and therefore an attacker on the application core would be able to disable the SMPU by writing 0 to the GVLD bit, and then gain access to the memories of the safety core, for both read and write operations.

Even if the CMPU would have been correctly configured, disabling the SMPU would have opened the main memories to attacks through system peripherals, such as the DMA or Ethernet.

Disclosure to STMicroelectronics

Right after finding about this behavior on the SPC58 chip, we contacted STMicroelectronics PSIRT with all relevant information about the weakness.

After some back and forth correspondence, STMicroelectronics said they would release an errata for the issue, and here is their full response to the issue:

“The behavior deviation of SMPU you detected may affect non-secure device domains. However, this domain should not be used for storing security information.

Secret/security-critical data shall be stored within the HSM sub-system memory, if stored outside, they need to be encrypted.

The SMPU is not a security protection mechanism: rather, for example, it helps to avoid interference.”

Timeline for STMicroelectronics Responsible Disclosure

Jul 13, 2023	Our report concerning potential security weakness submitted to ST
Aug 7, 2023	STMicroelectronics replied that an errata will be published but not a security vulnerability
Aug 15, 2023	A second email with further explanations sent to ST
Sep 21, 2023	ST responds that “the SMPU is not a security protection mechanism”
Nov 6, 2023	CVE request
Nov 20, 2023	CVE-2023-48010 assigned

Affected STMicroelectronics Parts⁹

• All SPC58 devices
• SR5E1
• SPC574K (K2)
• SPC572L (Lavaredo)
• SPC574Sx (Sphaero)

(2) CVE-2024-33882

Since this PowerPC architecture was developed as a part of a joint venture between STMicroelectronics and Freescale, It was only natural to continue our quest and look for the same weakness in the NXP (formerly Freescale) PowerPC chips.
We chose the NXP MPC5748 which is described as an “Ultra-Reliable MCU for Automotive and Industrial Control and Gateway¹⁰” to see if this PowerPC holds a better security posture than the STMicroelectronics PowerPC chip.

This is the NXP MPC5748 PowerPC microcontroller block diagram¹¹:

Just looking at the block diagram above we could not help but wonder: Where the Core Memory Protection Units (CMPUs) are?

In yellow above we marked the 3 MCU’s cores. None of them is protected by a CMPU. It seems that this system-on-chip only has a System Memory Protection Unit (SMPU), marked red above. In green, we marked the chip’s memories.

Further investigating, we found that the MPC5748’s SMPU also contains the functionality of the CMPU. This means that if the same weakness that was found in the ST SPC58 exists in the MPC5748, an attacker would be able to completely disable the entire memory protection system, core and system protections included!

The NXP register names are quite similar to those of the STMicroelectronics chip. The “Global Valid” GVLD bit is located in bit 31 of the SMPUx_CES0 register:

Source: MPC5748G Reference Manual, Rev. 7.1 p. 493-494

And the memory regions are defined in register SMPUx_RGDn_WRD5:

Source: MPC5748G Reference Manual, Rev. 7.1, p. 505

Quite similar to the STMicroelectronics SPC58, a Region Descriptor Lock (LCK), or Read Only bit (RO) in the SPC58, is used to lock the memory-protected regions after these have been configured (in yellow above). The Note in red seems to be similar to the SPC58:

Again here, as in the SPC58 microcontroller, the wording is almost identical: Once you lock the regions the Global Valid bit of the SMPU has no effect, so the SMPU can not be disabled anymore.

A short test revealed that although the SMPU is enabled and all LCK bits are locked, a privileged attacker can still set the Global Valid to 0 and by doing that completely disable the SMPU. Since there is no separate CMPU, by disabling the SMPU an attacker gains unrestricted read/write/execute access to the entire memory space.

Disclosure to NXP

Right after finding out about this behavior on the MPC5748 chip, we contacted NXP PSIRT with all relevant information about the weakness.

After some back and forth correspondence, NXP acknowledged the documentation was not clear and said they would release a documentation errata this summer (date TBD) to remove ambiguity and prevent misunderstanding. However, NXP stated that the SMPU is not a security feature.

NXP’s full response is brought in its entirety below¹²:

“The product’s Reference Manual is clear about the SMPU not being a security feature. The SMPU is not mentioned in the chapter ‘Security Overview’, nor in the section ‘Security Modules’, but rather in the section on ‘System Modules’. The SMPU is also not listed under ‘Security’ in the ‘Feature List’ table and the chapter that describes the SMPU does not mention ‘security’.”

As much as we read through the reference manual of the MPC5748 chip, we could not find a positive reference to the SMPU not being a security mechanism. To the contrary, in chapter 21 section 2 of the reference manual, the SMPU paragraph states that:

“The System Memory Protection Unit (SMPU) provides hardware access control for system bus memory references. The SMPU concurrently monitors system bus transactions and evaluates their appropriateness using preprogrammed region descriptors that define memory spaces and their access rights. Memory references that have sufficient access control rights are allowed to complete, while references that are not mapped to any region descriptor or have insufficient rights are terminated with an access error response”¹³ [emphasis added] 

So, although the reference manual does not mention the SMPU, direct or indirect, other than in the SMPU chapter, the reference manual’s author described the SMPU as being in charge of controlling access permissions to the memory spaces of the MCU, which is the cornerstone of computer security.

Timeline for NXP Responsible Disclosure

Feb 28, 2024	First email to notify to NXP
Feb 28, 2024	NXP assigned an Internal ID
Mar 21, 2024	Email reminder to NXP
Mar 21, 2024	NXP respond – investigation still in progress
Mar 28, 2024	NXP replied that the note was phrased in an ambiguous way and an errata will be published. Behavior as expected.
Mar 31, 2024	An email with further explanations sent to NXP, arguing that the SMPU is a security mechanism and this is indeed a weakness in their implementation
Apr 04, 2024	Final response from NXP – NXP do not consider it as a security issue
Apr 16, 2024	CVE request
Apr 28, 2024	CVE-2024-33882 assigned

Mitigations

• Make sure you verify all important claims, especially those that involve important security mechanisms such as MPUs, made in the datasheet, either by testing them yourself or by going to an external Penetration Testing vendor. 
• Always read your MCU’s errata, as they may contain important information about the chip’s security posture.
• Relating to CVE-2023-48010: If you find that you can not rely on a hardware mechanism for security – as in the case of the SMPU above, don’t! Look for other methods to achieve the same level of security or make sure you use it in a safe and secure way. For instance, use other Memory Protection Units, such as the CMPU in the STMicroelectronics MCU.

Concluding remarks

As we’ve shown throughout this paper, Memory Protection Units are a crucial part of every microcontroller’s defense strategy. MPUs are indispensable in the context of Automotive applications, by enhancing the security, reliability, and safety of ECUs and embedded systems within vehicles. It is therefore extremely difficult for us to accept NXP and STMicroelectronics’ argument that a hardware mechanism designed to enforce access controls over shared resources is not a security mechanism.

Although both vendors specifically mentioned that, when following a sequence of operations, the SMPU can no longer be deactivated, we showed that the hardware parts that were supposed to lock the Global Valid Bit were not implemented, therefore, allowing a privileged attacker to disable the SMPU and gain access to sensitive memory regions that were otherwise inaccessible.

1. Source: https://www.techtarget.com/searchsecurity/definition/access-control#:~:text=Access%20control%20is%20a%20security,access%20control%3A%20physical%20and%20logical.
   ↩︎
2. W. Stallings, L. Brown, Computer Security: Principles and Practice, 3^rd Edition, p. 114 ↩︎
3. Nicolas Dejon, Chrystel Gaber, Gilles Grimaud. From MMU to MPU: adaptation of the Pip kernel to constrained devices. 3rd International Conference on Internet of Things & Embedded Systems (IoTE 2022), Dec 2022, Sydney, Australia. ffhal-03705114v2f ↩︎
4. https://hal.science/hal-03705114v2/file/FromMMUToMPUAdaptationOfThePipKernelToConstrainedDevices-IoTE2022-Final.pdf p. 2 ↩︎
5. a bus transaction refers to the exchange of data or control information between two devices connected by a bus in a computerized system. A bus is a communication pathway that allows multiple devices within a computer system to communicate with each other. ↩︎
6. https://en.wikipedia.org/wiki/PowerPC_e200 ↩︎
7. This is the trademark name given by STMicroelectronics to the PowerPC microcontroller line ↩︎
8. ASIL D, an abbreviation of Automotive Safety Integrity Level D, refers to the highest classification of initial hazard (injury risk) defined within ISO 26262 and to that standard’s most stringent level of safety measures to apply for avoiding an unreasonable residual risk ↩︎
9. This list of affected MCUs was sent by STMicroelectronics via an email on March 13, 2024 ↩︎
10. https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/mpc5xxx-microcontrollers/ultra-reliable-mpc57xx-mcus:MPC57XX ↩︎
11. https://www.nxp.com/docs/en/data-sheet/MPC5748G.pdf, p. 4 ↩︎
12. This response is from an email sent on April 4th, 2024 ↩︎
13. MPC5748G Reference Manual, Rev. 7.1, 01/2019, p. 479 ↩︎