@@ -791,15 +791,13 @@ If automatable and freely-usable vulnerability scanners are available for the pr
See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data
### 5.2.2 TR-SSDD: Secure design and development
#### 5.2.X.x Requirement
#### 5.2.2.1 Requirement
The product shall protect memory addresses from unauthorized access by executables under the product's control, including the product 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 product 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.
The product shall be designed and developed in a secure manner.
#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory errors
#### 5.2.2.2 MI-SSCA: Static source code analysis for memory errors
All security-relevant parts of the product shall be checked for memory errors using a source code analysis tool that detects code that may produce common memory errors, such as:
@@ -814,9 +812,9 @@ The sufficiency of the source code analysis tool and the selected manner of runn
All warnings, annotations, or other method of suppressing warnings from the analysis tool shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Reference: TR-MISO, FIXME others
* Reference: TR-SSDD
* Objective: Prevent or mitigate unauthorize memory access
* Objective: Prevent unauthorized memory access
* Preparation: None
@@ -826,6 +824,63 @@ All warnings, annotations, or other method of suppressing warnings from the anal
* Evidence: The documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings
The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment that permits measuring code coverage and detecting memory access errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Reference: TR-SSDD
* Objective: Prevent unauthorized memory access
* Preparation: None
* Activities: Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached
* Verdict: Code coverage was at least 95%, all reported memory errors are documented and justified => PASS, otherwise FAIL
* Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors
#### 5.2.2.4 MI-IMSL Implement in a memory-safe language
The product's firmware and/or software shall be implemented in a memory-safe language. Any use of unsafe memory features shall be documented to explain why they are necessary and do not present a security risk.
* Reference: TR-SSDD, TR-MSAF
* Objective: Prevent unauthorized memory access
* Preparation: None
* Activities: Review source code to determine its language and what exceptions to memory safety exist
* Verdict: Source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a security risk => PASS, otherwise FAIL
* Evidence: Source code, documentation of unsafe memory features
#### 5.2.2.5 MI-BTIN Boundary testing of inputs that may cause memory errors
The input fields of the product that may produce memory errors in the firmware or device driver shall be identified. The product shall be boundary tested for all such inputs while monitoring for memory errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.
* Reference: TR-SSDD, TR-MSAF
* Objective: Prevent unauthorized memory access
* Preparation: Identify input fields in the product that may produce memory errors
* Activities: Run a tool that tests input values that test the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors
* Verdict: All boundary values tested and all memory errors detected are documented and justified => PASS, otherwise FAIL
* Evidence: Logs of boundary testing tool, memory error report, documentation of any memory errors
#### 5.2.2.6 MI-SCFS: Secure compilation flags
All security-relevant firmware and software shall be compiled with secure compilation flags and options appropriate to the target platform and language. All compilation flags used shall be documented as to their rationale, along with any exceptions or limitations. Any exceptions to the flags or warnings shall be documented as to why they do not create an unacceptable risk.
* Applicability: Product implemented in a compiled language
* Reference: TR-SDDV
* Objective: Secure design and development
* Preparation: Document which flags should be used
* Activities: Review compilation flags, warnings, and documentation for exceptions
* Verdict: Documentation of flags exists, all warnings and exceptions are documented
* Evidence: Documentation of flags, build system files, documentation of warnings and exceptions
#### 5.2.2.7 Mapping of mitigations to risk factors and security profiles
See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data
#### 5.2.X.x Requirement
The product shall protect memory addresses from unauthorized access by executables under the product's control, including the product 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 product 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-MMAC**: Memory access control
The product shall implement mandatory hardware-enforced access control to memory to prevent unauthorized access of memory.
