Re: [edk2] Measured boot in OVMF with QEMU TPM passthrough?
Hello again,
I've done some analysis and here's where I'm at with measured boot with
OVMF in a QEMU guest:
I've verified that most of the relevant modules that need to be added
according to the instructions at
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security#HOW_TO_ENABLE_TCG_TPM
are being placed in the OVMF image by looking at Ovmf.map. They are
also loaded when OVMF boots, which I've verified from the OVMF debug
output. I believe the only one I've added to OvmfX64.dsc/fdf that does
not appear in the map or debug output is TcgSmm, which handles the ACPI
methods for TCG. I think this is a problem: I do see a TCPA table when
I dump the ACPI tables in my guest, and it has an address to the start
of the Event Log, but I still don't have any measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. And, the PCR values
from /sys/class/tpm/tpm0/device/pcrs don't change whether I have OVMF
Secure Boot enabled or not (I think it's supposed to extend PCR[07]?).
So, my question about whether or not measured boot with event logging
should be possible in OVMF with a QEMU VM still stands. Additonally, I'm
curious if the way I've added components to the OvmfX64.dsc file is
correct. For example, here's how I added the TcgDxe component:
SecurityPkg/Tcg/TcgDxe/TcgDxe.inf {
LibraryClasses
TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.inf
}
I added the LibraryClasses subsection after the build tool complained
about an instance of that class not being found, and did the same for
the other modules that had the same issue. I see other LibraryClasses
in TcgDxe.inf that don't require an instance in the subsection, why is that?
Finally, where in the code should I do steps 1 and 2 (clear memory,
process request) from the instructions linked above?
Any guidance would be appreciated.
Thanks,
David
On 08/19/2015 05:17 PM, David Van Arnem wrote:
Hello,
Should it be possible to perform measured boot in OVMF to measure a
QEMU guest (extend and log PCRs) using a TPM passed-through from the
host?
I have a host machine with a TPM (v1.2), and a QEMU Linux guest
booting using an OVMF image with the modifications suggested in the
following link (modifications were done to OvmfX64.dsc):
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security (section
How To Enable TCG TPM). I've enabled QEMU TPM passthrough from the
host to the guest, and I'm able to query the TPM in the guest using
commands like tpm_version, tpm_getpubek, etc. However, there are no
measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. Additionally,
though I can view the PCR list from /sys/class/tpm/tpm0/device/pcrs,
the list contains the same values that I saw when looking at the same
file on my host before enabling TPM passthrough. So, it appears
measurement is not happening on the guest, and I wanted to check here
to see if that's a limitation of OVMF/TPM passthrough, or if I just
did something incorrectly when modifying the OVMF package.
Thanks,
David
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 11/15] OvmfPkg: Link separated VarCheckUefiLib NULL class library instance
On 08/17/15 10:24, Star Zeng wrote:
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
OvmfPkg/OvmfPkgIa32.dsc| 5 -
OvmfPkg/OvmfPkgIa32X64.dsc | 5 -
OvmfPkg/OvmfPkgX64.dsc | 5 -
3 files changed, 12 insertions(+), 3 deletions(-)
Reviewed-by: Laszlo Ersek ler...@redhat.com
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index df00011..e55f0db 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -461,7 +461,10 @@ [Components]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 355ed6a..a8fcd88 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -468,7 +468,10 @@ [Components.X64]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4469bd1..63e8c12 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -466,7 +466,10 @@ [Components]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 04/15] OvmfPkg: Add VarCheckLib library mapping
On 08/17/15 10:23, Star Zeng wrote: Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Jordan Justen jordan.l.jus...@intel.com Cc: Laszlo Ersek ler...@redhat.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com --- OvmfPkg/OvmfPkgIa32.dsc| 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + 3 files changed, 3 insertions(+) Reviewed-by: Laszlo Ersek ler...@redhat.com diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 4ab618d..df00011 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -128,6 +128,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 90ca42a..355ed6a 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -133,6 +133,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index b72eaa9..4469bd1 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -133,6 +133,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/2] OvmfPkg: Add HttpBoot support
On 08/17/15 10:20, Gary Ching-Pang Lin wrote: This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE. When HttpBoot is enabled, a new Network boot option will show in the boot manager menu with the device path like this: PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri() It works like the PXE one but fetches the NBP from the given http url instead of the tftp service. A simple testing environment can be set up with the QEMU tap network and dnsmasq + lighttpd. Here is the example of the dnsmasq config: interface=tap interface dhcp-range=192.168.111.100,192.168.111.120,12h dhcp-option=60,HTTPClient dhcp-boot=http://tap ip/efi file It's similar to the PXE server settings except the tftp function is disabled, the option 60 must be HTTPClient, and the boot uri is a http url. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin g...@suse.com --- OvmfPkg/OvmfPkgIa32.dsc| 10 ++ OvmfPkg/OvmfPkgIa32.fdf| 5 + OvmfPkg/OvmfPkgIa32X64.dsc | 10 ++ OvmfPkg/OvmfPkgIa32X64.fdf | 5 + OvmfPkg/OvmfPkgX64.dsc | 10 ++ OvmfPkg/OvmfPkgX64.fdf | 5 + 6 files changed, 45 insertions(+) Reviewed-by: Laszlo Ersek ler...@redhat.com Please ask Siyuan, Jordan, or Ard to commit this for you. Laszlo diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 4ab618d..9a6de15 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -35,6 +35,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE HTTP_BOOT_ENABLE= FALSE [BuildOptions] GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG @@ -129,6 +130,10 @@ [LibraryClasses] AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf +!endif + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf @@ -551,6 +556,11 @@ [Components] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + NetworkPkg/DnsDxe/DnsDxe.inf + NetworkPkg/HttpDxe/HttpDxe.inf + NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 16675f8..0e4ee49 100644 --- a/OvmfPkg/OvmfPkgIa32.fdf +++ b/OvmfPkg/OvmfPkgIa32.fdf @@ -324,6 +324,11 @@ [FV.DXEFV] INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + INF NetworkPkg/DnsDxe/DnsDxe.inf + INF NetworkPkg/HttpDxe/HttpDxe.inf + INF NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif INF OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 90ca42a..2f8006d 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -35,6 +35,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE HTTP_BOOT_ENABLE= FALSE [BuildOptions] GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG @@ -134,6 +135,10 @@ [LibraryClasses] AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf +!endif + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf @@ -558,6 +563,11 @@ [Components.X64] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + NetworkPkg/DnsDxe/DnsDxe.inf + NetworkPkg/HttpDxe/HttpDxe.inf + NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index e6c525a..74412d4 100644 --- a/OvmfPkg/OvmfPkgIa32X64.fdf +++ b/OvmfPkg/OvmfPkgIa32X64.fdf @@ -324,6 +324,11 @@ [FV.DXEFV] INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + INF NetworkPkg/DnsDxe/DnsDxe.inf + INF NetworkPkg/HttpDxe/HttpDxe.inf + INF
Re: [edk2] [Patch 0/3] Add header file and driver module for HTTP utilities
Thank you for doing this! Series Reviewed-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu Sent: Thursday, August 20, 2015 8:37 PM To: edk2-devel@lists.01.org Subject: [edk2] [Patch 0/3] Add header file and driver module for HTTP utilities Those patches are used to add header file and driver module for HTTP utilities Jiaxin Wu (3): MdePkg: Add header files for HTTP utilities protocol. NetworkPkg: Add HTTP utilities driver. Nt32Pkg: Add HttpUtilitiesDxe module. MdePkg/Include/Protocol/HttpUtilities.h| 124 +++ MdePkg/MdePkg.dec | 3 + NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c | 126 +++ NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.h | 212 +++ NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf | 51 +++ NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesImpl.c| 279 +++ .../HttpUtilitiesDxe/HttpUtilitiesProtocol.c | 393 + NetworkPkg/NetworkPkg.dsc | 2 + Nt32Pkg/Nt32Pkg.dsc| 1 + Nt32Pkg/Nt32Pkg.fdf| 1 + 10 files changed, 1192 insertions(+) create mode 100644 MdePkg/Include/Protocol/HttpUtilities.h create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.h create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesImpl.c create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Measured boot in OVMF with QEMU TPM passthrough?
On 08/21/15 18:44, David Van Arnem wrote:
Hello again,
I've done some analysis and here's where I'm at with measured boot with
OVMF in a QEMU guest:
I've verified that most of the relevant modules that need to be added
according to the instructions at
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security#HOW_TO_ENABLE_TCG_TPM
are being placed in the OVMF image by looking at Ovmf.map. They are
also loaded when OVMF boots, which I've verified from the OVMF debug
output. I believe the only one I've added to OvmfX64.dsc/fdf that does
not appear in the map or debug output is TcgSmm, which handles the ACPI
methods for TCG.
Based on the name, TcgSmm is probably an SMM runtime driver, and would
have to be loaded by the SMM core.
However, SMM support is just being added to OVMF, so TcgSmm won't work
for you right now.
I think this is a problem: I do see a TCPA table when
I dump the ACPI tables in my guest, and it has an address to the start
of the Event Log, but I still don't have any measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. And, the PCR values
from /sys/class/tpm/tpm0/device/pcrs don't change whether I have OVMF
Secure Boot enabled or not (I think it's supposed to extend PCR[07]?).
So, my question about whether or not measured boot with event logging
should be possible in OVMF with a QEMU VM still stands.
No clue. Probably not.
Additonally, I'm
curious if the way I've added components to the OvmfX64.dsc file is
correct. For example, here's how I added the TcgDxe component:
SecurityPkg/Tcg/TcgDxe/TcgDxe.inf {
LibraryClasses
TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.inf
}
I added the LibraryClasses subsection after the build tool complained
about an instance of that class not being found, and did the same for
the other modules that had the same issue. I see other LibraryClasses
in TcgDxe.inf that don't require an instance in the subsection, why is
that?
Because either the module-type-independent [LibraryClasses] section in
the DSC file generally resolves the library class to a library instance,
and/or because the DXE_DRIVER module type specific section
[LibraryClasses.DXE_DRIVER] does the same (overriding the default if
both sections specify a resolution).
Finally, where in the code should I do steps 1 and 2 (clear memory,
process request) from the instructions linked above?
Step 1: for this you will need to include the r/o variable driver PEIM
in OVMF. Otherwise you can't look at the MemoryOverwriteRequestControl
variable during PEI. When you have that covered... Well, OVMF does not
do memory initialization, because memory is just there from the start
in a virtual machine. If you want to clear memory, you'll have to
familiarize yourself with the OVMF memory map, and figure out what to
clear and when. I got no clue about TPM. (And honestly, I have zero time
to learn about it.) The OVMF whitepaper describes the memory map in
detail (google it).
Step 2: TcgPhysicalPresenceLibProcessRequest () from TCG physical
presenceLib library should be invoked to process pending TPM request in
BDS when console is ready -- that would be in
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c, function
PlatformBdsPolicyBehavior(), after the call to
PlatformBdsConnectConsole(). Probably.
Any guidance would be appreciated.
Thanks,
David
On 08/19/2015 05:17 PM, David Van Arnem wrote:
Hello,
Should it be possible to perform measured boot in OVMF to measure a
QEMU guest (extend and log PCRs) using a TPM passed-through from the
host?
I have a host machine with a TPM (v1.2), and a QEMU Linux guest
booting using an OVMF image with the modifications suggested in the
following link (modifications were done to OvmfX64.dsc):
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security (section
How To Enable TCG TPM). I've enabled QEMU TPM passthrough from the
host to the guest, and I'm able to query the TPM in the guest using
commands like tpm_version, tpm_getpubek, etc. However, there are no
measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. Additionally,
though I can view the PCR list from /sys/class/tpm/tpm0/device/pcrs,
the list contains the same values that I saw when looking at the same
file on my host before enabling TPM passthrough. So, it appears
measurement is not happening on the guest, and I wanted to check here
to see if that's a limitation of OVMF/TPM passthrough, or if I just
did something incorrectly when modifying the OVMF package.
Thanks,
David
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
Re: [edk2] [PATCH 13/15] ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance
On 08/18/15 14:05, Ard Biesheuvel wrote:
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
Cc: Laszlo Ersek ler...@redhat.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org
Thanks Ard (for the other ArmVirtPkg patch review too)
---
ArmVirtPkg/ArmVirtQemu.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 216f130..f1af968 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -256,7 +256,10 @@ [Components.common]
#
ArmPkg/Drivers/CpuDxe/CpuDxe.inf
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+LibraryClasses
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
!if $(SECURE_BOOT_ENABLE) == TRUE
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
LibraryClasses
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Measured boot in OVMF with QEMU TPM passthrough?
On Fri, Aug 21, 2015 at 6:44 PM, David Van Arnem dvanar...@cmlab.biz wrote:
Hello again,
I've done some analysis and here's where I'm at with measured boot with OVMF
in a QEMU guest:
I've verified that most of the relevant modules that need to be added
according to the instructions at
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security#HOW_TO_ENABLE_TCG_TPM
are being placed in the OVMF image by looking at Ovmf.map. They are also
loaded when OVMF boots, which I've verified from the OVMF debug output. I
believe the only one I've added to OvmfX64.dsc/fdf that does not appear in
the map or debug output is TcgSmm, which handles the ACPI methods for TCG.
I think this is a problem: I do see a TCPA table when I dump the ACPI tables
in my guest, and it has an address to the start of the Event Log, but I
still don't have any measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. And, the PCR values from
/sys/class/tpm/tpm0/device/pcrs don't change whether I have OVMF Secure Boot
enabled or not (I think it's supposed to extend PCR[07]?).
So, my question about whether or not measured boot with event logging should
be possible in OVMF with a QEMU VM still stands. Additonally, I'm curious if
the way I've added components to the OvmfX64.dsc file is correct. For
example, here's how I added the TcgDxe component:
SecurityPkg/Tcg/TcgDxe/TcgDxe.inf {
LibraryClasses
TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.inf
}
I added the LibraryClasses subsection after the build tool complained about
an instance of that class not being found, and did the same for the other
modules that had the same issue. I see other LibraryClasses in TcgDxe.inf
that don't require an instance in the subsection, why is that?
Finally, where in the code should I do steps 1 and 2 (clear memory, process
request) from the instructions linked above?
Any guidance would be appreciated.
Hi,
If I'm not mistaken all of this should be handled without anything for
you to do. You just need to add the right modules like
SecurityPkg/Tcg/TcgPei (for TPM 1.2, I think that QEMU only support
1.2). When they will be loaded their entry point function will be
called and perform what is necessary.
If you want an example about what you should add in the .dsc, .fdf and
.dec files (libraries, modules, some variables value), you should look
into Vlv2TbltDevicePkg/ that use TPM.
Hope this helps
Thanks,
David
On 08/19/2015 05:17 PM, David Van Arnem wrote:
Hello,
Should it be possible to perform measured boot in OVMF to measure a QEMU
guest (extend and log PCRs) using a TPM passed-through from the host?
I have a host machine with a TPM (v1.2), and a QEMU Linux guest booting
using an OVMF image with the modifications suggested in the following link
(modifications were done to OvmfX64.dsc):
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security (section How
To Enable TCG TPM). I've enabled QEMU TPM passthrough from the host to the
guest, and I'm able to query the TPM in the guest using commands like
tpm_version, tpm_getpubek, etc. However, there are no measurements recorded
in /sys/kernel/security/tpm0/ascii_bios_measurements. Additionally, though
I can view the PCR list from /sys/class/tpm/tpm0/device/pcrs, the list
contains the same values that I saw when looking at the same file on my host
before enabling TPM passthrough. So, it appears measurement is not
happening on the guest, and I wanted to check here to see if that's a
limitation of OVMF/TPM passthrough, or if I just did something incorrectly
when modifying the OVMF package.
Thanks,
David
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Measured boot in OVMF with QEMU TPM passthrough?
On Fri, Aug 21, 2015 at 7:21 PM, Laszlo Ersek ler...@redhat.com wrote:
On 08/21/15 18:44, David Van Arnem wrote:
Hello again,
I've done some analysis and here's where I'm at with measured boot with
OVMF in a QEMU guest:
I've verified that most of the relevant modules that need to be added
according to the instructions at
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security#HOW_TO_ENABLE_TCG_TPM
are being placed in the OVMF image by looking at Ovmf.map. They are
also loaded when OVMF boots, which I've verified from the OVMF debug
output. I believe the only one I've added to OvmfX64.dsc/fdf that does
not appear in the map or debug output is TcgSmm, which handles the ACPI
methods for TCG.
Based on the name, TcgSmm is probably an SMM runtime driver, and would
have to be loaded by the SMM core.
However, SMM support is just being added to OVMF, so TcgSmm won't work
for you right now.
I think this is a problem: I do see a TCPA table when
I dump the ACPI tables in my guest, and it has an address to the start
of the Event Log, but I still don't have any measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. And, the PCR values
from /sys/class/tpm/tpm0/device/pcrs don't change whether I have OVMF
Secure Boot enabled or not (I think it's supposed to extend PCR[07]?).
So, my question about whether or not measured boot with event logging
should be possible in OVMF with a QEMU VM still stands.
No clue. Probably not.
Additonally, I'm
curious if the way I've added components to the OvmfX64.dsc file is
correct. For example, here's how I added the TcgDxe component:
SecurityPkg/Tcg/TcgDxe/TcgDxe.inf {
LibraryClasses
TpmCommLib|SecurityPkg/Library/TpmCommLib/TpmCommLib.inf
}
I added the LibraryClasses subsection after the build tool complained
about an instance of that class not being found, and did the same for
the other modules that had the same issue. I see other LibraryClasses
in TcgDxe.inf that don't require an instance in the subsection, why is
that?
Because either the module-type-independent [LibraryClasses] section in
the DSC file generally resolves the library class to a library instance,
and/or because the DXE_DRIVER module type specific section
[LibraryClasses.DXE_DRIVER] does the same (overriding the default if
both sections specify a resolution).
Finally, where in the code should I do steps 1 and 2 (clear memory,
process request) from the instructions linked above?
Step 1: for this you will need to include the r/o variable driver PEIM
in OVMF. Otherwise you can't look at the MemoryOverwriteRequestControl
variable during PEI. When you have that covered... Well, OVMF does not
do memory initialization, because memory is just there from the start
in a virtual machine. If you want to clear memory, you'll have to
familiarize yourself with the OVMF memory map, and figure out what to
clear and when. I got no clue about TPM. (And honestly, I have zero time
to learn about it.) The OVMF whitepaper describes the memory map in
detail (google it).
Yeah I am not sure this is really useful for a virtual machine. It is
to mitigate an attack about someone dumping the content of the RAM by
quickly turning off and on the platform. So if the firmware is
clearing the memory before the attacker can dump it, it cannot dump
any secret data. So for a virtual machine, there is no need to do
this.
But if you want to implement this anyway, the spec is saying [1] you
need to zero the memory if this bit is set at platform initialization.
[1]
https://www.trustedcomputinggroup.org/files/temp/6452209B-1D09-3519-AD815636FC36C5CF/Platform%20Reset%20Attack%20Mitigation%20Specification.pdf
Step 2: TcgPhysicalPresenceLibProcessRequest () from TCG physical
presenceLib library should be invoked to process pending TPM request in
BDS when console is ready -- that would be in
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c, function
PlatformBdsPolicyBehavior(), after the call to
PlatformBdsConnectConsole(). Probably.
Any guidance would be appreciated.
Thanks,
David
On 08/19/2015 05:17 PM, David Van Arnem wrote:
Hello,
Should it be possible to perform measured boot in OVMF to measure a
QEMU guest (extend and log PCRs) using a TPM passed-through from the
host?
I have a host machine with a TPM (v1.2), and a QEMU Linux guest
booting using an OVMF image with the modifications suggested in the
following link (modifications were done to OvmfX64.dsc):
http://tianocore.sourceforge.net/wiki/How_to_Enable_Security (section
How To Enable TCG TPM). I've enabled QEMU TPM passthrough from the
host to the guest, and I'm able to query the TPM in the guest using
commands like tpm_version, tpm_getpubek, etc. However, there are no
measurements recorded in
/sys/kernel/security/tpm0/ascii_bios_measurements. Additionally,
though I can view the PCR list from /sys/class/tpm/tpm0/device/pcrs,
the list contains the same values that I saw
[edk2] [PATCH 2/2] MdePkg: Follow PI spec to update ExtendedSize in EFI_FFS_FILE_HEADER2
for FFS data above 16 bytes alignment requirement.
PI spec requires FFS header to be at 8 bytes alignment to FV header.
And, FFS data alignment requires the beginning of the file data must
be aligned on a particular boundary, such as 1, 16, 128 bytes or above.
If FFS data alignment requires to be above 16 bytes, and FFS header
must be at 8 byte alignment, so FFS header size must be multiple of 8.
Cc: Liming Gao liming@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Pi/PiFirmwareFile.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
b/MdePkg/Include/Pi/PiFirmwareFile.h
index 1f94429..7343444 100644
--- a/MdePkg/Include/Pi/PiFirmwareFile.h
+++ b/MdePkg/Include/Pi/PiFirmwareFile.h
@@ -1,7 +1,7 @@
/** @file
The firmware file related definitions in PI.
-Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials are licensed and made available
under
the terms and conditions of the BSD License that accompanies this distribution.
The full text of the license may be found at
@@ -11,7 +11,7 @@ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS
IS BASIS,
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
@par Revision Reference:
- PI Version 1.2.
+ PI Version 1.4.
**/
@@ -173,7 +173,7 @@ typedef struct {
/// If FFS_ATTRIB_LARGE_FILE is set in Attributes, then ExtendedSize exists
and Size must be set to zero.
/// If FFS_ATTRIB_LARGE_FILE is not set then EFI_FFS_FILE_HEADER is used.
///
- UINT32ExtendedSize;
+ UINT64ExtendedSize;
} EFI_FFS_FILE_HEADER2;
#define IS_FFS_FILE2(FfsFileHeaderPtr) \
@@ -183,7 +183,7 @@ typedef struct {
((UINT32) (*((UINT32 *) ((EFI_FFS_FILE_HEADER *) (UINTN)
FfsFileHeaderPtr)-Size) 0x00ff))
#define FFS_FILE2_SIZE(FfsFileHeaderPtr) \
-(((EFI_FFS_FILE_HEADER2 *) (UINTN) FfsFileHeaderPtr)-ExtendedSize)
+((UINT32) (((EFI_FFS_FILE_HEADER2 *) (UINTN)
FfsFileHeaderPtr)-ExtendedSize))
typedef UINT8 EFI_SECTION_TYPE;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] BaseTools: Follow PI spec to update ExtendedSize in EFI_FFS_FILE_HEADER2
for FFS data above 16 bytes alignment requirement.
PI spec requires FFS header to be at 8 bytes alignment to FV header.
And, FFS data alignment requires the beginning of the file data must
be aligned on a particular boundary, such as 1, 16, 128 bytes or above.
If FFS data alignment requires to be above 16 bytes, and FFS header
must be at 8 byte alignment, so FFS header size must be multiple of 8.
Cc: Liming Gao liming@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
BaseTools/Source/C/Common/FirmwareVolumeBuffer.c | 4 ++--
BaseTools/Source/C/Common/FvLib.c | 4 ++--
BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
index 01d4e72..7988d8e 100644
--- a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
+++ b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
@@ -1,7 +1,7 @@
/** @file
EFI Firmware Volume routines which work on a Fv image in buffers.
-Copyright (c) 1999 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -864,7 +864,7 @@ Returns:
return 0;
}
if (Ffs-Attributes FFS_ATTRIB_LARGE_FILE) {
-return ((EFI_FFS_FILE_HEADER2 *)Ffs)-ExtendedSize;
+return (UINT32) ((EFI_FFS_FILE_HEADER2 *)Ffs)-ExtendedSize;
}
return FvBufExpand3ByteSize(Ffs-Size);
}
diff --git a/BaseTools/Source/C/Common/FvLib.c
b/BaseTools/Source/C/Common/FvLib.c
index 1b3c08b..938aa09 100644
--- a/BaseTools/Source/C/Common/FvLib.c
+++ b/BaseTools/Source/C/Common/FvLib.c
@@ -1,7 +1,7 @@
/** @file
These functions assist in parsing and manipulating a Firmware Volume.
-Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -784,7 +784,7 @@ Returns:
return 0;
}
if (FfsHeader-Attributes FFS_ATTRIB_LARGE_FILE) {
-return ((EFI_FFS_FILE_HEADER2 *)FfsHeader)-ExtendedSize;
+return (UINT32) ((EFI_FFS_FILE_HEADER2 *)FfsHeader)-ExtendedSize;
} else {
return GetLength(FfsHeader-Size);
}
diff --git a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
index ec31eab..2984860 100644
--- a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
+++ b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
@@ -2,9 +2,9 @@
The firmware file related definitions in PI.
@par Revision Reference:
- Version 1.0.
+ Version 1.4.
- Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+ Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
@@ -110,7 +110,7 @@ typedef struct {
EFI_FFS_FILE_ATTRIBUTES Attributes;
UINT8 Size[3];
EFI_FFS_FILE_STATE State;
- UINT32 ExtendedSize;
+ UINT64 ExtendedSize;
} EFI_FFS_FILE_HEADER2;
#define MAX_FFS_SIZE0x100
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] MdePkg: Follow PI spec to update ExtendedSize in EFI_FFS_FILE_HEADER2
Reviewed-by: Liming Gao liming@intel.com
-Original Message-
From: Zeng, Star
Sent: Friday, August 21, 2015 2:19 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [PATCH 2/2] MdePkg: Follow PI spec to update ExtendedSize in
EFI_FFS_FILE_HEADER2
for FFS data above 16 bytes alignment requirement.
PI spec requires FFS header to be at 8 bytes alignment to FV header.
And, FFS data alignment requires the beginning of the file data must be aligned
on a particular boundary, such as 1, 16, 128 bytes or above.
If FFS data alignment requires to be above 16 bytes, and FFS header must be at
8 byte alignment, so FFS header size must be multiple of 8.
Cc: Liming Gao liming@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
MdePkg/Include/Pi/PiFirmwareFile.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
b/MdePkg/Include/Pi/PiFirmwareFile.h
index 1f94429..7343444 100644
--- a/MdePkg/Include/Pi/PiFirmwareFile.h
+++ b/MdePkg/Include/Pi/PiFirmwareFile.h
@@ -1,7 +1,7 @@
/** @file
The firmware file related definitions in PI.
-Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License that accompanies this
distribution.
The full text of the license may be found at @@ -11,7 +11,7 @@ THE PROGRAM IS
DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT WARRANTIES OR
REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
@par Revision Reference:
- PI Version 1.2.
+ PI Version 1.4.
**/
@@ -173,7 +173,7 @@ typedef struct {
/// If FFS_ATTRIB_LARGE_FILE is set in Attributes, then ExtendedSize exists
and Size must be set to zero.
/// If FFS_ATTRIB_LARGE_FILE is not set then EFI_FFS_FILE_HEADER is used.
///
- UINT32ExtendedSize;
+ UINT64ExtendedSize;
} EFI_FFS_FILE_HEADER2;
#define IS_FFS_FILE2(FfsFileHeaderPtr) \ @@ -183,7 +183,7 @@ typedef struct {
((UINT32) (*((UINT32 *) ((EFI_FFS_FILE_HEADER *) (UINTN)
FfsFileHeaderPtr)-Size) 0x00ff))
#define FFS_FILE2_SIZE(FfsFileHeaderPtr) \
-(((EFI_FFS_FILE_HEADER2 *) (UINTN) FfsFileHeaderPtr)-ExtendedSize)
+((UINT32) (((EFI_FFS_FILE_HEADER2 *) (UINTN)
+ FfsFileHeaderPtr)-ExtendedSize))
typedef UINT8 EFI_SECTION_TYPE;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 0/6] Add generic PcdGetSize() API
V2: BaseTools generates the real size for the intital value of VOID* PCD. Update BasePcdLibNull library instance to add two new PcdApi. V1: PcdLib LibPcdGetSize() and LibPcdGetExSize() are type specific API. New generic PcdGetSize() API will be added to reterieve the size of PCD value. Like PcdGetValue(), it supports all PCD types and all PCD data types. BaseTools generates PCD size macros in AutoGen code. MdePkg PcdLib adds PcdGetSize() APIs to match those generated macros. Modules use PcdGetSize() API to replace LibPcdGetSize() and LibPcdGetExSize() APIs. Liming Gao (6): BaseTools: Generate macro for the size of PCD value BaseTools: Fix AutoGen issue for Patchable VOID* PCD. BaseTools: Update SetPcdPtr in AutoGen Code MdePkg: Add four PcdGetSize() API in PcdLib MdePkg: Add two PcdApi for Patch VOID* PCD set operation. SecurityPkg: Use PcdGetSize to get the size of VOID* PCD value. BaseTools/Source/Python/AutoGen/GenC.py| 90 +++-- MdePkg/Include/Library/PcdLib.h| 141 - MdePkg/Library/BasePcdLibNull/PcdLib.c | 120 +- MdePkg/Library/DxePcdLib/DxePcdLib.c | 119 - MdePkg/Library/PeiPcdLib/PeiPcdLib.c | 119 - .../DxeRsa2048Sha256GuidedSectionExtractLib.c | 4 +- .../DxeRsa2048Sha256GuidedSectionExtractLib.inf| 4 +- .../PeiRsa2048Sha256GuidedSectionExtractLib.c | 4 +- .../PeiRsa2048Sha256GuidedSectionExtractLib.inf| 2 +- 9 files changed, 567 insertions(+), 36 deletions(-) -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 5/6] MdePkg: Add two PcdApi for Patch VOID* PCD set operation.
Two new APIs LibPatchPcdSetPtrAndSize() and LibPatchPcdSetPtrAndSizeS() are added to catch the size of the updated VOID* PCD value buffer, then PcdGetSize() API can return the actual size. Update three PcdLib instances to implement these two APIs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao liming@intel.com Reviewed-by: Star Zeng star.z...@intel.com --- MdePkg/Include/Library/PcdLib.h| 83 +-- MdePkg/Library/BasePcdLibNull/PcdLib.c | 120 +++-- MdePkg/Library/DxePcdLib/DxePcdLib.c | 119 ++-- MdePkg/Library/PeiPcdLib/PeiPcdLib.c | 119 ++-- 4 files changed, 422 insertions(+), 19 deletions(-) diff --git a/MdePkg/Include/Library/PcdLib.h b/MdePkg/Include/Library/PcdLib.h index ce759fe..ad8a700 100644 --- a/MdePkg/Include/Library/PcdLib.h +++ b/MdePkg/Include/Library/PcdLib.h @@ -340,12 +340,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. @return Return the pointer to the Buffer that was set. **/ #define PatchPcdSetPtr(TokenName, Size, Buffer) \ -LibPatchPcdSetPtr ( \ - _gPcd_BinaryPatch_##TokenName, \ +LibPatchPcdSetPtrAndSize ( \ + (VOID *)_gPcd_BinaryPatch_##TokenName, \ + _gPcd_BinaryPatch_Size_##TokenName, \ (UINTN)_PCD_PATCHABLE_##TokenName##_SIZE, \ (Size), \ (Buffer) \ ) /** @@ -2054,11 +2055,11 @@ LibPcdGetNextTokenSpace ( If PatchVariable is NULL, then ASSERT(). If SizeOfBuffer is NULL, then ASSERT(). If SizeOfBuffer 0 and Buffer is NULL, then ASSERT(). - @param[in] PatchVariable A pointer to the global variable in a module that is + @param[out] PatchVariable A pointer to the global variable in a module that is the target of the set operation. @param[in] MaximumDatumSize The maximum size allowed for the PCD entry specified by PatchVariable. @param[in, out] SizeOfBuffer A pointer to the size, in bytes, of Buffer. @param[in] Buffer A pointer to the buffer to used to set the target variable. @@ -2066,11 +2067,11 @@ LibPcdGetNextTokenSpace ( **/ VOID * EFIAPI LibPatchPcdSetPtr ( - INVOID*PatchVariable, + OUTVOID *PatchVariable, INUINTN MaximumDatumSize, IN OUTUINTN *SizeOfBuffer, IN CONST VOID*Buffer ); @@ -2086,11 +2087,11 @@ LibPatchPcdSetPtr ( If PatchVariable is NULL, then ASSERT(). If SizeOfBuffer is NULL, then ASSERT(). If SizeOfBuffer 0 and Buffer is NULL, then ASSERT(). - @param[in] PatchVariable A pointer to the global variable in a module that is + @param[out] PatchVariable A pointer to the global variable in a module that is the target of the set operation. @param[in] MaximumDatumSize The maximum size allowed for the PCD entry specified by PatchVariable. @param[in, out] SizeOfBuffer A pointer to the size, in bytes, of Buffer. @param[in] Buffer A pointer to the buffer to used to set the target variable. @@ -2098,11 +2099,81 @@ LibPatchPcdSetPtr ( **/ RETURN_STATUS EFIAPI LibPatchPcdSetPtrS ( - IN VOID *PatchVariable, + OUT VOID *PatchVariable, + IN UINTNMaximumDatumSize, + IN OUT UINTN*SizeOfBuffer, + IN CONST VOID *Buffer + ); + +/** + Sets a value and size of a patchable PCD entry that is type pointer. + + Sets the PCD entry specified by PatchVariable to the value specified by Buffer + and SizeOfBuffer. Buffer is returned. If SizeOfBuffer is greater than + MaximumDatumSize, then set SizeOfBuffer to MaximumDatumSize and return + NULL to indicate that the set operation was not actually performed. + If SizeOfBuffer is set to MAX_ADDRESS, then SizeOfBuffer must be set to + MaximumDatumSize and NULL must be returned. + + If PatchVariable is NULL, then ASSERT(). + If SizeOfPatchVariable is NULL, then ASSERT(). + If SizeOfBuffer is NULL, then ASSERT(). + If SizeOfBuffer 0 and Buffer is NULL, then ASSERT(). + + @param[out] PatchVariable A pointer to the global variable in a module that is +the target of the set operation. + @param[out] SizeOfPatchVariable A pointer to the size, in bytes, of PatchVariable. + @param[in] MaximumDatumSize The maximum size allowed for the PCD entry
[edk2] [PATCH v2 3/6] BaseTools: Update SetPcdPtr in AutoGen Code
For patchable PCD, map SetPcdPtr() to LibPatchPcdSetPtrAndSize(),
then the size of the updated VOID* value can be cached.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
BaseTools/Source/Python/AutoGen/GenC.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
b/BaseTools/Source/Python/AutoGen/GenC.py
index 76e9fa7..77de165 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -1019,12 +1019,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
AutoGenH.Append('extern %s %s %s%s;\n' % (Const, Pcd.DatumType,
PcdVariableName, Array))
AutoGenH.Append('#define %s %s%s\n' % (GetModeName, Type,
PcdVariableName))
if Pcd.Type == TAB_PCDS_PATCHABLE_IN_MODULE:
if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName,
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrAndSize((VOID *)_gPcd_BinaryPatch_%s,
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer),
(Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrAndSizeS((VOID *)_gPcd_BinaryPatch_%s,
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer),
(Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, Pcd.TokenCName,
Pcd.TokenCName))
else:
AutoGenH.Append('#define %s(Value) (%s = (Value))\n' %
(SetModeName, PcdVariableName))
AutoGenH.Append('#define %s(Value) ((%s = (Value)),
RETURN_SUCCESS) \n' % (SetModeStatusName, PcdVariableName))
else:
AutoGenH.Append('//#define %s ASSERT(FALSE) // It is not allowed
to set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
@@ -1142,12 +1142,12 @@ def CreateLibraryPcdCode(Info, AutoGenC, AutoGenH, Pcd):
if PcdItemType == TAB_PCDS_PATCHABLE_IN_MODULE:
PcdVariableName = '_gPcd_' +
gItemTypeStringDatabase[TAB_PCDS_PATCHABLE_IN_MODULE] + '_' + TokenCName
AutoGenH.Append('extern volatile %s _gPcd_BinaryPatch_%s%s;\n'
%(DatumType, TokenCName, Array) )
AutoGenH.Append('#define %s %s_gPcd_BinaryPatch_%s\n' %(GetModeName,
Type, TokenCName))
if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName,
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrAndSize((VOID *)_gPcd_BinaryPatch_%s,
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer),
(Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrAndSizeS((VOID *)_gPcd_BinaryPatch_%s,
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer),
(Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, Pcd.TokenCName,
Pcd.TokenCName))
else:
AutoGenH.Append('#define %s(Value) (%s = (Value))\n' %
(SetModeName, PcdVariableName))
AutoGenH.Append('#define %s(Value) ((%s = (Value)),
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
PcdDataSize = GetPcdSize(Pcd)
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/6] BaseTools: Fix AutoGen issue for Patchable VOID* PCD.
Patchable VOID* PCD set operation should map LibPatchPcdSetPtr()
and LibPatchPcdSetPtrS() API. This has been done when PCD is used
in driver, but not done when PCD is used in library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
BaseTools/Source/Python/AutoGen/GenC.py | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
b/BaseTools/Source/Python/AutoGen/GenC.py
index 381c14b..76e9fa7 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -1019,12 +1019,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
AutoGenH.Append('extern %s %s %s%s;\n' % (Const, Pcd.DatumType,
PcdVariableName, Array))
AutoGenH.Append('#define %s %s%s\n' % (GetModeName, Type,
PcdVariableName))
if Pcd.Type == TAB_PCDS_PATCHABLE_IN_MODULE:
if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtr(_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrS(_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName,
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName,
Pcd.TokenCName))
else:
AutoGenH.Append('#define %s(Value) (%s = (Value))\n' %
(SetModeName, PcdVariableName))
AutoGenH.Append('#define %s(Value) ((%s = (Value)),
RETURN_SUCCESS) \n' % (SetModeStatusName, PcdVariableName))
else:
AutoGenH.Append('//#define %s ASSERT(FALSE) // It is not allowed
to set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
@@ -1141,12 +1141,16 @@ def CreateLibraryPcdCode(Info, AutoGenC, AutoGenH, Pcd):
AutoGenH.Append('#define %s(Value) LibPcdSet%sS(%s, (Value))\n' %
(SetModeStatusName, DatumSizeLib, PcdTokenName))
if PcdItemType == TAB_PCDS_PATCHABLE_IN_MODULE:
PcdVariableName = '_gPcd_' +
gItemTypeStringDatabase[TAB_PCDS_PATCHABLE_IN_MODULE] + '_' + TokenCName
AutoGenH.Append('extern volatile %s _gPcd_BinaryPatch_%s%s;\n'
%(DatumType, TokenCName, Array) )
AutoGenH.Append('#define %s %s_gPcd_BinaryPatch_%s\n' %(GetModeName,
Type, TokenCName))
-AutoGenH.Append('#define %s(Value) (%s = (Value))\n' % (SetModeName,
PcdVariableName))
-AutoGenH.Append('#define %s(Value) ((%s = (Value)),
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
+if Pcd.DatumType == 'VOID*':
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE,
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName,
Pcd.TokenCName))
+else:
+AutoGenH.Append('#define %s(Value) (%s = (Value))\n' %
(SetModeName, PcdVariableName))
+AutoGenH.Append('#define %s(Value) ((%s = (Value)),
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
PcdDataSize = GetPcdSize(Pcd)
AutoGenH.Append('#define %s %s\n' % (PatchPcdSizeTokenName,
PcdDataSize))
AutoGenH.Append('#define %s %s\n' %
(GetModeSizeName,PatchPcdSizeVariableName))
AutoGenH.Append('extern UINTN %s; \n' % PatchPcdSizeVariableName)
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 1/6] BaseTools: Generate macro for the size of PCD value
PcdLib introduces new APIs to get the size of PCD value.
BaseTools generates those macros in AutoGen code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bob Feng bob.c.f...@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
BaseTools/Source/Python/AutoGen/GenC.py | 78 ++---
1 file changed, 73 insertions(+), 5 deletions(-)
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
b/BaseTools/Source/Python/AutoGen/GenC.py
index 3afded6..381c14b 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -731,10 +731,33 @@ def DynExPcdTokenNumberMapping(Info, AutoGenH):
# COMPAREGUID() will only be used if the Guid passed in
is local to the module.
AutoGenH.Append('#define _PCD_TOKEN_EX_%s(GuidPtr)
__PCD_%s_ADDR_CMP(GuidPtr) ? __PCD_%s_ADDR_CMP(GuidPtr) :
__PCD_%s_VAL_CMP(GuidPtr) \n'
% (Pcd.TokenCName, Pcd.TokenCName,
Pcd.TokenCName, Pcd.TokenCName))
TokenCNameList.append(TokenCName)
+def GetPcdSize(Pcd):
+if Pcd.DatumType == 'VOID*':
+Value = Pcd.DefaultValue
+if Value in [None, '']:
+return 1
+elif Value[0] == 'L':
+return (len(Value) - 2) * 2
+elif Value[0] == '{':
+return len(Value.split(','))
+else:
+return len(Value) - 1
+if Pcd.DatumType == 'UINT64':
+return 8
+if Pcd.DatumType == 'UINT32':
+return 4
+if Pcd.DatumType == 'UINT16':
+return 2
+if Pcd.DatumType == 'UINT8':
+return 1
+if Pcd.DatumType == 'BOOLEAN':
+return 1
+
+
## Create code for module PCDs
#
# @param InfoThe ModuleAutoGen object
# @param AutoGenCThe TemplateString object for C code
# @param AutoGenHThe TemplateString object for header file
@@ -745,10 +768,14 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
PcdTokenNumber = Info.PlatformInfo.PcdTokenNumber
#
# Write PCDs
#
PcdTokenName = '_PCD_TOKEN_' + Pcd.TokenCName
+PatchPcdSizeTokenName = '_PCD_PATCHABLE_' + Pcd.TokenCName +'_SIZE'
+PatchPcdSizeVariableName = '_gPcd_BinaryPatch_Size_' + Pcd.TokenCName
+FixPcdSizeTokenName = '_PCD_SIZE_' + Pcd.TokenCName
+
if Pcd.Type in gDynamicExPcd:
TokenNumber = int(Pcd.TokenValue, 0)
# Add TokenSpaceGuidValue value to PcdTokenName to discriminate the
DynamicEx PCDs with
# different Guids but same TokenCName
PcdExTokenName = '_PCD_TOKEN_' + Pcd.TokenSpaceGuidCName + '_' +
Pcd.TokenCName
@@ -786,11 +813,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
DatumSize = gDatumSizeStringDatabase[Pcd.DatumType]
DatumSizeLib = gDatumSizeStringDatabaseLib[Pcd.DatumType]
GetModeName = '_PCD_GET_MODE_' + gDatumSizeStringDatabaseH[Pcd.DatumType]
+ '_' + Pcd.TokenCName
SetModeName = '_PCD_SET_MODE_' + gDatumSizeStringDatabaseH[Pcd.DatumType]
+ '_' + Pcd.TokenCName
SetModeStatusName = '_PCD_SET_MODE_' +
gDatumSizeStringDatabaseH[Pcd.DatumType] + '_S_' + Pcd.TokenCName
-
+GetModeSizeName = '_PCD_GET_MODE_SIZE' + '_' + Pcd.TokenCName
+
PcdExCNameList = []
if Pcd.Type in gDynamicExPcd:
if Info.IsLibrary:
PcdList = Info.LibraryPcdList
else:
@@ -803,27 +831,30 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
# If PcdToken and PcdGet/Set used in the Pcds with different Guids but
same CName, it should failed to build.
if PcdExCNameList.count(Pcd.TokenCName) 1:
AutoGenH.Append('// Disabled the macros, as PcdToken and
PcdGet/Set are not allowed in the case that more than one DynamicEx Pcds are
different Guids but same CName.\n')
AutoGenH.Append('// #define %s %s\n' % (PcdTokenName,
PcdExTokenName))
AutoGenH.Append('// #define %s LibPcdGetEx%s(%s, %s)\n' %
(GetModeName, DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
+AutoGenH.Append('#define %s LibPcdGetExSize(%s, %s)\n' %
(GetModeSizeName,Pcd.TokenSpaceGuidCName, PcdTokenName))
if Pcd.DatumType == 'VOID*':
AutoGenH.Append('// #define %s(SizeOfBuffer, Buffer)
LibPcdSetEx%s(%s, %s, (SizeOfBuffer), (Buffer))\n' % (SetModeName,
DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
AutoGenH.Append('// #define %s(SizeOfBuffer, Buffer)
LibPcdSetEx%sS(%s, %s, (SizeOfBuffer), (Buffer))\n' % (SetModeStatusName,
DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
else:
AutoGenH.Append('// #define %s(Value) LibPcdSetEx%s(%s, %s,
(Value))\n' % (SetModeName, DatumSizeLib, Pcd.TokenSpaceGuidCName,
PcdTokenName))
AutoGenH.Append('// #define %s(Value) LibPcdSetEx%sS(%s, %s,
(Value))\n' % (SetModeStatusName, DatumSizeLib, Pcd.TokenSpaceGuidCName,
PcdTokenName))
[edk2] [PATCH v2 4/6] MdePkg: Add four PcdGetSize() API in PcdLib
Add below four PcdGetSize() API in PcdLib header file. They can be used to get the size of PCD value. FixedPcdGetSize() PatchPcdGetSize() PcdGetSize() PcdGetExSize() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao liming@intel.com Reviewed-by: Star Zeng star.z...@intel.com --- MdePkg/Include/Library/PcdLib.h | 58 - 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/MdePkg/Include/Library/PcdLib.h b/MdePkg/Include/Library/PcdLib.h index a7e1e62..ce759fe 100644 --- a/MdePkg/Include/Library/PcdLib.h +++ b/MdePkg/Include/Library/PcdLib.h @@ -346,11 +346,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. _gPcd_BinaryPatch_##TokenName, \ (UINTN)_PCD_PATCHABLE_##TokenName##_SIZE, \ (Size), \ (Buffer) \ ) - /** Retrieves an 8-bit PCD token value based on a token name. Returns the 8-bit value for the token specified by TokenName. If TokenName is not a valid token in the token space, then the module will not build. @@ -431,10 +430,67 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ #define PcdGetBool(TokenName) _PCD_GET_MODE_BOOL_##TokenName +/** + Retrieves the size of a fixed PCD token based on a token name. + + Returns the size of the token specified by TokenName. + If TokenName is not a valid token in the token space, then the module will not build. + + @param[in] TokenName The name of the PCD token to retrieve a current value size for. + + @return Return the size + +**/ +#define FixedPcdGetSize(TokenName)_PCD_SIZE_##TokenName + + +/** + Retrieves the size of a binary patchable PCD token based on a token name. + + Returns the size of the token specified by TokenName. + If TokenName is not a valid token in the token space, then the module will not build. + + @param[in] TokenName The name of the PCD token to retrieve a current value size for. + + @return Return the size + +**/ +#define PatchPcdGetSize(TokenName)_gPcd_BinaryPatch_Size_##TokenName + + +/** + Retrieves the size of the PCD token based on a token name. + + Returns the size of the token specified by TokenName. + If TokenName is not a valid token in the token space, then the module will not build. + + @param[in] TokenName The name of the PCD token to retrieve a current value size for. + + @return Return the size + +**/ +#define PcdGetSize(TokenName) _PCD_GET_MODE_SIZE_##TokenName + + +/** + Retrieve the size of a given PCD token. + + Returns the size of the token specified by TokenNumber and Guid. + If Guid is NULL, then ASSERT(). + + @param[in] Guid Pointer to a 128-bit unique value that designates +which namespace to retrieve a value from. + @param[in] TokenNumber The PCD token number to retrieve a current value size for. + + @return Return the size. + +**/ +#define PcdGetExSize(Guid, TokenName) LibPcdGetExSize ((Guid), PcdTokenEx(Guid,TokenName)) + #ifndef DISABLE_NEW_DEPRECATED_INTERFACES /** Sets an 8-bit PCD token value based on a token name. Sets the 8-bit value for the token specified by TokenName. Value is returned. -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 6/6] SecurityPkg: Use PcdGetSize to get the size of VOID* PCD value.
PcdLib introduces generic API to get the size of VOID* PCD value.
Update Pei and Dxe RsaGuidedLib to use generic PCD API instead of GetEx API.
This change can remove PCD type limitation in these two libraries.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
Reviewed-by: Star Zeng star.z...@intel.com
---
.../DxeRsa2048Sha256GuidedSectionExtractLib.c | 4 ++--
.../DxeRsa2048Sha256GuidedSectionExtractLib.inf | 4 ++--
.../PeiRsa2048Sha256GuidedSectionExtractLib.c | 4 ++--
.../PeiRsa2048Sha256GuidedSectionExtractLib.inf | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
index 2b61014..1f7a299 100644
---
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
+++
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
@@ -2,11 +2,11 @@
This library registers RSA 2048 SHA 256 guided section handler
to parse RSA 2048 SHA 256 encapsulation section and extract raw data.
It uses the BaseCrypyLib based on OpenSSL to authenticate the signature.
-Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
http://opensource.org/licenses/bsd-license.php
@@ -270,11 +270,11 @@ Rsa2048Sha256GuidedSectionHandler (
//
PublicKey = (UINT8 *)PcdGetPtr (PcdRsa2048Sha256PublicKeyBuffer);
DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer = %p\n,
PublicKey));
ASSERT (PublicKey != NULL);
DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer Token =
%08x\n, PcdToken (PcdRsa2048Sha256PublicKeyBuffer)));
- PublicKeyBufferSize = LibPcdGetExSize (gEfiSecurityPkgTokenSpaceGuid,
PcdToken (PcdRsa2048Sha256PublicKeyBuffer));
+ PublicKeyBufferSize = PcdGetSize (PcdRsa2048Sha256PublicKeyBuffer);
DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer Size = %08x\n,
PublicKeyBufferSize));
ASSERT ((PublicKeyBufferSize % SHA256_DIGEST_SIZE) == 0);
CryptoStatus = FALSE;
while (PublicKeyBufferSize != 0) {
if (CompareMem (Digest, PublicKey, SHA256_DIGEST_SIZE) == 0) {
diff --git
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
index f1777f4..4681f08 100644
---
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
+++
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
@@ -48,13 +48,13 @@
MemoryAllocationLib
BaseCryptLib
PcdLib
PerformanceLib
-[PcdEx]
+[Pcd]
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer##
SOMETIMES_CONSUMES
-
+
[Protocols]
gEfiSecurityPolicyProtocolGuid ## SOMETIMES_CONSUMES (Set
platform override AUTH status if exist)
[Guids]
gEfiCertTypeRsa2048Sha256Guid ## PRODUCES ## UNDEFINED # Specifies
RSA 2048 SHA 256 authentication algorithm.
diff --git
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
index 8c0047e..e2a0fb6 100644
---
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
+++
b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
@@ -2,11 +2,11 @@
This library registers RSA 2048 SHA 256 guided section handler
to parse RSA 2048 SHA 256 encapsulation section and extract raw data.
It uses the BaseCrypyLib based on OpenSSL to authenticate the signature.
-Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
http://opensource.org/licenses/bsd-license.php
[edk2] [PATCH 0/3] MdePkg/Library/UefiFileHandleLib: Refine UefiFileHandleLib
1. Update the module's type and Basename. 2. Refine FileHandleGetFileName's return string. 3. Make FileHandleReadLine return the right buffer size. Qiu Shumin (3): MdePkg/Library/UefiFileHandleLib: Update the module Basename and module type to 'UEFI*'. MdePkg/Library/UefiFileHandleLib: Make the FileHandleGetFileName return the file name in right format. MdePkg/Library/UefiFileHandleLib: Make FileHandleReadLine return the right buffer size. MdePkg/Include/Library/FileHandleLib.h | 2 ++ .../Library/UefiFileHandleLib/UefiFileHandleLib.c | 38 +++--- .../UefiFileHandleLib/UefiFileHandleLib.inf| 4 +-- 3 files changed, 31 insertions(+), 13 deletions(-) -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/3] MdePkg/Library/UefiFileHandleLib: Update the module Basename and module type to 'UEFI*'.
The library instance is not BASE type, to follow naming convention this patch change Basename into 'Uefi*Lib' and module type into 'UEFI_DRIVER'. Cc: Jaben Carsey jaben.car...@intel.com Cc: Liming Gao liming@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qiu Shumin shumin@intel.com --- MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf index 6c98df0..f813eae 100644 --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf @@ -13,9 +13,9 @@ [Defines] INF_VERSION= 0x00010006 - BASE_NAME = BaseFileHandleLib + BASE_NAME = UefiFileHandleLib FILE_GUID = 9495D344-9D8A-41f3-8D17-E2FD238C4E71 - MODULE_TYPE= DXE_DRIVER + MODULE_TYPE= UEFI_DRIVER VERSION_STRING = 1.0 LIBRARY_CLASS = FileHandleLib|DXE_DRIVER UEFI_APPLICATION UEFI_DRIVER DXE_RUNTIME_DRIVER -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] BaseTools: Follow PI spec to update ExtendedSize in EFI_FFS_FILE_HEADER2
Reviewed-by: Liming Gao liming@intel.com
-Original Message-
From: Zeng, Star
Sent: Friday, August 21, 2015 2:19 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming
Subject: [PATCH 1/2] BaseTools: Follow PI spec to update ExtendedSize in
EFI_FFS_FILE_HEADER2
for FFS data above 16 bytes alignment requirement.
PI spec requires FFS header to be at 8 bytes alignment to FV header.
And, FFS data alignment requires the beginning of the file data must be aligned
on a particular boundary, such as 1, 16, 128 bytes or above.
If FFS data alignment requires to be above 16 bytes, and FFS header must be at
8 byte alignment, so FFS header size must be multiple of 8.
Cc: Liming Gao liming@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
BaseTools/Source/C/Common/FirmwareVolumeBuffer.c | 4 ++--
BaseTools/Source/C/Common/FvLib.c | 4 ++--
BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
index 01d4e72..7988d8e 100644
--- a/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
+++ b/BaseTools/Source/C/Common/FirmwareVolumeBuffer.c
@@ -1,7 +1,7 @@
/** @file
EFI Firmware Volume routines which work on a Fv image in buffers.
-Copyright (c) 1999 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 1999 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution. The full text of the license may be found at @@ -864,7 +864,7 @@
Returns:
return 0;
}
if (Ffs-Attributes FFS_ATTRIB_LARGE_FILE) {
-return ((EFI_FFS_FILE_HEADER2 *)Ffs)-ExtendedSize;
+return (UINT32) ((EFI_FFS_FILE_HEADER2 *)Ffs)-ExtendedSize;
}
return FvBufExpand3ByteSize(Ffs-Size); } diff --git
a/BaseTools/Source/C/Common/FvLib.c b/BaseTools/Source/C/Common/FvLib.c
index 1b3c08b..938aa09 100644
--- a/BaseTools/Source/C/Common/FvLib.c
+++ b/BaseTools/Source/C/Common/FvLib.c
@@ -1,7 +1,7 @@
/** @file
These functions assist in parsing and manipulating a Firmware Volume.
-Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -784,7 +784,7 @@ Returns:
return 0;
}
if (FfsHeader-Attributes FFS_ATTRIB_LARGE_FILE) {
-return ((EFI_FFS_FILE_HEADER2 *)FfsHeader)-ExtendedSize;
+return (UINT32) ((EFI_FFS_FILE_HEADER2 *)FfsHeader)-ExtendedSize;
} else {
return GetLength(FfsHeader-Size);
}
diff --git a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
index ec31eab..2984860 100644
--- a/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
+++ b/BaseTools/Source/C/Include/Common/PiFirmwareFile.h
@@ -2,9 +2,9 @@
The firmware file related definitions in PI.
@par Revision Reference:
- Version 1.0.
+ Version 1.4.
- Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+ Copyright (c) 2006 - 2015, Intel Corporation. All rights
+ reserved.BR
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this @@
-110,7 +110,7 @@ typedef struct {
EFI_FFS_FILE_ATTRIBUTES Attributes;
UINT8 Size[3];
EFI_FFS_FILE_STATE State;
- UINT32 ExtendedSize;
+ UINT64 ExtendedSize;
} EFI_FFS_FILE_HEADER2;
#define MAX_FFS_SIZE0x100
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/3] NetworkPkg: Add HTTP utilities driver
Thanks Ting, I will create another patch for HttpDxe to consume
HttpUtilitiesProtocol. /Jiaxin
-Original Message-
From: Ye, Ting
Sent: Friday, August 21, 2015 1:55 PM
To: Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Fu, Siyuan
Subject: RE: [Patch 2/3] NetworkPkg: Add HTTP utilities driver
I think the below protocol attribute is incorrect. Should be updated to
PRODUCES.
gEfiHttpUtilitiesProtocolGuid ## BY_START
Also, I expect a following patch to update HttpDxe driver to remove internal
functions and consume this protocol.
Other parts are good to me.
Reviewed-by: Ye Ting ting...@intel.com
Best Regards,
Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Friday, August 21, 2015 9:37 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan
Subject: [Patch 2/3] NetworkPkg: Add HTTP utilities driver
This patch is used to add HTTP utilities driver.
Cc: Ye Ting ting...@intel.com
Cc: Siyuan Fu siyuan...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c | 126 +++
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.h | 212 +++
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf | 51 +++
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesImpl.c| 279 +++
.../HttpUtilitiesDxe/HttpUtilitiesProtocol.c | 393 +
NetworkPkg/NetworkPkg.dsc | 2 +
6 files changed, 1063 insertions(+)
create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c
create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.h
create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesImpl.c
create mode 100644 NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
diff --git a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c
b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c
new file mode 100644
index 000..6bd5b6c
--- /dev/null
+++ b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.c
@@ -0,0 +1,126 @@
+/** @file
+ The DriverEntryPoint and Unload for HttpUtilities driver.
+
+ Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+
+ This program and the accompanying materials are licensed and made
+ available under the terms and conditions of the BSD License which
+ accompanies this distribution. The full text of the license may be
+ found at http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include HttpUtilitiesDxe.h
+
+
+/**
+ Unloads an image.
+
+ @param ImageHandle Handle that identifies the image to be
unloaded.
+
+ @retval EFI_SUCCESS The image has been unloaded.
+ @retval EFI_INVALID_PARAMETER ImageHandle is not a valid image handle.
+
+**/
+EFI_STATUS
+EFIAPI
+HttpUtilitiesDxeUnload (
+ IN EFI_HANDLE ImageHandle
+ )
+{
+ EFI_STATUS Status;
+ UINTN HandleNum;
+ EFI_HANDLE *HandleBuffer;
+ UINT32 Index;
+ EFI_HTTP_UTILITIES_PROTOCOL *HttpUtilitiesProtocol;
+
+
+ HandleBuffer = NULL;
+
+ //
+ // Locate all the handles with HttpUtilities protocol.
+ //
+ Status = gBS-LocateHandleBuffer (
+ ByProtocol,
+ gEfiHttpUtilitiesProtocolGuid,
+ NULL,
+ HandleNum,
+ HandleBuffer
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+
+ for (Index = 0; Index HandleNum; Index++) {
+//
+// Firstly, find HttpUtilitiesProtocol interface
+//
+Status = gBS-OpenProtocol (
+HandleBuffer[Index],
+gEfiHttpUtilitiesProtocolGuid,
+(VOID **) HttpUtilitiesProtocol,
+ImageHandle,
+NULL,
+EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL
+);
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+
+//
+// Then, uninstall HttpUtilities interface
+//
+Status = gBS-UninstallMultipleProtocolInterfaces (
+HandleBuffer[Index],
+gEfiHttpUtilitiesProtocolGuid, HttpUtilitiesProtocol,
+NULL
+);
+if (EFI_ERROR (Status)) {
+ return Status;
+}
+ }
+
+ return EFI_SUCCESS;
+}
+
+
+/**
+ This is the declaration of an EFI image entry point. This entry point
+is
+ the same for UEFI Applications, UEFI OS Loaders, and UEFI Drivers
+including
+ both device drivers and bus drivers.
+
+ @param ImageHandle The firmware allocated handle for the UEFI
image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The operation completed successfully.
+
