summaryrefslogtreecommitdiffstats
path: root/src/interface/efi
diff options
context:
space:
mode:
authorMichael Brown2016-04-12 12:59:31 +0200
committerMichael Brown2016-04-12 13:24:14 +0200
commit5238c85b623200fa0f44a46db93965080053f745 (patch)
treea7690b98c00cacca8c4a2030cecaacf4451077e5 /src/interface/efi
parent[libc] Print "<NULL>" for wide-character NULL strings (diff)
downloadipxe-5238c85b623200fa0f44a46db93965080053f745.tar.gz
ipxe-5238c85b623200fa0f44a46db93965080053f745.tar.xz
ipxe-5238c85b623200fa0f44a46db93965080053f745.zip
[efi] Work around broken EFI HII specification
The EFI_HII_CONFIG_ACCESS_PROTOCOL's ExtractConfig() method is passed a request string which includes the parameters being queried plus an apparently meaningless blob of information (the ConfigHdr), and is expected to include this same meaningless blob of information in the results string. Neither the specification nor the existing EDK2 code (including the nominal reference implementation in the DriverSampleDxe driver) provide any reason for the existence of this meaningless blob of information. It appears to be consumed in its entirety by the EFI_HII_CONFIG_ROUTING_PROTOCOL, and to contain zero bits of information by the time it reaches an EFI_HII_CONFIG_ACCESS_PROTOCOL instance. It would potentially allow for multiple configuration data sets to be handled by a single EFI_HII_CONFIG_ACCESS_PROTOCOL instance, in a style alien to the rest of the UEFI specification (which implicitly assumes that the instance pointer is always sufficient to uniquely identify the instance). iPXE currently handles this by simply copying the ConfigHdr from the request string to the results string, and otherwise ignoring it. This approach is also used by some code in EDK2, such as OVMF's PlatformDxe driver. As of EDK2 commit 8a45f80 ("MdeModulePkg: Make HII configuration settings available to OS runtime"), this causes an assertion failure inside EDK2. The failure arises when iPXE is handled a NULL request string, and responds (as per the specification) with a results string including all settings. Since there is no meaningless blob to copy from the request string, there is no corresponding meaningless blob in the results string. This now causes an assertion failure in HiiDatabaseDxe's HiiConfigRoutingExportConfig(). The same failure does not affect the OVMF PlatformDxe driver, which simply passes the request string to the HII BlockToConfig() utility function. The BlockToConfig() function returns EFI_INVALID_PARAMETER when passed a null request string, and PlatformDxe propagates this error directly to the caller. Fix by matching the behaviour of OVMF's PlatformDxe driver: explicitly return EFI_INVALID_PARAMETER if the request string is NULL or empty. This violates the specification (insofar as it is feasible to determine what the specification actually requires), but causes correct behaviour with the EDK2 codebase. Signed-off-by: Michael Brown <mcb30@ipxe.org>
Diffstat (limited to 'src/interface/efi')
-rw-r--r--src/interface/efi/efi_snp_hii.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/src/interface/efi/efi_snp_hii.c b/src/interface/efi/efi_snp_hii.c
index 720402bd..1e87ea15 100644
--- a/src/interface/efi/efi_snp_hii.c
+++ b/src/interface/efi/efi_snp_hii.c
@@ -546,6 +546,13 @@ efi_snp_hii_extract_config ( const EFI_HII_CONFIG_ACCESS_PROTOCOL *hii,
/* Initialise results */
*results = NULL;
+ /* Work around apparently broken UEFI specification */
+ if ( ! ( request && request[0] ) ) {
+ DBGC ( snpdev, "SNPDEV %p ExtractConfig ignoring malformed "
+ "request\n", snpdev );
+ return EFI_INVALID_PARAMETER;
+ }
+
/* Process all request fragments */
for ( pos = *progress = request ; *progress && **progress ;
pos = *progress + 1 ) {