During the latest UEFI Forum webinar, “The Role of Redfish in UEFI Forum Firmware Specifications,” panelists provided an overview of DMTF’s Redfish®, discussed implementation challenges, and explained how Redfish and UEFI platform firmware interact. In the Q&A following the webinar, panelists answered questions regarding a variety of topics, but weren’t able to get to all the questions in the time we had available. The questions below were asked by webinar attendees and are now answered by the presentation’s panelists.
Q: DSP0270 was mentioned as a means of a Redfish-enabled protocol between BMC and the host. How is DSP0218 used to implement communication over PLDM? Is this a common option?
A: DSP0270 defines a Redfish Host Interface, allowing access to Redfish service from the host (UEFI/FW, or OS). DSP0270 currently defines three paths:
- USB based network connection (HTTP(s)s over IPv4/IPv6 over USB Ethernet device).
- PCI based network connection (HTTP(s) over IPv4/IPv6 over PCI Ethernet device)
- OEM proprietary interface: The specification only defines an “OEM” type but leaves the details to implementation. This could be anything as long as the BMC/UEFI/OS drivers exist to establish this communication.
There is currently no PLDM (over MCTP) based path defined for Redfish Host Interface communication between the BMC and the host.
Q: Is there an example working model or sample implementation of redfish -> UEFI?
A: This code is currently in community preview stage, and the TianoCore community is looking for feedback on the implementation. For more details, please refer slides 4 – 7 in this UEFI Forum presentation.
Q: What is the mapping between the boot override and the boot options?
A: Boot override does not map to a particular boot option since boot override uses an alias. The boot option resources do specify an alias, but the override does not allow for enumeration of multiple devices with the same alias. The boot device determination in the event of multiple device type aliases is implementation specific. If a targeted override is desired, the user would utilize the UEFI target type override and specify the exact UEFI device path for the desired target boot device.
Q: Is there a method to prevent unauthorized actors from accessing a system via Redfish if they gain access to the configuration subnet on which the BMC resides?
A: Redfish access is controlled via the BMC (or Manager) account security. To gain access, users must login to the Redfish service (using either an HTTP Basic Authentication, or a Session Based Authentication) with a valid BMC account that has sufficient privilege for that operation. Each resource in Redfish may require its own privilege (for reading or writing) and the service enforces the access control. A BMC admin with high privilege can configure the user accounts and their privileges. In addition, all communication with Redfish service can be over an HTTPS/TLS encrypted link. All users of HW containing a BMC should ensure that they update all default usernames and passwords upon receiving hardware. Updated account information is the simplest way to ensure your system remains uncompromised.
Q: For BIOS configuration, is there existing code for automatic conversion from VFR to a JSON schema, to allow programmatically reproducing BIOS setup remotely?
A: This implementation will convert HII questions flagged as REST style into BIOS registry attributes, but it does not create the menu section of the registry. This code is currently in community preview stage, and the TianoCore community is looking for feedback on the implementation. For more details, please refer to slides 4 – 7 in the UEFI presentation.
The page layout is an important part of the setup infrastructure and can be implemented via a custom attribute registry on top of what the default EDKII implementation does. The current Redfish specification does not cover the exact page the questions reside on. This can cause confusion for questions that appear more than once for when a device appears more than once like PCIe port setting. Adding the additional custom attributes is easily done but is currently out of scope for the specification. We encourage Redfish consumers to become active in the specification workgroups to help define what additional needs they have.
Q: Is there a provision to allow a boot-only variation of Redfish with a standard NIC for things like enterprise client system configuration? For example, can the BIOS initiate an HTTPS transaction to give a configuration server a chance to update the redfish registry in place of a BMC?
A: It is conceivable that the Redfish Service could be remote, and that BIOS can perform HTTPS transactions to the remote service. The Redfish Host Interface specification defines a network device for host access to the Redfish Service. Many implementations available on industry servers today use a private NIC connection to the BMC as the Redfish Host Interface. However, if the Redfish Host Interface was configured as a NIC connected to an external network, then host software (including UEFI), would use this device to communicate with an external Redfish Service.
Q: Sometimes while implementing Redfish, I find it difficult to map where should I place detailed information about something, like Baseboard or Motherboard info. Should I use the Assembly schema under Chassis and specify the physical context to SystemBoard or specify a separated schema inside OEM on a computer system for example?
A: A general rule is to try to stick to standard Redfish schema, defined by DMTF, as much as possible. The schema are defined at: https://redfish.dmtf.org/redfish/schema_index. Avoid using an OEM schema unless the standard’s schema does not provide the necessary functionality. When in need of help while interpreting schema or figuring out how to map data to schema and properties, a good resource to use is the Redfish Forum at: https://www.redfishforum.com/. These questions get looked at on a weekly basis by the DMTF Redfish working group and are answered promptly.
Q: How is Redfish expected to be used with Rack Manager in a data center environment?
A: The Redfish architecture is defined to allow flexibility of the hardware that is being managed, be it a single compute node, storage node, or an entire rack of nodes, etc. The abstraction allows for “Chassis” resources to represent the various physical Chassis components of the managed systems, including complex topologies such as nodes, racks, blades, or even an entire data center. For Rack Manager, the Open Compute Project has a project called OpenRMC to implement a Redfish based north API for Rack Managers. There are also other commercial and open source implementations of Rack Manager type functionality that are Redfish-based.
Q: Redfish seems to have a server focus, but what about clients that don't have BMC? It is unclear how they implement Redfish.
A: Redfish is a manageability interface specification. Generally, server platforms have had a BMC for hosting remote manageability. Client platforms can choose which processor or controller hosts the Redfish interface.
Q: Will HTTPS GET operations for getting BIOS attributes fail during system boot up (when data exchange is in progress)?
A: This is implementation-specific. It is possible that some implementations will have this effect, in which case the Redfish service should return an HTTP error, and an Extended Error Message, indicating that the resource is not available or that the service is busy. It is also possible for implementations to still provide a cached copy of the BIOS Attributes on a GET (from previous BIOS/BMC sync). Implementations should attempt to keep service downtime to a minimum to ensure best usage.
Q: Is there any plan for Redfish to expand its playground, i.e. from Intel to non-Intel server platforms? Has there already been some progress?
A: Redfish is an implementation agnostic industry interface standard. Since its release in 2015, the Redfish model has been extended to manage storage platforms, data center facilities equipment and manufacturing process automation components. Redfish models started in the server space, so those implementations are most prevalent.
Thank you to our webinar attendees for asking these insightful questions. For answers to any other UEFI Forum-related questions, visit our website for more resources: https://uefi.org/