Author: AppaRao Puli
Other contributors: None
Created: 2019-09-12
The platform is a collection of fundamental hardware and firmware components needed to boot and operate a system. The Platform Firmware Resiliency(PFR) in NIST SP 800-193 provides technical guidelines and recommendations supporting resiliency of platform firmware and data against potentially destructive attacks.
Currently Redfish schema's defined by DMTF doesn't cover properties or resources to represent the PFR provisioned and locked states.
This document covers the new OEM properties under ComputerSystem resource to represent the PFR provisioning status such as platform firmware is provisioned or not as well as provisioning is locked or not. This also covers the Redfish OpenBMC message registry metadata for logging events associated with PFR.
Platform Firmware Resilience technology in NIST SP 800-93 provide common guidelines to implementers, including Original Equipment Manufacturers (OEMs) and component/device suppliers, to build stronger security mechanisms into platforms. Server platforms consist of multiple devices which must provide resiliency by protecting, detecting and recovering platform assets. Management controller running on server platform can be used to indicate the status of resiliency and event logs associated with it.
High level requirements:
BMC shall provide the way to represent Platform Firmware Resilience provisioning status over Redfish.
Event logs should be logged to redfish for Platform Firmware Resilience.
Different OEM's has there own way of implementing the Platform Firmware Resilience by using guidelines provided by NIST SP 800-193. Some of the component protected under this includes(not limited) ES/SIO, BMC/ME Flash, Host Processors, Trusted Platform Modules(TPM), PSU's, Memory etc... For example Intel uses the "Intel PFR" design to resiliency platform components.
NOTE: This document doesn't cover design aspects of how OEM's implements the Platform Firmware Resilience. It covers only generic redfish ComputerSystem OEM properties and Redfish message registry metadata entries which are implementation agnostic.
OpenBMC is moving to Redfish as its standard for out of band management. The bmcweb implements all the Redfish schema's to represent different properties and resources. ComputerSystem schema doesn't cover the properties associated with Platform Firmware Resilience but it provides OEM objects for manufacturer/provider specific extension moniker.
Below are property is defined to represent the Platform Firmware Resilience provisioning status.
ProvisiongStatus: The value of this property indicates the provisioning status of platform firmware. It is of Enum Type with below values.
NotProvisioned: Indicates platform firmware is not provisioned. This is an unsecured state.
ProvisionedButNotLocked: Indicates that the platform firmware is provisioned but not locked. So re-provisioning is allowed in this state.
ProvisionedAndLocked: Indicates that the platform firmware is provisioned and locked. So re-provisioning is not allowed in this state.
PFR enabled platforms can provision or re-provision the platform resilience multiple times when it is in "NotProvisioned" or "ProvisionedButNotLocked" states. But once the platform is transitioned to "ProvisionedAndLocked" state, it can not be re-provisioned.
New OemComputerSystem schema can be found at link
PFR in OpenBMC must support logging of resiliency error detection and correction. Below are two metadata entries in redfish message registry for redfish event logging capability. For more details on how to log redfish events can be found at document Redfish logging in bmcweb .
Below type of events should be logged as part of PFR or provisioning. These redfish events are created for basic firmware components BIOS, BMC, CPLD and ME and must be extended whenever new firmware modules are supported under PFR.
Platform Firmware Resiliency Errors: This is used to log the platform firmware resiliency errors.
MessageID's:
Below are some cases, where firmware resiliency error events logged for specific components.
Platform Firmware Panic reason: This is used to log the reason for platform firmware panic.
MessageID's:
Below are some cases, where these events can be logged.
Platform Firmware Recovery reasons: This is used to log the reason for last platform firmware component recovery.
MessageID's:
Below are few cases, where these events can be logged.
Event logs associated with BMC component is specified here as example.
MessageEntry{"BMCFirmwareResiliencyError",
{
"Indicates BMC firmware encountered resilience error",
"BMC firmware resiliency error. Error reason: %1.",
"Critical",
1,
{
"string",
},
"None.",
}},
MessageEntry{"BMCFirmwarePanicReason",
{
"Indicates the reason for last BMC firmware panic.",
"BMC firmware panic occurred due to %1.",
"Warning",
1,
{
"string",
},
"None.",
}},
MessageEntry{"BMCFirmwareRecoveryReason",
{
"Indicates the reason for last BMC firmware recovery.",
"BMC firmware recovery occurred due to %1.",
"Warning",
1,
{
"string",
},
"None.",
}},
None
None
Provisiong status:
URI: /redfish/v1/Systems/system
METHOD: GET
RESPONSE:
{
"@odata.context": "/redfish/v1/$metadata#ComputerSystem.ComputerSystem",
"@odata.id": "/redfish/v1/Systems/system",
"@odata.type": "#ComputerSystem.v1_6_0.ComputerSystem",
...................
...................
"Description": "Computer System",
"Oem": {
"OpenBmc": {
"FirmwareProvisioning": {
"ProvisioningStatus": "NotProvisioned"
}
}
},
...................
...................
}
Event logs:
User can induce security attack and validate the panic event logs as well as recovery mechanism using below URI.
Few examples to attack Firmware components and validate PFR:
Corrupt the BMC/BIOS etc... firmware and check Panic events and recovery actions events.
Induce hardware watchdog trigger using known methods and check. etc..
Corrupt the security key's by directly mocking hardware and validate.
URI: /redfish/v1/Systems/system/LogServices/EventLog/Entries METHOD: GET