@@ -932,7 +932,7 @@ Each mitigation is described with the following fields where necessary:
### 5.2.X **TR-TOUT**: Test output
The manufacturer shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable format on the product as placed on the market. The manufacturer shall document the steps necessary to enable testing and collection of the test output. The manufacturer shall not add unnecessary barriers to activating and collecting test output by MSAs.
The operating system shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable format on the product as placed on the market. The manufacturer shall document the steps necessary to enable testing and collection of the test output. The manufacturer shall not add unnecessary barriers to activating and collecting test output by MSAs.
Test: Follow the instructions to set up testing, run one test for a technical requirement that produces test output, and collect the output
Result: Test output matches expected output for that test
@@ -943,7 +943,7 @@ For any technical requirement which includes a test, the manufacturer shall docu
### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data
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.
The operating system 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.
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.
@@ -958,7 +958,7 @@ The manufacturer shall check all security-relevant parts of the operating system
* 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.
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 reasonably foreseeable use or misuse.
* 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
@@ -969,7 +969,7 @@ All warnings, annotations, or other method of suppressing warnings from the anal
The manufacturer shall implement MI-SSCA.
The manufacturer shall implement mechanisms to prevent unauthorized access to the memory used by security-relevant parts of the operating system. The manufacturer shall use user identifiers, discretionary access control, or mandatory access control to prevent unauthorized access of memory owned by user accounts by other user accounts.
The operating system shall implement mechanisms to prevent unauthorized access to the memory used by security-relevant parts of the operating system. The operating system shall use user identifiers, discretionary access control, or mandatory access control to prevent unauthorized access of memory owned by user accounts by other user accounts.
* 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 in this way
* Result: failure to access memory
@@ -979,30 +979,49 @@ The manufacturer shall implement mechanisms to prevent unauthorized access to th
#### 5.2.X.x **MI-CCON**: Prevent creation of more than one user account
The manufacturer shall implement MI-SCCA and MI-MMAC.
The manufacturer shall implement MI-SCCA.
The manufacturer shall implement mechanisms to reject a user account from logging in if a different user account is already logged in.
The operating system shall implement mechanisms to prevent the creation of a user account if one already exists.
* Test: create one user account, then attempt to create a second
* Result: first user account creation succeeds, second fails
* Output: error message
#### 5.2.X.x **MI-UCON**: Prevent concurrent user account usage
The manufacturer shall implement MI-SCCA.
The operating system shall implement MI-MMAC.
The operating system shall implement mechanisms to reject a user account from logging in if a different user account 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
* Output: error message
#### 5.2.X.x **MI-SPEX** Prevent memory leaks through microarchitectural side channels
#### 5.2.X.x **MI-PMSC** Prevent memory leaks through microarchitectural side channels in provided executables
The manufacturer shall implement MI-USEP.
The operating system shall implement MI-MMAC.
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:
The operating system shall implement mechanisms to prevent the executables it provides from leaking memory data to unauthorized users through known exploitable microarchitectural side channels (MASCs), such as via the observing the time of cache access for the operations:
* branch prediction
* speculative loads/stores
* out-of-order execution
* FIXME more techniques
* 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
The manufacturer shall document on which platforms the operating system mitigates known MASC leaks.
* Test: for each type of known MASC leak on each supported platform, run a test that detects if an unprivileged user can use the MASC leak to gain unauthorized access to data in memory from security-relevant executables
* Result: tests report that MASC leak can not be used in this way
* Output: the times measured by the tests
* Documentation: list of known exploitable MASCs in each supported platform
#### 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.
#### 5.2.X.x Mapping of mitigations to risk factors
@@ -1013,11 +1032,15 @@ Mitigations satisfy technical requirements only under when they mitigate the rel
| None | All risk factors are 0 |
| SSCA | CUSR = 0 & SWMD = 0 |
| MMAC | CUSR <= 2 & SWMD <= 2 |
| CCON | CUSR <= 1 |
| UCON | CUSR <= 1 |
| SPEX | any |
| TRMD | ADMN <= 1 |
| PMSC | any |
FIXME change the above mapping to be based on a combination of likelihood and impact
FIXME add MMAC being okay with CUSR 3 and low impact
#### 5.2.X.x Mapping of mitigations to security profiles
| Mitigation | Security profiles it applies to |
@@ -1026,9 +1049,9 @@ FIXME change the above mapping to be based on a combination of likelihood and im
