I recently came across http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards which reminded me of the world of firmware. Specifically, there is an interplay of de jure standards, such as the UEFI 2.6 specification, and then de facto standards, including open and closed source behaviors.
I'll give a quick example where these two venues collided. Specifically, during the drafting of the UEFI 2.5 specification, there was an operating system request to make the UEFI run time code produced in a way such that the hypervisor or OS could apply page protection. Recall that UEFI runtime code and data are co-located in ring 0 with the OS kernel. This change entailed several things, including the OS making the UEFI run time code read-only and the data pages non-executable. To that end, the EDKII was updated to align the UEFI runtime driver sections on a 4KiB boundary and not merge the code and data pages. In addition, the UEFI memory map was updated to have a memory descriptor for each code and data page, creating several descriptors for each UEFI runtime image, versus the former behavior of having one memory descriptor for the entire set of PE images.
We codified this behavior in UEFI 2.5 with the memory properties table
This bit let the OS know that the code was factored into these separate pages and validated by the firmware producer to be truly pure code and data (e.g., no self-modifying code). This was a de jure UEFI 2.5 specification addition.
What happened? Namely, why did we move to the EFI_MEMORY_ATTRIBUTES_TABLE in UEFI 2.6 and add language to the specification?
After publishing the 2.5 specification and upstreaming patches responsive to this properties table, many OS kernels started to crash. Uh oh.
What we learned was that when OS kernels invoke SetVirtualAddress to map the UEFI runtime entries from a 1:1 pre-OS setting to a non-1:1 OS kernel mapping, the relative distance between entries were not preserved. This didn't appear in earlier implementations since one memory descriptor covered a single image. In fracturing the single descriptor covering the PE image into multiple entries, the un-documented requirement to keep relative offsets between sections of a PE/COFF image during the SetVa call was surfaced. We essentially discovered a de facto requirement to have a single descriptor covering a single PE/COFF image.
Thus the change in the UEFI 2.6 de jure specification to have an 'alternate' table to the UEFI memory map (e.g., EFI_MEMORY_ATTRIBUTES_TABLE) and maintain the single descriptor per image given the circa 1999 and beyond OS's and their SetVa expectations.
This new attributes table is also called out in some OS requirements https://msdn.microsoft.com/windows/hardware/commercialize/design/minimum/device-guard-and-credential-guard.
This doesn't moot the value of the de jure specification, of course. OS and device vendors appreciate standards so that long-term support (LTS) variants of the OS can have an expectation that platforms produced during the support lifetime, such as 10 years, will be compatible. Given the complexity of modern systems, the de jure specification cannot always cover all of the system details. Thus the value of open source and products providing some de facto standardization, too, to complement the formal standard.
Speaking of industry standard firmware and code, I'd also like to let people know that the "Beyond BIOS" book is now available at https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 and https://www.degruyter.com/view/product/484468. Since the original publication in 2006, many things have changed, including scaling of the industry standards efforts, but the basics remain the same. And those areas that have evolved are deftly treated in the updated text.
This book serves as a good launching point for someone just diving into the world of industry standard firmware. I was happy to have the opportunity to work with my old friends and co-authors Mike Rothman and Suresh, along with new friends like Jeffrey, Megan, and others from De Gruyter. De Gruyter also allowed for me to share a sample chapter https://github.com/vincentjzimmer/Documents/blob/master/Beyond_BIOS_3rd_Ed_Chapter-7-9781501505690.pdf, too.
If you have the time please take a look.
And interactions of modern systems don't always behave as expected, too.
You can learn more about the UEFI Shell, which is nicely staged in the picture above, in a update of the UEFI Shell book later this year https://www.degruyter.com/view/product/484477.
I'll give a quick example where these two venues collided. Specifically, during the drafting of the UEFI 2.5 specification, there was an operating system request to make the UEFI run time code produced in a way such that the hypervisor or OS could apply page protection. Recall that UEFI runtime code and data are co-located in ring 0 with the OS kernel. This change entailed several things, including the OS making the UEFI run time code read-only and the data pages non-executable. To that end, the EDKII was updated to align the UEFI runtime driver sections on a 4KiB boundary and not merge the code and data pages. In addition, the UEFI memory map was updated to have a memory descriptor for each code and data page, creating several descriptors for each UEFI runtime image, versus the former behavior of having one memory descriptor for the entire set of PE images.
We codified this behavior in UEFI 2.5 with the memory properties table
This bit let the OS know that the code was factored into these separate pages and validated by the firmware producer to be truly pure code and data (e.g., no self-modifying code). This was a de jure UEFI 2.5 specification addition.
What happened? Namely, why did we move to the EFI_MEMORY_ATTRIBUTES_TABLE in UEFI 2.6 and add language to the specification?
After publishing the 2.5 specification and upstreaming patches responsive to this properties table, many OS kernels started to crash. Uh oh.
What we learned was that when OS kernels invoke SetVirtualAddress to map the UEFI runtime entries from a 1:1 pre-OS setting to a non-1:1 OS kernel mapping, the relative distance between entries were not preserved. This didn't appear in earlier implementations since one memory descriptor covered a single image. In fracturing the single descriptor covering the PE image into multiple entries, the un-documented requirement to keep relative offsets between sections of a PE/COFF image during the SetVa call was surfaced. We essentially discovered a de facto requirement to have a single descriptor covering a single PE/COFF image.
Thus the change in the UEFI 2.6 de jure specification to have an 'alternate' table to the UEFI memory map (e.g., EFI_MEMORY_ATTRIBUTES_TABLE) and maintain the single descriptor per image given the circa 1999 and beyond OS's and their SetVa expectations.
This new attributes table is also called out in some OS requirements https://msdn.microsoft.com/windows/hardware/commercialize/design/minimum/device-guard-and-credential-guard.
Speaking of industry standard firmware and code, I'd also like to let people know that the "Beyond BIOS" book is now available at https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 and https://www.degruyter.com/view/product/484468. Since the original publication in 2006, many things have changed, including scaling of the industry standards efforts, but the basics remain the same. And those areas that have evolved are deftly treated in the updated text.
This book serves as a good launching point for someone just diving into the world of industry standard firmware. I was happy to have the opportunity to work with my old friends and co-authors Mike Rothman and Suresh, along with new friends like Jeffrey, Megan, and others from De Gruyter. De Gruyter also allowed for me to share a sample chapter https://github.com/vincentjzimmer/Documents/blob/master/Beyond_BIOS_3rd_Ed_Chapter-7-9781501505690.pdf, too.
If you have the time please take a look.
And interactions of modern systems don't always behave as expected, too.
You can learn more about the UEFI Shell, which is nicely staged in the picture above, in a update of the UEFI Shell book later this year https://www.degruyter.com/view/product/484477.
No comments:
Post a Comment