[if gte mso 9]>
Subject: Re: [edk2] Loading different HII images from OptionROM
From: "Prakash, Sathya" <Sathya.Prakash@lsi.com>
To: "firstname.lastname@example.org" <email@example.com>
Date: 2013-03-08 22:23:46
#1. I couldn’t understand what do you mane by “part of the image that gets measured by the firmware”. The plan is to keep the image in a controller’s flash part known to our controller firmware (not host firmware) only and make controller specific calls from the BSD (the one which is getting enumerated by system firmware) to read the image into a local buffer and load and start the image using loadimage() and startimage(). So I assume since we are using a memory pointer the loaimage() should call security architecture protocol.
#2 From what you said below, if we sign the image hidden in the flash then the #2 should not be an issue.
So I guess since loadimage() takes care of both #1 and #2. We shouldn’t be having any issue from the security perspective. Do we have any other concerns with this approach?
There are two issues:
1) TCG: Is the utility part of the same EFI image that gets measured by the firmware. Typically, if you are using LoadImage() with a memory pointer, LoadImage() will call the Security Architecture protocol, which will, in turn, measure these into PCR 4. A MAA which is sensitive to changes in PCR 4 might take a different path.
2) SECURE BOOT: LoadImage() will check the certificates attached to your application. If it is not signed by a key related to one of the certs/hashes in the database, LoadImage() will fail.
So, in general, your loader doesn’t have to do it. LoadImage() should do it.
The configuration utility is EFI image. And the EFI image is stored In the option ROM. The thin BSD uses loadimage() and startimage() for executing the HII configuration utility.
The only concern is those utilities will not be part of the OpROM image staged into host memory by the system firmware and I couldn’t get what kind of complications it will create with secure boot.
Let us say, if OptionROM security check is enabled in system firmware and the BSD image is signed but the HII utility image is not signed, will the system firmware validates and rejects the HII image loading through startimage() or it is the responsibility of the our BSD to validate the sign before calling loadimage()?
What are HII configuration utilities? They are EFI image or HII package data?
I would like to get your expert opinion on whether the below mentioned model is acceptable in UEFI.
We want to have one thin boot service driver in our OptionROM image (exposed in PCI enumeration) and the driver will dynamically load one of many HII configuration utilities based on the controller type. Is this design acceptable?
I am concerned about the below section in the driver developer’s guide
4.2.13 Do not use hidden PCI Option ROM Regions
Some option ROMs may use paging or other techniques to load and execute code that
was not visible to the system firmware when measuring the visible portion of the
option ROM. This technique is discouraged because it is the PCI bus driver’s
responsibility to extract the option ROM contents when a PCI bus enumerates. If code
were required to access hidden portions of an option ROM, then the PCI bus driver
would not have the ability to extract the additional PCI Option ROM contents.
This inability means that the UEFI drivers in a PCI Option ROM must be visible without
accessing a hidden portion of a PCI Option ROM. However, if there is a safe mechanism
to access the hidden portions of the PCI option ROM after the UEFI drivers have been
loaded and executed, then the UEFI driver may choose to access those contents. For
example, non-volatile configuration information, utilities, or diagnostics can be stored
in the hidden PCI Option ROM regions.
Caution: The hidden option ROM regions are also not measurable via UEFI 2.3 and beyond
signing and verification interfaces. This makes them, and the system, less secure.