BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

4.2.3 Runtime Protection of Critical Platform Firmware

NIST platform security: roots of trust, firmware and secure enclaves SP 800-193
All changes in this version
first version loaded 4 Firmware Security Guidelines for Platform Devices part of 4.2

Title

Runtime Protection of Critical Platform Firmware

Control

To satisfy the principle of non-bypassability described in Section 4.2.1.3 , it is important that software or bus-mastering hardware under the control of software not be capable of interfering with the intended function of Critical Platform Firmware . Critical Platform Firmware is the collection of all Platform Firmware that either (a) performs the functions of protection, detection, recovery and update of any Platform Firmware, (b) maintains the security of critical data or (c) implements interfaces for critical data that are non-bypassable.

Devices that claim conformance with the Protection requirements, and rely on critical platform firmware to protect the firmware image and/or critical data at OS runtime, must meet the guidelines in this subsection. The goal of these guidelines is to establish an environment for critical platform firmware to execute in which it is isolated (protected) from software. Such isolation (protection) may be provided either logically (e.g., use of System Management Mode in x86-based platforms, or TrustZone in ARM-based platforms), or physically (e.g. in RAM attached to a non-host processor which is physically or logically isolated from the host processor).

This subsection does not necessarily apply to firmware that is classified as non-critical (for instance, the majority of the BIOS on a PC-style platform is typically non-critical).

1) If Critical Platform Firmware code in non-volatile memory is copied into RAM to be executed (for performance, or for other reasons) then the firmware program in RAM shall be protected from modification by software or shall complete its function before software starts. 2) If Critical Platform Firmware uses RAM for temporary data storage, then this memory shall be protected from software running on the Platform until the data’s use is complete. 3) Software shall not be able to interfere with the intended function of Critical Platform Firmware. For example, by denying execution, modifying the processor mode, or polluting caches. Note: These guidelines do not preclude the use of RAM that is writable by software specifically for communication with Firmware or device hardware, including using memory as a staging area for updates. The guidelines are intended to prevent the unauthorized modification of executing code or private state used by Critical Platform Firmware.