[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>

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 ) {