Sathya -
For #1: any portion that will be executed must be measured. Yes, if you use
LoadImage() it will get measured.
Normally drivers do not launch user interfaces themselves during the boot
process. I wasn't clear if that was your intention.
Tim
From: Prakash, Sathya [mailto:[email protected]]
Sent: Friday, March 08, 2013 1:24 PM
To: [email protected]
Subject: Re: [edk2] Loading different HII images from OptionROM
Tim,
#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?
Thanks
Sathya
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, March 08, 2013 12:47 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Loading different HII images from OptionROM
Sathya -
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.
Tim
From: Prakash, Sathya [mailto:[email protected]]
Sent: Friday, March 08, 2013 11:28 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Loading different HII images from OptionROM
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()?
Thanks
Sathya
From: Gao, Liming [mailto:[email protected]]
Sent: Friday, March 08, 2013 12:33 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] Loading different HII images from OptionROM
Hi:
What are HII configuration utilities? They are EFI image or HII package data?
Thanks
Liming
From: Prakash, Sathya [mailto:[email protected]]
Sent: Friday, March 08, 2013 3:30 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] Loading different HII images from OptionROM
Folks,
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.
Thanks
Sathya
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
