You may have noticed the recent posting on the EDKII mailing list https://www.mail-archive.com/edk2-devel@lists.01.org/msg06031.html about HII export. The mail questions the utility of exporting this information, especially when you cannot easily set the value. So this begs the question - 'what is HII?'
There is already great material on the web about HII, including http://uefi.blogspot.com/2009/09/uefi-hii-part-1.html, http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2011Q4_P4_Intel.pdf, https://www.youtube.com/watch?v=11PIctg6pz8, so I won't attempt to repeat those discourses.
Instead, I'll provide a quick background and why it's of interest to OS run times and management stacks. HII stands for "Human Interface Infrastructure." This was originally a set of Intel Framework technology specification http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf for managing the platform setup. It consists of a database of settings and forms. The forms have a list of questions and an associated setting. HII moved into the UEFI specification when it was observed that 3rd party UEFI drivers might publish forms to support the configuration of their respective devices.
My office neighbor here in Seattle Mike Rothman
authored much of the specification in this area, including how the HII database can be exported to the operating system runtime [from UEFI 2.6 http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf]
The left side of the figure shows the pre-OS usage of the information, such as a PC's 'setup/browser' application. The right hand side shows how this information can be ascertained via a pointer in the EFI_SYSTEM_TABLE to view the information at runtime. It is this 'export' behavior, a requiremetn of the UEFI specification, that the mailing list patch at the top wanted to make optional via the firmware build.
The strings are interesting, but today the questions are vendor-board specific. To provide additional utility, having the questions and settings normalized across a larger class of devices was pursued. As described in section 3 of https://firmware.intel.com/sites/default/files/resources/uefi-manageability-security-white-paper.pdf:
"OEMs typically have their own keywords and namespaces that they use when interacting with target platforms. Given that, a standard method to interact with a target platform might be one which leverages the syntax established by DMTF’s SMASH CLP [3]. The typical CIM_BIOSAttribute associated with CLP expresses configuration data by using a “:”
syntax.
Given the previous example, one can imagine that a
UEFI-based syntax could be expressed by having the xi-UEFI
language equivalent value replace the
value and the value would be UEFI"
The The x-UEFI configuration language is now a reality. The latest keywords can now be found at http://uefi.org/confignamespace. This list should grow over time as more configuration data emerges based upon new platform technologies, features in the UEFI and other industry standards, etc.
This type of facility helps provide infrastructure to provide visibility into 'Is Features XYZ enabled." A common instance of this is virtualization technology, hyper threading, and other art managed by the platform.
Going forward, I can imagine OS viewer utilities, maybe /dev/hii in Linux and an associated Microsoft Windows interface, to exposing this information. The EDKII community on tianocore.org ought to investigate some simple shell applications to export the information, too.
There is already great material on the web about HII, including http://uefi.blogspot.com/2009/09/uefi-hii-part-1.html, http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2011Q4_P4_Intel.pdf, https://www.youtube.com/watch?v=11PIctg6pz8, so I won't attempt to repeat those discourses.
Instead, I'll provide a quick background and why it's of interest to OS run times and management stacks. HII stands for "Human Interface Infrastructure." This was originally a set of Intel Framework technology specification http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf for managing the platform setup. It consists of a database of settings and forms. The forms have a list of questions and an associated setting. HII moved into the UEFI specification when it was observed that 3rd party UEFI drivers might publish forms to support the configuration of their respective devices.
My office neighbor here in Seattle Mike Rothman
authored much of the specification in this area, including how the HII database can be exported to the operating system runtime [from UEFI 2.6 http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf]
The left side of the figure shows the pre-OS usage of the information, such as a PC's 'setup/browser' application. The right hand side shows how this information can be ascertained via a pointer in the EFI_SYSTEM_TABLE to view the information at runtime. It is this 'export' behavior, a requiremetn of the UEFI specification, that the mailing list patch at the top wanted to make optional via the firmware build.
The strings are interesting, but today the questions are vendor-board specific. To provide additional utility, having the questions and settings normalized across a larger class of devices was pursued. As described in section 3 of https://firmware.intel.com/sites/default/files/resources/uefi-manageability-security-white-paper.pdf:
"OEMs typically have their own keywords and namespaces that they use when interacting with target platforms. Given that, a standard method to interact with a target platform might be one which leverages the syntax established by DMTF’s SMASH CLP [3]. The typical CIM_BIOSAttribute associated with CLP expresses configuration data by using a “
This type of facility helps provide infrastructure to provide visibility into 'Is Features XYZ enabled." A common instance of this is virtualization technology, hyper threading, and other art managed by the platform.
No comments:
Post a Comment