@@ -963,39 +963,44 @@ All warnings, annotations, or other method of suppressing warnings from the anal
* 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
#### 5.2.X.x **MI-KSEP**: Separation of operating systems memory from user account memory
Use case: system where multiple users are expected to concurrently share the system's resources or services
The manufacturer shall implement mechanisms to prevent unauthorized access to security-relevant parts of the operating system memory by unauthorized users or subsystems of the operating systems.
* Mitigation: use user identifiers, discretionary access control, or mandatory access control to separate user data and processes
* Test: with the privileges of one user, attempt to read and modify stored private data and process memory owned by another user
* Result: failure to read or modify stored data, failure to access process memory
* Test: from a user account, attempt to read, modify, and execute security-relevant parts of operating system memory that the user is not authorized to access
* Result: failure to access operating systems memory
* Output: error message logged by the test
FIXME should have separate requirement for privileged user still not being able to access kernel memory
#### 5.2.X.x **MI-USEP**: Separation of memory by user account
The manufacturer shall use user identifiers, discretionary access control, or mandatory access control to prevent access of the private in-memory data owned by one user account by different user account.
* Test: with the privileges of one user, attempt to read, modify, and execute process memory owned by another user
* Result: failure to access process memory
* Output: error message logged by the test
* False positive test: read public data owned by another user
Use case: system where only a single user is expected to be logged in at a time
The manufacturer shall implement mechanisms to reject a user account from logging in if a different user account is already logged in.
* Mitigation: reject a user account from logging in if another user is already logged in
* Test: with one user logged in, attempt to log in as a second user
* Result: failure to log in
* Output: error message logged to system log
#### 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.)
#### 5.2.X.x **MI-SPEX** Prevent memory leaks through microarchitectural side channels
* Mitigation: Use MMU to mark memory regions as inaccessible to an executable before scheduling it
* Test: Attempt to read, write, or execute memory in a different memory isolation domain
* Result: error, trap, signal, or kill thread
* Output: executes error handling code or thread is killed
* Requirements: ability to compile and execute code
* Documentation: test source code, instructions to compile, output of error handling or log message for thread kill
The manufacturer shall implement mechanisms to prevent leaking of memory data to unauthorized user through microarchitectural side channels via the observing the time of cache access for the operations:
#### 5.2.X.x **MI-SPEX** Prevent data leak through speculative execution attacks
* branch prediction
* speculative loads/stores
* out-of-order execution
* FIXME more techniques
FIXME fill in
* Test: for each type of operation, write a test that compares the timing difference in the execution of the operation depending on the contents of memory that the test is not authorized to access
* Result: there is no difference reliable enough to deduce the contents of a memory address
* Output: the times measured by the tests
### 5.2.X **TR-OOBM**: Out-of-bounds memory access prevention or mitigation
