Improve memory isolation technical requirement

For any technical requirement which includes a test, the manufacturer shall document the instructions for setting up and running the test, as well as the expected output. Documentation shall include source code and usage documentation for each test, along with the options or inputs necessary to run the tests.

### 5.2.X **TR-MISO**: Memory isolation

### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data

#### 5.2.X.1 Example threat

The manufacturer shall protect security-relevant memory addresses from unauthorized access by executables under the operating system's control, including the operating system itself. This includes system memory, storage addressable via memory mapping, memory for I/O devices, and anything else accessible via the memory-related instructions in the platform.

Attacker tries to access memory that belongs to another user or the kernel in an unauthorized manner.

The operating system does not need to protect against unauthorized access by elements of the platform it is running on (e.g. CPU microcode, devices on the system bus, other operating systems in the device, a hypervisor). Future iterations of the standard may add this requirement for appropriate use cases.

#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory protection

#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory errors

Use case: operating systems where all executables share a single address space, memory protection settings, and processor privilege level (e.g. embedded, low power, special purpose, unikernel)

The manufacturer shall check all security-relevant parts of the operating system for memory errors using a source code analysis tool that detects at least the following types of memory errors, subject to whether each error is possible in the source code language:

* Mitigation: statically check source code for out-of-bounds memory access

* Test: source code that accesses memory out-of-bounds in a variety of defined ways (TBD)

* Result: warning or error

* Output: the warning or error message produced by the checker

* False positive test: source code that does not access memory out of bounds does not produce the warning or error

* Requirements: board support package

* Documentation: source code and output of the tests, source code of operating system, checker information

* buffer overflow

* use after free

* double free

* uninitialized variables

* dereference invalid pointer

* TBD others?

All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be accompanied by an explanation of why the code in question will not produce an error under expected conditions of use.

* Test: run a source code analysis tool on all security-relevant parts of the operating system

* Result: no warnings or suppression of warnings that do not have documentation showing why they are memory safe

* Output: the output of the source code analysis checker

* False negative test: for each kind of memory error in the above list, write a test program with the error, run the analysis tool on it, and show that it produces a warning for each error

#### 5.2.X.x **MI-USEP**: User account separation

* Result: failure to log in

* Output: error message logged to system log

#### 5.2.X.x **MI-MMUP**: Memory protection using MMU

#### 5.2.X.x **MI-MMUP**: Memory segmentation using MMU

Use case: Any operating system that requires process isolation (anything with multiple users, potentially untrusted users, untrusted userspace executables, etc.)

* Requirements: ability to compile and execute code

* Documentation: test source code, instructions to compile, output of error handling or log message for thread kill

#### 5.2.X.x **MI-SPEX** Prevent data leak through speculative execution attacks

FIXME fill in

### 5.2.X **TR-OOBM**: Out-of-bounds memory access prevention or mitigation

FIXME: should all of this be required for executables running with elevated privileges?