Removal of must, minor formatting

|--------------|-----------------------------|

| OS           | Operating system            |

| MMU          | Memory Management unit      |

| IO           | Input/Output                |

| I/O           | Input/Output                |

For the purposes of the present document's risk analysis, the following abbreviations apply:

An operating system abstracts the hardware, allocates resources, and provides services to itself and any other software on the system. It often serves as a central organizing authority that controls access to system resources by various pieces of software, dividing up available resources among the applications and its own subsystems to meet implicit or explicit goals or constraints. An operating system often uses a large part of the resources of the system it runs on, but in return it simplifies the development and deployment of the overall system.

![Temporary architecture diagram](media/architecture.png)

![Figure 1: Temporary architecture diagram](media/architecture.png)

> FIXME GitLab pipeline doesn't work with mermaid

### 4.5.2 Mapping of Use Cases to Risk Factors

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in clause 6.3. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in clause 6.3 Table 1. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.

FIXME needs updates

2. Require security functions be provided by some other part of its context

3. Provide security functions for the use of other components

For example, most individual hardware components do not have a built-in method of securely updating any firmware in the product. Usually this requires a full-featured system running an operating system which can check for firmware updates, download and verify them, and carry out the process of updating the firmware.

> EXAMPLE: Most individual hardware components do not have a built-in method of securely updating any firmware in the product. Usually this requires a full-featured system running an operating system which can check for firmware updates, download and verify them, and carry out the process of updating the firmware.

### 4.10.2 Security functions provided outside the product

The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that the MSAs generally prefer evaluating via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.

Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.

Mitigations are how a technical requirement can be satisfied. Mitigations should be tailored to the use case and take into account the user’s sophistication and the operational environment.

Format:

### 5.2.1 General

This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following clause will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.

This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. Each technical requirement will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.

Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.

#### 5.2.X.x **MI-TRMD** Transfer risk of microarchitectural side channel data leaks to user

The manufacturer shall document that the risk of microarchitectural side channel data leaks has been transferred to the user, who must mitigate them sufficiently for their use case.

The manufacturer shall document that the risk of microarchitectural side channel data leaks has been transferred to the user, who shall mitigate them sufficiently for their use case.

#### 5.2.X.x **MI-ASLR** Address Space Layout Randomization

  * Objective: Limit attack surface

  * Preparation: List all types of interfaces on the product that may be exposed to an attacker, whether enabled or disabled. For each type of interface, identify a method to list all exposed interfaces of that type. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct exposed interface in each state, describe the interface and why it must be enabled by default.

  * Preparation: List all types of interfaces on the product that may be exposed to an attacker, whether enabled or disabled. For each type of interface, identify a method to list all exposed interfaces of that type. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct exposed interface in each state, describe the interface and why it has to be enabled by default.

  * Activities: Using the list of types of interfaces, the list of states of the product, and the method to list all exposed interfaces of that type, list all exposed interfaces in each state. Compare to the documented list.

  * Objective: Minimize data processed

  * Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct source of data processed in any state of the product in its secure-by-default configuration, describe the data processed and why it must be processed for the product to perform its functions.

  * Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct source of data processed in any state of the product in its secure-by-default configuration, describe the data processed and why it has to be processed for the product to perform its functions.

  * Activities: Using the list of sources of data, the list of states of the product, and the method to detect whether the product is processing data from that source, list all sources of data processed in each state. Compare to the documented list.

## Common Memory Safety Mitigations

Many memory safety mitigations apply to both Kernel and Userspace execution environments, and must be protected in both places.

Many memory safety mitigations apply to both Kernel and Userspace execution environments, and shall be protected in both places.

### **MI-SED**: Stack exhaustion detection