1# Redfish resource supplement for Platform Firmware Resilience (PFR) 2 3Author: AppaRao Puli 4 5Primary assignee: AppaRao Puli !apuli 6 7Other contributors: None 8 9Created: 2019-09-12 10 11## Problem description 12 13The platform is a collection of fundamental hardware and firmware components 14needed to boot and operate a system. The Platform Firmware Resiliency(PFR) 15in NIST SP 800-193 provides technical guidelines and recommendations 16supporting resiliency of platform firmware and data against potentially 17destructive attacks. 18 19Currently Redfish schema's defined by DMTF doesn't cover properties or 20resources to represent the PFR provisioned and locked states. 21 22This document covers the new OEM properties under ComputerSystem resource 23to represent the PFR provisioning status such as platform firmware is 24provisioned or not as well as provisioning is locked or not. This also covers 25the Redfish OpenBMC message registry metadata for logging events associated 26with PFR. 27 28## Background and references 29 30Platform Firmware Resilience technology in NIST SP 800-93 provide common 31guidelines to implementers, including Original Equipment Manufacturers (OEMs) 32and component/device suppliers, to build stronger security mechanisms into 33platforms. Server platforms consist of multiple devices which must provide 34resiliency by protecting, detecting and recovering platform assets. Management 35controller running on server platform can be used to indicate the status of 36resiliency and event logs associated with it. 37 38 - [NIST.SP.180-193](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf) 39 - [Redfish schema supplement](https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2019.1a.pdf) 40 - [Redfish Logging in bmcweb](https://github.com/openbmc/docs/blob/master/redfish-logging-in-bmcweb.md) 41 42## Requirements 43 44High level requirements: 45 46 - BMC shall provide the way to represent Platform Firmware Resilience 47 provisioning status over Redfish. 48 49 - Event logs should be logged to redfish for Platform Firmware Resilience. 50 51## Proposed design 52 53Different OEM's has there own way of implementing the Platform Firmware 54Resilience by using guidelines provided by NIST SP 800-193. Some of the 55component protected under this includes(not limited) ES/SIO, BMC/ME Flash, 56Host Processors, Trusted Platform Modules(TPM), PSU's, Memory etc... 57For example Intel uses the "Intel PFR" design to resiliency platform 58components. 59 60NOTE: This document doesn't cover design aspects of how OEM's implements 61the Platform Firmware Resilience. It covers only generic redfish ComputerSystem 62OEM properties and Redfish message registry metadata entries which are 63implementation agnostic. 64 65OpenBMC is moving to Redfish as its standard for out of band management. 66The bmcweb implements all the Redfish schema's to represent different 67properties and resources. ComputerSystem schema doesn't cover the properties 68associated with Platform Firmware Resilience but it provides OEM objects for 69manufacturer/provider specific extension moniker. 70 71Below are property is defined to represent the Platform Firmware 72Resilience provisioning status. 73 74 - ProvisiongStatus: The value of this property indicates the provisioning 75 status of platform firmware. It is of Enum Type with below values. 76 77 1) NotProvisioned: Indicates platform firmware is not provisioned. 78 This is an unsecured state. 79 80 2) ProvisionedButNotLocked: Indicates that the platform firmware is 81 provisioned but not locked. So re-provisioning is allowed in this 82 state. 83 84 3) ProvisionedAndLocked: Indicates that the platform firmware is 85 provisioned and locked. So re-provisioning is not allowed in this 86 state. 87 88PFR enabled platforms can provision or re-provision the platform resilience 89multiple times when it is in "NotProvisioned" or "ProvisionedButNotLocked" 90states. But once the platform is transitioned to "ProvisionedAndLocked" state, 91it can not be re-provisioned. 92 93New OemComputerSystem schema can be found at 94[link](https://gerrit.openbmc-project.xyz/#/c/openbmc/bmcweb/+/24253/) 95 96PFR in OpenBMC must support logging of resiliency error detection and 97correction. Below are two metadata entries in redfish message registry 98for redfish event logging capability. For more details on how to log redfish 99events can be found at document [Redfish logging in bmcweb 100](https://github.com/openbmc/docs/blob/master/redfish-logging-in-bmcweb.md). 101 102 103``` 104MessageEntry{ 105 "PlatformFirmwareError", 106 { 107 .description = "Indicates that the specific error occurred in " 108 "platform firmware.", 109 .message = "Error occurred in platform firmware. ErrorCode=%1", 110 .severity = "Critical", 111 .numberOfArgs = 1, 112 .paramTypes = {"string"}, 113 .resolution = "None.", 114 }}, 115 MessageEntry{ 116 "PlatformFirmwareEvent", 117 { 118 .description = "Indicates that the platform firmware events like " 119 "panic or recovery occurred for the specified " 120 "reason.", 121 .message = "Platform firmware %1 event triggered due to %2.", 122 .severity = "Critical", 123 .numberOfArgs = 2, 124 .paramTypes = {"string", "string"}, 125 .resolution = "None.", 126 }}, 127``` 128 129 130## Alternatives considered 131 132None 133 134## Impacts 135 136None 137 138## Testing 139 140Provisiong status: 141 142 - User can provision the PFR in OEM specific way and test using below URI 143 and Method. Intel uses "Intel PFR" design (via BIOS) to provision and 144 lock the PFR provisioning status. 145``` 146URI: /redfish/v1/Systems/system 147METHOD: GET 148RESPONSE: 149 150{ 151 "@odata.context": "/redfish/v1/$metadata#ComputerSystem.ComputerSystem", 152 "@odata.id": "/redfish/v1/Systems/system", 153 "@odata.type": "#ComputerSystem.v1_6_0.ComputerSystem", 154 ................... 155 ................... 156 "Description": "Computer System", 157 "Oem": { 158 "OpenBmc": { 159 "FirmwareProvisioning": { 160 "ProvisioningStatus": "NotProvisioned" 161 } 162 } 163 }, 164 ................... 165 ................... 166} 167``` 168 169Event logs: 170 171 - User can induce security attack and validate the panic event logs as well as 172 recovery mechanism using below URI. 173 174 Few examples to attack Firmware components and validate PFR: 175 176 1) Corrupt the BMC/BIOS etc... firmware and check Panic events and recovery 177 actions events. 178 179 2) Induce hardware watchdog trigger using known methods and check. 180 etc.. 181 182 3) Corrupt the security key's by directly mocking hardware and validate. 183 184``` 185URI: /redfish/v1/Systems/system/LogServices/EventLog/Entries 186METHOD: GET 187``` 188