Weaknesses in Defenses Against Memory Interference

Freedom from Interference

You are right if you consider taking enough sleep as a safeguard against memory interference. However this blog is not about interferences that affect our human memory and learning capabilities. Instead it is about how memory interferences are detected and resolved in today's safety critical software systems. Nevertheless there are quite a few similarities between a psychological and a software engineering view on memory interference.

Traditional automotive software systems replaced or improved mechanical systems. Today's advanced driver assistance systems (ADAS) go a step further and either assists or start to replace the biochemical systems that operate the car, i.e. you the driver. Such ADAS systems are able to compensate the perceived weaknesses in specific masculine and feminine behaviors and skills. For example dynamic stability control systems mitigate the effects of self-overestimation, and intelligent parking assist system compensate for lack of spatial visualization ability. However both human and electronic systems are also susceptible to failures that share an identical root cause. If the human driver or microcontroller execute multiple tasks simultaneously there is a risk that a memory or a data object related to one task is lost or mutilated by interferences from another task. In both scenarios such failure can introduce severe safety risks.

In psychology, the memory interference theory also known as the theory of forgetting, explains how new information may cause existing memories to disappear or become inaccessible or inaccurate. This blog covers the same topic from a software engineer's perspective and addresses the safety mechanisms implemented in hardware and software to detect and mitigate the effects of memory interferences. This topic is becoming more and more important, first because the automotive safety standard ISO 26262 states that freedom from interference (FFI) shall be ensured, and second because the current trends in automotive hardware and software architectures increase the likeliness that interferences do occur.  

Domain Controllers Increase Interference Vulnerability

In the automotive industry there has been a shift from separate electronic control units (ECUs) that implement one function each towards a more integrated architecture where multiple software components are co-located on a single ECU, often referred to as a domain controller. Such integrated architecture provides advantages such as a reduced data communication overhead, and reduced material costs with less wires and connectors which are known to be fault prone. However there are also risks associated such as an increased likelihood that a fault in one software component could cause another safety relevant software component to fail.

ISO 26262 Guidance on FFI

ISO 26262 provides some goal based guidance about ensuring “freedom from interference”, which is defined as the “absence of cascading failures between two or more elements that could lead to the violation of a safety requirement”. The guidance is of particular interest for mixed criticality systems that contain software components with different automotive safety integrity levels (ASILs), or safety-related and non-safety-related software components. In such case all of the embedded software shall be treated in accordance with the highest ASIL, unless the software components meet the criteria for coexistence. As a result the verification cost of non-safety-related and lower ASIL software components will increase dramatically, unless freedom from interference can be ensured by some means. ISO 26262 describes software partitioning as solution to ensure freedom from memory interference, where for ASIL D the software partitioning shall be supported by dedicated hardware features.

MPU detects Memory Interferences

Therefore automotive microcontrollers such as the Infineon AURIX® provide various safety features that protect against memory interferences. The memory protection unit (MPU) facilitates enforcement of privilege rules, separation of software components, and enforcement of access rules. If an interference occurs the hardware emits an interrupt and the software tries to recover from the error. The number of partitions that can be serviced by the hardware is limited compared to the number of software components located on an ECU (roughly 1:10). As such this results in a coarse-grained protection scheme where software components are typically not protected against interferences from other software components with the same ASIL.

(AUTOSAR) RTOS and Hypervisors

Runtime environments such as (AUTOSAR) operating systems or hypervisors also provide mechanisms to support freedom from interference. Typically the runtime system uses the memory protection features of the underlying hardware. A fine-grained protection model can be realized if the runtime system reprograms the memory protection facilities of the hardware, e.g. on task switches. This causes a trade-off between safety and performance, whereby the processing speed will degrade significantly due to the large number of task switches that are typical for automotive software. Furthermore, an additional safety trade-off is introduced since MPU hardware designs often contain safety measures to make the implementation more robust against transient hardware errors caused by electromagnetic interference and radiation. If the MPU is dynamically reprogrammed the in-memory data structures that hold the memory access permissions are vulnerable to transient hardware errors that can break address mappings and permissions.

Limitations in Interference Detection & Recovery

As shown, the current safety mechanisms to ensure freedom from interference have severe limitations. If ISO 26262 guidance is applied and the system is implemented on a modern automotive microcontroller equipped with an AUTOSAR compliant RTOS then still:

• Freedom from interference between software components of the same ASIL rating is not provided.

• Freedom from interference is not supported at the task-level.

• The memory partitioning is not applicable for trusted OS components.

• Error detection and recovery is course-grained and takes place at run-time. A failure of a single software component results in the shutdown or restart of the entire memory partition thereby affecting all other correctly working software components located in this partition as well.

Conclusion

It’s clear that software partitioning and freedom from interference is a system-level concern that is not yet solved today and shall be addressed at architectural, design and implementation levels. If you want to read a more in-depth coverage of this subject you can download our free whitepaper “Freedom From Memory Interference - How safe and secure are current defenses?”.

In a next blog I will evaluate a safety mechanism, ASIL Aware Static Analysis, to ensure freedom from interference at software construction time.