With the UEFI 2.3 specification, the contributors recognized that there are lots of devices in the platform that might need their firmware image updated. Add-in cards, embedded controllers, BMCs, and sensor hubs have flash. If they have flash, then they probably want to update the contents of that flash. So the specification allowed each device driver to publish the Firmware Management protocol (chapter 32) which gave the driver a way to publish its ability to handle firmware updates and validate their version and contents. But there was still something lacking: how can an OS application update these flash images in a standard, secure way?
This presentation highlighted the security issues with firmware update of the motherboard or the add-in devices. If you leave the flash device unprotected while the OS is running, malware can attack it. So there must be security. And, if you want updated firmware images to be distributed in such a way that they can be queued for update, there has to be a standard, especially while the OS is running.
If this is true, then there needs to be some way for the OS application to pass back the new firmware image to the pre-OS environment, and then a way for these firmware images to be passed to the correct instance of the Firmware Management protocol.
The UEFI 2.4 specification introduced the Firmware Management capsule. Capsules are buckets of data associated with a type that the OS or OS application can pass back to the system firmware using the UpdateCapsule() runtime service. After a reset (when the flash protection is disabled and control is handed back to the firmware), the capsules are passed to the correct instance of the Firmware Management protocol.
Jeff, Terry and Brian went over this and then highlighted the best practices for using this new capsule type. They also identified three scenarios for capsule update which were all easy to use but which offered varying degrees of security, from good to best.
- Good - In the first scenario, the capsule contains both a UEFI driver and a firmware image. The BIOS validates the UEFI driver and then launches it, expecting it will produce the Firmware Management protocol. The system firmware then passes that instance of the protocol the rest of the capsule payload. The driver's instance of the protocol validates the firmware image and updates the flash image. The add-in card vendor doesn't put the flash and validation logic on the add-in card itself, saving precious ROM space on the card. The system firmware validates the UEFI driver using the normal secure boot mechanism, assuming it is turned on. That is, the card has to depend on the system firmware.
- Better - In the second scenario, the capsule only contains the firmware update payload, but not a UEFI driver. Instead, the add-in card provides the instance of the Firmware Management protocol, which is installed by the UEFI driver that resides on the add-in card. That driver is also validated by the system firmware using the same secure boot criteria, and the UEFI driver on the add-in card performs the validation of the payload before flashing it. This requires more space on the flash device on the add-in card to support this validation and flash code, but it means that the security of the card's flash image is all in the hands of the card without any other help from the BIOS.
- Best - In the third scenario, we have the same situation as the second scenario except that the validation and flash update are done by hardware on the add-in card rather than by the UEFI driver.
Disclaimer: Jeff Bobzin is my co-worker and vice president at Insyde Software.
2 comments:
To be honest I can't say I like the sound of this.
After getting locked out from the bios the users will also be locked out from firmware like the vbios...
While I agree that current option roms are horrible when it comes to security, I can't approve of getting locked out completely from the hardware one buys.
A system that hasn't enabled secure boot should allow for flashing modified firmware, else it will become almost impossible to get rid of ridiculous wlan whitelists, activate locked virtualization features and so on.
Most of the time you don't really know what you get regarding the firmware when you buy a system, and once you have it and realize it's a mess then it's already too late.
All that the UEFI 2.4 standard does is apply the same security measures to the driver inside of the capsule as it does to all other UEFI drivers and applications. So this didn't change this. It was clear that doing the flash under the OS was a huge security hole for all but the most sophisticated plug-in cards.
The UEFI 2.4 standard leaves the actual security policy for validating the actual image to the vendor. That image may not be signed. It is possible that add-in card vendors can provide options to enable/disable their checking. This pushes the "secure boot enable/disable" question out to the next level of firmware.
Post a Comment