mirror_edk2.git
3 years agoOvmfPkg/QemuVideoDxe: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:22:08 +0000 (21:22 +0100)]
OvmfPkg/QemuVideoDxe: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF files
Laszlo Ersek [Sat, 10 Mar 2018 22:14:30 +0000 (23:14 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF files

Among other things, the header file declares functions that are called
from the FVB protocol member functions in "FwBlockService.c", and defined
in "QemuFlash.c".

Both C files are listed in both "FvbServicesSmm.inf" and
"FvbServicesRuntimeDxe.inf", thus add the header file to both INF files as
well.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFs
Laszlo Ersek [Sat, 10 Mar 2018 22:02:32 +0000 (23:02 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFs

Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"FwBlockService.c". This way "mFvbDeviceTemplate.FwVolBlockInstance" can
be initialized near the top of "FwBlockService.c", ahead of the member
function definitions.

"FwBlockService.c" is linked into both the DXE_SMM_DRIVER and the
DXE_RUNTIME_DRIVER builds of this module, thus list the header file in
both INF files.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformPei: list "Xen.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:40:32 +0000 (22:40 +0100)]
OvmfPkg/PlatformPei: list "Xen.h" in the INF file

The header defines the OVMF_INFO_PHYSICAL_ADDRESS macro and the
EFI_XEN_OVMF_INFO structure, which are used in "Xen.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformPei: list "Platform.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:34:41 +0000 (22:34 +0100)]
OvmfPkg/PlatformPei: list "Platform.h" in the INF file

The header file declares several functions and global variables that are
shared between various translation units in this module.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformPei: list "Cmos.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:25:58 +0000 (22:25 +0100)]
OvmfPkg/PlatformPei: list "Cmos.h" in the INF file

The header file declares the CmosRead8() and CmosWrite8() functions, which
are implemented in "Cmos.c" and called from "MemDetect.c" and
"Platform.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformDxe: list "PlatformConfig.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "PlatformConfig.h" in the INF file

The header file declares the PlatformConfigSave() and PlatformConfigLoad()
functions (and defines related types and macros). The functions are
defined in "PlatformConfig.c" and called from "Platform.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformDxe: list "Platform.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "Platform.h" in the INF file

The header file defines HII-related macros and types that are shared
between the form description in "PlatformForms.vfr" and the HII driver
logic "Platform.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate
Laszlo Ersek [Sat, 10 Mar 2018 20:58:44 +0000 (21:58 +0100)]
OvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate

In edk2, we spell "static" "STATIC", plus objects with static storage
duration (esp. protocol templates) should be const-qualified (spelled
"CONST") whenever possible.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:51:48 +0000 (21:51 +0100)]
OvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file

Among other things, the header file declares the functions that implement
the VIRTIO_DEVICE_PROTOCOL members over virtio-mmio. The functions are
defined in "VirtioMmioDeviceFunctions.c", and referenced in the
initialization of "mMmioDeviceProtocolTemplate", in "VirtioMmioDevice.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:47:09 +0000 (21:47 +0100)]
OvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF file

The header file defines macros and types for "SerializeVariablesLib.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:41:36 +0000 (21:41 +0100)]
OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file

The header file declares the CreateExtraRootBusMap(),
DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are
defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:22:08 +0000 (21:22 +0100)]
OvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 20:14:06 +0000 (21:14 +0100)]
OvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files

Among other things, "DebugLibDetect.h" declares the
PlatformDebugLibIoPortFound() function. The function is called from
"DebugLib.c", which is included in both library instances. The function is
defined separately per library instance, in "DebugLibDetectRom.c" and
"DebugLibDetect.c", respectively.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 20:05:36 +0000 (21:05 +0100)]
OvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF file

The header file declares LoadNvVarsFromFs() and SaveNvVarsToFs(), which
are defined in "FsAccess.c" and called from "NvVarsFileLib.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 19:49:56 +0000 (20:49 +0100)]
OvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files

Among other things, the header file declares the AllocateAcpiNvsPool()
function. This function is called from the "LockBoxLib.c" source file (in
the implementation of the SaveLockBox() library API), which is built into
both library instances. AllocateAcpiNvsPool() is implemented separately
per library instance, in "LockBoxBase.c" and "LockBoxDxe.c", respectively.

(In the LockBoxBaseLib instance, the AllocateAcpiNvsPool() function is
never expected to be called -- the public SaveLockBox() API should never
be called before the DXE phase --, we just have to provide a stub for
linking purposes.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 19:43:36 +0000 (20:43 +0100)]
OvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file

The header file declares the InitLinuxDescriptorTables() and
SetLinuxDescriptorTables() functions, which are called from "Linux.c" and
implemented in "LinuxGdt.c".

The header file also declares the JumpToKernel() and JumpToUefiKernel()
functions, which are similarly called from "Linux.c". They are implemented
(dependent on architecture) in "Ia32/JumpToKernel.nasm" and
"X64/JumpToKernel.nasm".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file

Among other things, the header file declares the
InternalMemEncryptSevSetMemoryDecrypted() and
InternalMemEncryptSevSetMemoryEncrypted() functions. The functions are
called from "X64/MemEncryptSevLib.c", and defined in
"X64/VirtualMemory.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files

The header file declares the InternalAcpiGetTimerTick() function. The
function is called from "AcpiTimerLib.c", which is built into all three
library instances. The function is defined individually per library
instance, in "BaseRomAcpiTimerLib.c", "BaseAcpiTimerLib.c", and
"DxeAcpiTimerLib.c" (enumerated in increasing firmware phase order).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/IoMmuDxe: list "AmdSevIoMmu.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/IoMmuDxe: list "AmdSevIoMmu.h" in the INF file

The header file declares the AmdSevInstallIoMmuProtocol() function, which
is implemented in "AmdSevIoMmu.c" and called from "IoMmuDxe.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/EmuVariableFvbRuntimeDxe: list "Fvb.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/EmuVariableFvbRuntimeDxe: list "Fvb.h" in the INF file

Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"Fvb.c". This way "mEmuVarsFvb.FwVolBlockInstance" can be initialized near
the top of "Fvb.c", ahead of the member function definitions.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/CsmSupportLib: list "LegacyRegion.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyRegion.h" in the INF file

Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_REGION2_PROTOCOL member functions that are defined in
"LegacyRegion.c". This way "mLegacyRegion2" can be initialized near the
top of "LegacyRegion.c", ahead of the member function definitions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/CsmSupportLib: list "LegacyPlatform.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyPlatform.h" in the INF file

The header file defines types and macros for "LegacyPlatform.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/CsmSupportLib: list "LegacyInterrupt.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyInterrupt.h" in the INF file

Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_INTERRUPT_PROTOCOL member functions that are defined in
"LegacyInterrupt.c". This way "mLegacyInterrupt" can be initialized near
the top of "LegacyInterrupt.c", ahead of the member function definitions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/CsmSupportLib: list "CsmSupportLib.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "CsmSupportLib.h" in the INF file

The header file declares the functions LegacyRegionInit(),
LegacyInterruptInstall() and LegacyBiosPlatformInstall(). They are defined
in "LegacyRegion.c", "LegacyInterrupt.c", and "LegacyPlatform.c",
respectively, and are all called from CsmSupportLibConstructor() in
"CsmSupportLib.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/CsmSupportLib: sort [Sources*] sections in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:45:45 +0000 (19:45 +0100)]
OvmfPkg/CsmSupportLib: sort [Sources*] sections in the INF file

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/BlockMmioToBlockIoDxe: list "BlockIo.h" in the INF file
Laszlo Ersek [Sat, 10 Mar 2018 18:42:15 +0000 (19:42 +0100)]
OvmfPkg/BlockMmioToBlockIoDxe: list "BlockIo.h" in the INF file

Among other things, the header file declares the
"gBlockMmioToBlockIoComponentName" and "gBlockMmioToBlockIoComponentName2"
protocol instance structures. They are defined and initialized in
"ComponentName.c" and installed in "BlockIo.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 18:16:02 +0000 (19:16 +0100)]
OvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF files

"QemuLoader.h" defines the command structures of QEMU's ACPI
linker/loader. The client code is in "QemuFwCfgAcpi.c", which is part of
both builds of this driver.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"
Laszlo Ersek [Sat, 10 Mar 2018 17:26:36 +0000 (18:26 +0100)]
OvmfPkg/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"

We added initial support for QEMU's ACPI linker/loader in commit
a618eaa1f45d ("OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU
interface", 2014-06-19). This commit defined the command structures in the
new file "QemuLoader.h", and #included the header in the preexistent
"Qemu.c" file, where the initial command script processing loop was being
implemented.

In commit 14b0faadfc87 ("OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a
new file", 2015-02-02), we extracted the -- by then, more advanced --
linker/loader script processing from "Qemu.c" to "QemuFwCfgAcpi.c".
"Qemu.c" was going to need "QemuLoader.h" no longer, but we forgot to make
the #include directive unique to the new "QemuFwCfgAcpi.c" file. Do it
now.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 17:13:18 +0000 (18:13 +0100)]
OvmfPkg/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF files

Among other things, the header file declares InstallAcpiTables(). This
function is called from AcpiPlatformEntryPoint() -- the entry point of
both INF files, defined in the common "EntryPoint.c" file --, and it is
defined (dependent on INF file) in "AcpiPlatform.c" or
"QemuFwCfgAcpiPlatform.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/AcpiPlatformDxe: sort [Sources*] sections in the INF files
Laszlo Ersek [Sat, 10 Mar 2018 17:10:02 +0000 (18:10 +0100)]
OvmfPkg/AcpiPlatformDxe: sort [Sources*] sections in the INF files

This makes it easier to insert future source files, and to see the source
files that are unique to either INF file. No functional changes.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: list "PrePi.h" in INF file
Laszlo Ersek [Sat, 10 Mar 2018 16:54:24 +0000 (17:54 +0100)]
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: list "PrePi.h" in INF file

Among other things, the header file declares the ArchInitialize()
function, which is called from "PrePi.c", and implemented (dependent on
architecture) in "AArch64/ArchPrePi.c" and "Arm/ArchPrePi.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: sort [Sources*] sections in INF
Laszlo Ersek [Sat, 10 Mar 2018 17:06:10 +0000 (18:06 +0100)]
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: sort [Sources*] sections in INF

This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoArmVirtPkg/PlatformBootManagerLib: list "PlatformBm.h" in INF file
Laszlo Ersek [Sat, 10 Mar 2018 16:44:54 +0000 (17:44 +0100)]
ArmVirtPkg/PlatformBootManagerLib: list "PlatformBm.h" in INF file

The header file declares TryRunningQemuKernel(), defined in "QemuKernel.c"
and called from "PlatformBm.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoMdeModulePkg PCD: Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET
Star Zeng [Tue, 13 Mar 2018 09:03:11 +0000 (17:03 +0800)]
MdeModulePkg PCD: Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET

Remove PCD_TYPE_SKU_ENABLED in PCD_TYPE_ALL_SET.
This change was missing at e8d2a9805286a2fd4f613697cf0cccb4a1ebc90d.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eric Dong <eric.dong@intel.com>
3 years agoNetworkPkg/IScsiDxe: Fix the ISCSI connection failure in certain case.
Jiaxin Wu [Mon, 12 Mar 2018 00:50:12 +0000 (08:50 +0800)]
NetworkPkg/IScsiDxe: Fix the ISCSI connection failure in certain case.

The ISCSI connection will fail for the first time if the target info is
retrieved from DHCP and expressed as URI format. The issue is caused by
the missing DNS protocol dependency check during the driver support
function.

This patch is to fix the above issue.

Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoMdeModulePkg/Mtftp4Dxe: Fix the incorrect return status.
Jiaxin Wu [Mon, 12 Mar 2018 00:50:41 +0000 (08:50 +0800)]
MdeModulePkg/Mtftp4Dxe: Fix the incorrect return status.

The incorrect return status was caused by the commit of 39b0867d, which
was to resolve the token status error that does not compliance with spec
definition, but it results the protocol status not compliance with spec
definition.

This patch is to resolve above issue.

Cc: Wang Fan <fan.wang@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wang, Fan <fan.wang@intel.com>
3 years agoMdeModulePkg PCD: Remove unused PCD attribute PCD_TYPE_SKU_ENABLED
Gao, Liming [Wed, 7 Mar 2018 08:15:18 +0000 (16:15 +0800)]
MdeModulePkg PCD: Remove unused PCD attribute PCD_TYPE_SKU_ENABLED

PcdDb optimization has handled PCD DB for each SKU, not for single PCD.
So, this PCD attribute is not used any more.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoBaseTools: Get Pcd DatumType from DEC file for --pcd
Yonghong Zhu [Mon, 12 Mar 2018 07:09:03 +0000 (15:09 +0800)]
BaseTools: Get Pcd DatumType from DEC file for --pcd

It is regression bug that missing the Pcd DatumType info from DEC file
for --pcd .

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoIntelSiliconPkg/Vtd: Add missing dump in ExtContext.
Jiewen Yao [Fri, 9 Mar 2018 03:50:58 +0000 (11:50 +0800)]
IntelSiliconPkg/Vtd: Add missing dump in ExtContext.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump
Jiewen Yao [Thu, 8 Mar 2018 12:40:57 +0000 (20:40 +0800)]
IntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex
Laszlo Ersek [Fri, 9 Mar 2018 19:06:31 +0000 (20:06 +0100)]
SecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex

TcgPei doesn't actually use the PEI-phase read-only variable service, so
drop that from the Depex.

This patch was inspired by commit ab9e11da6651 ("SecurityPkg/Tcg2Pei: drop
PeiReadOnlyVariable from Depex", 2018-03-09).

Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/Tcg2ConfigPei: trivial coding style updates
Laszlo Ersek [Fri, 9 Mar 2018 18:54:20 +0000 (19:54 +0100)]
OvmfPkg/Tcg2ConfigPei: trivial coding style updates

- the @file comment block should match between INF and main C file

- rewrap / refill columns to 79 characters

- insert space before opening paren

- prefix and suffix //-style comment block with empty // lines

- fix indentation of arguments in multi-line function call

- general tab spacing (indent step) is 2 in edk2, unlike QEMU's 4

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
Brijesh Singh [Fri, 9 Mar 2018 16:06:03 +0000 (10:06 -0600)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active

Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
early in DXE phase and clears the C-bit from NonExistent entry -- which
is later split and accommodate the flash MMIO. When SMM is enabled, we
build two sets of page tables; first page table is used when executing
code in non SMM mode (SMM-less-pgtable) and second page table is used
when we are executing code in SMM mode (SMM-pgtable).

During boot time, AmdSevDxe driver clears the C-bit from the
SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used
from SMM mode.

In this patch we explicitly clear the C-bit from Qemu flash MMIO range
before we probe the flash. When OVMF is built with SMM_REQUIRE then
call to initialize the flash services happen after the SMM-pgtable is
created and processor has served the first SMI. At this time we will
have access to the SMM-pgtable.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
[lersek@redhat.com: trivial coding style improvements]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
Marc-André Lureau [Thu, 22 Feb 2018 18:10:03 +0000 (19:10 +0100)]
OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe

The library registers a security management handler, to measure images
that are not measure in PEI phase. For example with the qemu PXE rom:

Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi

And the following binary_bios_measurements log entry seems to be
added:

PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER      size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4

The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:

(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
    protocol sometime in the DXE phase (assuming a TPM2 chip is present,
    reported via PcdTpmInstanceGuid).

(2) The DXE core finds that no more drivers are left to dispatch from
    DXEFV, and we enter the BDS phase.

(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
    non-recursively, producing PciIo instances and discovering PCI
    oproms.

(4) The dispatching of images that don't originate from FVs is deferred
    at this point, by
    "MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".

(5) OVMF's PlatformBootManagerLib signals EndOfDxe.

(6) OVMF's PlatformBootManagerLib calls
    EfiBootManagerDispatchDeferredImages() -- the images deferred in
    step (4) are now dispatched.

(7) Image dispatch invokes the Security / Security2 Arch protocols
    (produced by SecurityStubDxe). In this patch, we hook
    DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
    will try to locate the TCG2 protocol, and measure the image into the
    TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
    will always be found and used (assuming a TPM2 chip is present).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: include Tcg2Dxe module
Marc-André Lureau [Thu, 22 Feb 2018 16:53:16 +0000 (17:53 +0100)]
OvmfPkg: include Tcg2Dxe module

This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.

The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:

[    0.000000] efi: EFI v2.70 by EDK II
[    0.000000] efi:  SMBIOS=0x3fa1f000  ACPI=0x3fbb6000  ACPI 2.0=0x3fbb6014  MEMATTR=0x3e7d4318  TPMEventLog=0x3db21018

$ python chipsec_util.py tpm parse_log binary_bios_measurements

[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']

PCR: 0 type: EV_S_CRTM_VERSION                size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x820000 length: 0xe0000
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x900000 length: 0xa00000
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4 type: EV_EFI_ACTION                    size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473

$ tpm2_pcrlist
sha1 :
  0  : 35bd1786b6909daad610d7598b1d620352d33b8a
  1  : ec0511e860206e0af13c31da2f9e943fb6ca353d
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : 45a323382bd933f08e7f0e256bc8249e4095b1ec
  5  : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
  6  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  7  : 518bd167271fbb64589c61e43d8c0165861431d8
  8  : 0000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000
sha256 :
  0  : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
  1  : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
  2  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  3  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  4  : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
  5  : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
  6  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  7  : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
  8  : 0000000000000000000000000000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :

The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.

Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:

  * We have a library class called Tpm2DeviceLib -- this is basically the
  set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
  Its leading comment says "This library abstract how to access TPM2
  hardware device".

  There are two *sets* of APIs in "Tpm2DeviceLib.h":

  (a) functions that deal with the TPM2 device:
      - Tpm2RequestUseTpm(),
      - Tpm2SubmitCommand()

      This set of APIs is supposed to be used by clients that *consume*
      the TPM2 device abstraction.

  (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
      used by *providers* of various TPM2 device abstractions.

  * Then, we have two implementations (instances) of the Tpm2DeviceLib class:
  (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
  (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf

  (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
  APIs listed under (a), and it does not implement (b) -- see
  EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
  drivers that *consume* the TPM2 device abstraction. And, the (a) group
  of APIs is implemented by forwarding the requests to the TCG2 protocol.

  The idea here is that all the drivers that consume the TPM2 abstraction
  do not have to be statically linked with a large TPM2 device library
  instance; instead they are only linked (statically) with this "thin"
  library instance, and all the actual work is delegated to whichever
  driver that provides the singleton TCG2 protocol.

  (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
  for the driver that offers (produces) the TCG2 protocol. This lib
  instance implements both (a) and (b) API groups.

  * Here's how things fit together:

  (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
  library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
  via NULL class resolution. This simply means that before the
  "Tcg2Dxe.inf" entry point function is entered, the constructor function
  of "Tpm2InstanceLibDTpm.inf" will be called.

  (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
  registers its own actual TPM2 command implementation with the
  "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
  driver). This provides the back-end for the API set (a).

         TCG2 protocol provider (Tcg2Dxe.inf driver) launches
                      |
                      v
    NULL class: Tpm2InstanceLibDTpm instance construction
                      |
                      v
    Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
           backend registration for API set (a)

  (iii) The Tcg2Dxe driver exposes the TCG2 protocol.

  (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
  land in Tcg2Dxe, via the protocol.

  (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
  from lib instance (2).

  (vi) Those functions call the "backend" functions registered by
  Tpm2DeviceLibDTpm in step (ii).

       TPM 2 consumer driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
                |
                v
         TCG2 protocol interface
                |
                v
  TCG2 protocol provider: Tcg2Dxe.inf driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
                |
                v
     NULL class: Tpm2InstanceLibDTpm instance
        (via earlier registration)
                |
                v
       TPM2 chip (actual hardware)

  * So that is the "router" pattern in edk2. Namely,

  - Consumers of an abstraction use a thin library instance.

  - The thin library instance calls a firmware-global (singleton) service,
    i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).

  - The PEIM providing the PPI, or the DXE driver providing the protocol,
    don't themselves implement the actual service either. Instead they
    offer a "registration" service too, and they only connect the incoming
    "consumer" calls to the earlier registered back-end(s).

  - The "registration service", for back-ends to use, may take various
    forms.

    It can be exposed globally to the rest of the firmware, as
    another member function of the PPI / protocol structure. Then backends
    can be provided by separate PEIMs / DXE drivers.

    Or else, the registration service can be exposed as just another
    library API. In this case, the backends are provided as NULL class
    library instances, and a platform  DSC file links them into the PEIM /
    DXE driver via NULL class resolutions. The backend lib instances call
    the registration service in their own respective constructor
    functions.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: include Tcg2Pei module
Marc-André Lureau [Thu, 22 Feb 2018 14:26:34 +0000 (15:26 +0100)]
OvmfPkg: include Tcg2Pei module

This module will initialize TPM device, measure reported FVs and BIOS
version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format
compatibility, but the SHA-256 measurements and TCG 2 log format are
now recommended.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: add customized Tcg2ConfigPei clone
Marc-André Lureau [Thu, 22 Feb 2018 13:20:58 +0000 (14:20 +0100)]
OvmfPkg: add customized Tcg2ConfigPei clone

The Tcg2ConfigPei module informs the firmware globally about the TPM
device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
GUID value. The original module under SecurityPkg can perform device
detection, or read a cached value from a non-volatile UEFI variable.

OvmfPkg's clone of the module only performs the TPM2 hardware detection.

This is what the module does:

- Check the QEMU hardware for TPM2 availability only

- If found, set the dynamic PCD "PcdTpmInstanceGuid" to
  &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of
  the firmware about the TPM type.

- Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
  PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
  In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
  and the consumption of the "TPM type" PCD.

- If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
  (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
  no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: simplify SecurityStubDxe.inf inclusion
Marc-André Lureau [Mon, 5 Mar 2018 16:14:18 +0000 (17:14 +0100)]
OvmfPkg: simplify SecurityStubDxe.inf inclusion

SecurityStubDxe.inf should be included unconditionally.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo
Marc-André Lureau [Fri, 2 Mar 2018 17:19:33 +0000 (18:19 +0100)]
MdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo

No functional changes.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex
Marc-André Lureau [Thu, 1 Mar 2018 15:09:39 +0000 (16:09 +0100)]
SecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex

The module doesn't use read-only variable.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoBaseTools: GlobalData remove unused variable
Carsey, Jaben [Thu, 8 Mar 2018 00:45:18 +0000 (08:45 +0800)]
BaseTools: GlobalData remove unused variable

gWideStringPattern is not used.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools: Fix parse OFFSET_OF get wrong offset
Feng, YunhuaX [Fri, 9 Mar 2018 08:46:00 +0000 (16:46 +0800)]
BaseTools: Fix parse OFFSET_OF get wrong offset

Fix parse OFFSET_OF get wrong offset

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools: Fix a bug for --pcd used in ConditionalStatement calculate
Yonghong Zhu [Fri, 9 Mar 2018 07:18:35 +0000 (15:18 +0800)]
BaseTools: Fix a bug for --pcd used in ConditionalStatement calculate

Move the GlobalData.BuildOptionPcd before FdfParser() function and add
type check for Pcd item.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Update --pcd parser to support flexible pcd format
Yonghong Zhu [Wed, 7 Mar 2018 06:14:43 +0000 (14:14 +0800)]
BaseTools: Update --pcd parser to support flexible pcd format

This patch update --pcd parser to support flexible pcd format.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Fixed Pcd from command line issue.
BobCF [Thu, 8 Mar 2018 05:56:21 +0000 (13:56 +0800)]
BaseTools: Fixed Pcd from command line issue.

Save the pcd command line value in Pcd object

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoIntelSiliconPkg/Vtd: Add MapHandleInfo in VtdDxe.
Jiewen Yao [Thu, 8 Mar 2018 11:42:49 +0000 (19:42 +0800)]
IntelSiliconPkg/Vtd: Add MapHandleInfo in VtdDxe.

This information is to record which device requested which DMA buffer.
It can be used for DMA buffer analysis.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg: also clear HashInterfaceHob.SupportedHashMask
Marc-Andr? Lureau [Wed, 7 Mar 2018 15:57:39 +0000 (23:57 +0800)]
SecurityPkg: also clear HashInterfaceHob.SupportedHashMask

Commit 4cc2b63bd829426b05bad0d8952f1855a10d6ed7 fixed an out of bounds
ZeroMem() call. However, as Laszlo Ersek pointed out, the intent was
to clear all but the Identifier (to revert the effect of
RegisterHashInterfaceLib()). For that, it should clear the
SupportedHashMask too.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg OpalPasswordExtraInfoVariable.h: Remove it
Star Zeng [Tue, 6 Mar 2018 13:47:06 +0000 (21:47 +0800)]
SecurityPkg OpalPasswordExtraInfoVariable.h: Remove it

Remove OpalPasswordExtraInfoVariable.h as it is not been used
anymore.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPasswordSupportLib: Remove it
Star Zeng [Sun, 11 Feb 2018 06:40:03 +0000 (14:40 +0800)]
SecurityPkg OpalPasswordSupportLib: Remove it

Remove OpalPasswordSupportLib as it is not been used
anymore.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPassword: Remove old solution
Star Zeng [Tue, 6 Mar 2018 13:43:20 +0000 (21:43 +0800)]
SecurityPkg OpalPassword: Remove old solution

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPassword: Add solution without SMM device code
Star Zeng [Sun, 11 Feb 2018 03:00:44 +0000 (11:00 +0800)]
SecurityPkg OpalPassword: Add solution without SMM device code

After IOMMU is enabled in S3, original solution with SMM device
code (OpalPasswordSmm) to unlock OPAL device for S3 will not work
as the DMA operation will be aborted without granted DMA buffer.
Instead, this solution is to add OpalPasswordPei to eliminate
SMM device code, and OPAL setup UI produced by OpalPasswordDxe
will be updated to send requests (set password, update password,
and etc), and then the requests will be processed in next boot
before SmmReadyToLock, password and device info will be saved to
lock box used by OpalPasswordPei to unlock OPAL device for S3.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg TcgStorageCoreLib: Make it be base type really
Star Zeng [Tue, 6 Mar 2018 13:37:22 +0000 (21:37 +0800)]
SecurityPkg TcgStorageCoreLib: Make it be base type really

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg TcgStorageOpalLib: Make it be base type really
Star Zeng [Mon, 15 Jan 2018 10:42:02 +0000 (18:42 +0800)]
SecurityPkg TcgStorageOpalLib: Make it be base type really

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY
Star Zeng [Sun, 11 Feb 2018 02:01:21 +0000 (10:01 +0800)]
MdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY

With this flag, the LockBox can be restored in S3 resume only.
The LockBox can not be restored after SmmReadyToLock in normal boot
and after EndOfS3Resume in S3 resume.
It can not be set together with LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoUefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory
Jian J Wang [Fri, 2 Mar 2018 02:46:05 +0000 (10:46 +0800)]
UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory

if PcdDxeNxMemoryProtectionPolicy is enabled for EfiReservedMemoryType
of memory, #PF will be triggered for each APs after ExitBootServices
in SCRT test. The root cause is that AP wakeup code executed at that
time is stored in memory of type EfiReservedMemoryType (referenced by
global mReservedApLoopFunc), which is marked as non-executable.

This patch fixes this issue by setting memory of mReservedApLoopFunc to
be executable immediately after allocation.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/Core: fix too many available pages between BS_Data
Jian J Wang [Wed, 7 Mar 2018 03:26:32 +0000 (11:26 +0800)]
MdeModulePkg/Core: fix too many available pages between BS_Data

The root cause is an unnecessary check to Size parameter in function
AdjustMemoryS(). It will cause one standalone free page (happen to have
Guard page around) in the free memory list cannot be allocated, even if
the requested memory size is less than a page.

  //
  // At least one more page needed for Guard page.
  //
  if (Size < (SizeRequested + EFI_PAGES_TO_SIZE (1))) {
    return 0;
  }

The following code in the same function actually covers above check
implicitly. So the fix is simply removing above check.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg/SmmTcg2PhysicalPresenceLib: Fix coding style issue
Dandan Bi [Wed, 7 Mar 2018 05:24:37 +0000 (13:24 +0800)]
SecurityPkg/SmmTcg2PhysicalPresenceLib: Fix coding style issue

Boolean values do not need to use explicit comparisons
to TRUE or FALSE.

Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by:Chao Zhang <chao.b.zhang@intel.com>

3 years agoUefiCpuPkg/CpuCommonFeaturesLib: Fix coding style issue
Dandan Bi [Wed, 7 Mar 2018 05:20:29 +0000 (13:20 +0800)]
UefiCpuPkg/CpuCommonFeaturesLib: Fix coding style issue

Boolean values do not need to use explicit comparisons
to TRUE or FALSE.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/DriverSampleDxe: Refine the sample case for UNION type
Dandan Bi [Wed, 7 Mar 2018 02:34:00 +0000 (10:34 +0800)]
MdeModulePkg/DriverSampleDxe: Refine the sample case for UNION type

The example of UNION storage is not good, now update it.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX
Laszlo Ersek [Wed, 7 Mar 2018 09:17:28 +0000 (10:17 +0100)]
BaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX

I recently added the gcc-8 specific "-Wno-stringop-truncation" and
"-Wno-restrict" options to BUILD_CFLAGS, both for "Darwin" (XCODE5 /
clang, OSX) and otherwise (gcc, Linux / Cygwin).

I also regression-tested the change with gcc-4.8 on Linux -- gcc-4.8 does
not know either of the (gcc-8 specific) "-Wno-stringop-truncation" and
"-Wno-restrict" options, yet the build completed fine (by GCC design).

Regarding OSX, my expectation was that

- XCODE5 / clang would either recognize these warnings options (because
  clang does recognize most -W options of gcc),

- or, similarly to gcc, clang would simply ignore the "-Wno-xxx" flags
  that it didn't recognize.

Neither is the case; the new flags have broken the BaseTools build on OSX.
Revert them (for OSX only).

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Liming Gao <liming.gao@intel.com>
Fixes: 1d212a83df0eaf32a6f5d4159beb2d77832e0231
Fixes: 9222154ae7b3eef75ae88cdb56158256227cb929
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoSecurityPkg: only clear HashInterface information
Marc-Andr? Lureau [Tue, 6 Mar 2018 20:27:18 +0000 (04:27 +0800)]
SecurityPkg: only clear HashInterface information

The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. Instead, just clear the HashInterface fields, as
I suppose was originally intended.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/Core: Fix feature conflict between NX and Stack guard
Hao Wu [Tue, 6 Mar 2018 11:34:38 +0000 (19:34 +0800)]
MdeModulePkg/Core: Fix feature conflict between NX and Stack guard

If enabled, NX memory protection feature will mark some types of active
memory as NX (non-executable), which includes the first page of the stack.
This will overwrite the attributes of the first page of the stack if the
stack guard feature is also enabled.

The solution is to override the attributes setting to the first page of
the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack
guard feature is enabled.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/Core: Refine handling NULL detection in NX setting
Hao Wu [Tue, 6 Mar 2018 10:36:37 +0000 (18:36 +0800)]
MdeModulePkg/Core: Refine handling NULL detection in NX setting

The commit rewrites the logic in function
InitializeDxeNxMemoryProtectionPolicy() for handling the first page
(page 0) when NULL pointer detection feature is enabled.

Instead of skip setting the page 0, the codes will now override the
attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute.

The purpose is to make it easy for other special handling of pages
(e.g. the first page of the stack when stack guard feature is enabled).

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoShellBinPkg: Ia32/X64 Shell binary update.
Ruiyu Ni [Wed, 7 Mar 2018 08:30:32 +0000 (16:30 +0800)]
ShellBinPkg: Ia32/X64 Shell binary update.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/UefiBootManagerLib: limit recursive call depth
Heyi Guo [Thu, 1 Mar 2018 02:39:32 +0000 (10:39 +0800)]
MdeModulePkg/UefiBootManagerLib: limit recursive call depth

Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and another reconnect. The
endless iteration will cause stack overflow and then system exception,
and it may be not easy to find that the exception is actually caused
by stack overflow.

So we limit the number of reconnect retry to 10 to improve code
robustness, and DEBUG_CODE is moved ahead before recursive repair to
track the repair result.

We also remove a duplicated declaration of BmRepairAllControllers() in
InternalBm.h in this patch, for it is only a trivial change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest
Ruiyu Ni [Tue, 6 Mar 2018 03:31:57 +0000 (11:31 +0800)]
MdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest

CompatibleRangeTest() contains two bugs:
1. It doesn't reject the memory above 16MB
2. it cannot handle the case when the partial or whole range of
   requested memory is already tested.

The patch fixes the two bugs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/NullMemoryTest: Change prototype of ConvertToTestedMemory
Ruiyu Ni [Tue, 6 Mar 2018 03:04:27 +0000 (11:04 +0800)]
MdeModulePkg/NullMemoryTest: Change prototype of ConvertToTestedMemory

The patch should not impact the functionality.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts
Marc Zyngier [Tue, 6 Mar 2018 13:00:35 +0000 (13:00 +0000)]
ArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts

The generic timer driver only EOIs the timer interrupt if
the ISTATUS bit is set. This is completely fine if you pretend
that spurious interrupts do not exist. But as a matter of fact,
they do, and the first one will leave the interrupt activated
at the GIC level, making sure that no other interrupt can make
it anymore.

Making sure that each interrupt Ack is paired with an EOI is the
way to go. Oh, and enabling the interrupt each time it is taken
is completely pointless. We entered this function for a good
reason...

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoIntelSiliconPkg VTdPmrPei: Add PcdVTdPeiDmaBufferSize(S3)
Star Zeng [Mon, 5 Mar 2018 14:10:16 +0000 (22:10 +0800)]
IntelSiliconPkg VTdPmrPei: Add PcdVTdPeiDmaBufferSize(S3)

Add PcdVTdPeiDmaBufferSize(S3) to replace the hard coded value
TOTAL_DMA_BUFFER_SIZE and TOTAL_DMA_BUFFER_SIZE_S3 in IntelVTdPmrPei.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoIntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap
Star Zeng [Wed, 14 Feb 2018 09:10:36 +0000 (17:10 +0800)]
IntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap

NULL is returned to Mapping when Operation is BusMasterCommonBuffer or
BusMasterCommonBuffer64 in PeiIoMmuMap().
So Mapping == NULL is valid when calling PeiIoMmuUnmap().

940dbd071e9f01717236af236740aa0da716805f wrongly changed EFI_SUCCESS
to EFI_INVALID_PARAMETER when Mapping == NULL in PeiIoMmuUnmap().
This patch is to correct it.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoOvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 21:05:55 +0000 (22:05 +0100)]
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map

Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:

  [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
  http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
  https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html

Original commit message from Brijesh:

> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
> both guest and hypervisor. Since the data need to be accessed by both
> hence we must map the SMMSaved State area as unencrypted (i.e C-bit
> cleared).
>
> This patch clears the SavedStateArea address before SMBASE relocation.
> Currently, we do not clear the SavedStateArea address after SMBASE is
> relocated due to the following reasons:
>
> 1) Guest BIOS never access the relocated SavedStateArea.
>
> 2) The C-bit works on page-aligned address, but the SavedStateArea
> address is not a page-aligned. Theoretically, we could roundup the
> address and clear the C-bit of aligned address but looking carefully we
> found that some portion of the page contains code -- which will causes a
> bigger issue for the SEV guest. When SEV is enabled, all the code must
> be encrypted otherwise hardware will cause trap.

Changes by Laszlo:

- separate AmdSevDxe bits from SmmCpuFeaturesLib bits;

- spell out PcdLib dependency with #include and in LibraryClasses;

- replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation
  with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages()
  function;

- consequently, pass page-aligned BaseAddress to
  MemEncryptSevClearPageEncMask();

- zero the pages before clearing the C-bit;

- pass Flush=TRUE to MemEncryptSevClearPageEncMask();

- harden the treatment of MemEncryptSevClearPageEncMask() failure.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map
Laszlo Ersek [Thu, 1 Mar 2018 19:59:12 +0000 (20:59 +0100)]
OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map

Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:

  [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
  http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
  https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html

Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the
initial SMRAM save state map can be re-encrypted (including zeroing them
out after setting the C-bit on them), and they can be released to DXE for
general use (undoing the allocation that we did in PlatformPei's
AmdSevInitialize() function).

The decryption of the same pages (which will occur chronologically
earlier) is implemented in the next patch; hence the "re-encryption" part
of this patch is currently a no-op. The series is structured like this in
order to be bisection-friendly. If the decryption patch preceded this
patch, then an info leak would be created while standing between the
patches.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 16:59:19 +0000 (17:59 +0100)]
OvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map

In the next two patches, we'll temporarily decrypt the pages containing
the initial SMRAM save state map, for SMBASE relocation. (Unlike the
separate, relocated SMRAM save state map of each VCPU, the original,
shared map behaves similarly to a "common buffer" between guest and host.)
The decryption will occur near the beginning of the DXE phase, in
AmdSevDxe, and the re-encryption will occur in PiSmmCpuDxeSmm, via OVMF's
SmmCpuFeaturesLib instance.

There is a non-trivial time gap between these two points, and the DXE
phase might use the pages overlapping the initial SMRAM save state map for
arbitrary purposes meanwhile. In order to prevent any information leak
towards the hypervisor, make sure the DXE phase puts nothing in those
pages until re-encryption is done.

Creating a memalloc HOB for the area in question is safe:

- the temporary SEC/PEI RAM (stack and heap) is based at
  PcdOvmfSecPeiTempRamBase, which is above 8MB,

- the permanent PEI RAM (installed in PlatformPei's PublishPeiMemory()
  function) never starts below PcdOvmfDxeMemFvBase, which is also above
  8MB.

The allocated pages can be released to the DXE phase after SMBASE
relocation and re-encryption are complete.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 16:31:44 +0000 (17:31 +0100)]
OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map

In the next three patches, we're going to modify three modules under
OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest,
each affected module will have to know the page range that covers the
initial (pre-SMBASE relocation) SMRAM save state map. Add a helper
function to MemEncryptSevLib that calculates the "base address" and
"number of pages" constants for this page range.

(In a RELEASE build -- i.e., with assertions disabled and optimization
enabled --, the helper function can be compiled to store two constants
determined at compile time.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: refresh #includes and LibraryClasses
Laszlo Ersek [Thu, 1 Mar 2018 20:43:09 +0000 (21:43 +0100)]
OvmfPkg/AmdSevDxe: refresh #includes and LibraryClasses

List those and only those libraries that are used.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 14:02:11 +0000 (15:02 +0100)]
OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: rewrap to 79 characters width
Laszlo Ersek [Thu, 1 Mar 2018 13:32:23 +0000 (14:32 +0100)]
OvmfPkg/AmdSevDxe: rewrap to 79 characters width

There are many overlong lines; it's hard to work with the module like
this. Rewrap all files to 79 columns.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClasses
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClasses

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keyword
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keyword

In edk2, the "static" keyword is spelled "STATIC". Also let "STATIC" stand
alone on a line in function definitions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns
Laszlo Ersek [Thu, 1 Mar 2018 17:55:09 +0000 (18:55 +0100)]
OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns

There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.

(

The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset"
arrays was verified by hexdumping the arrays in
SmmCpuFeaturesLibConstructor(), both before and after the patch, and
comparing the dumps.

Contents of "mSmmCpuRegisterRanges", IA32 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 14 00 00 00
> mSmmCpuRegisterRanges: 000010 2E 00 00 00 1B 00 00 00 33 00 00 00 36 00 00 00
> mSmmCpuRegisterRanges: 000020 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuRegisterRanges", X64 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000010 14 00 00 00 2E 00 00 00 1B 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000020 33 00 00 00 36 00 00 00 04 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuWidthOffset", both IA32 and X64 builds:

> mSmmCpuWidthOffset: {
> mSmmCpuWidthOffset: 000000 00 00 00 00 00 00 00 00 00 00 00 08 00 00 68 02
> mSmmCpuWidthOffset: 000010 6C 02 00 00 00 08 00 00 88 02 8C 02 00 00 00 08
> mSmmCpuWidthOffset: 000020 00 00 78 02 7C 02 00 00 00 00 00 00 64 02 68 02
> mSmmCpuWidthOffset: 000030 00 00 00 00 00 00 84 02 88 02 00 00 00 00 00 00
> mSmmCpuWidthOffset: 000040 74 02 78 02 00 00 00 00 00 00 00 00 04 00 00 00
> mSmmCpuWidthOffset: 000050 04 04 A8 03 00 02 00 00 00 00 04 04 AC 03 10 02
> mSmmCpuWidthOffset: 000060 00 00 00 00 04 04 B0 03 20 02 00 00 00 00 04 04
> mSmmCpuWidthOffset: 000070 B4 03 30 02 00 00 00 00 04 04 B8 03 40 02 00 00
> mSmmCpuWidthOffset: 000080 00 00 04 04 BC 03 50 02 00 00 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000090 70 02 00 00 00 00 04 04 C4 03 90 02 00 00 00 00
> mSmmCpuWidthOffset: 0000A0 04 08 C8 03 60 03 64 03 00 00 04 08 CC 03 68 03
> mSmmCpuWidthOffset: 0000B0 6C 03 00 00 00 08 00 00 B8 03 BC 03 01 00 00 08
> mSmmCpuWidthOffset: 0000C0 00 00 B0 03 B4 03 01 00 00 08 00 00 A8 03 AC 03
> mSmmCpuWidthOffset: 0000D0 01 00 00 08 00 00 A0 03 A4 03 01 00 00 08 00 00
> mSmmCpuWidthOffset: 0000E0 98 03 9C 03 01 00 00 08 00 00 90 03 94 03 01 00
> mSmmCpuWidthOffset: 0000F0 00 08 00 00 88 03 8C 03 01 00 00 08 00 00 80 03
> mSmmCpuWidthOffset: 000100 84 03 01 00 04 08 D0 03 F8 03 FC 03 01 00 04 08
> mSmmCpuWidthOffset: 000110 DC 03 E0 03 E4 03 01 00 04 08 D4 03 F0 03 F4 03
> mSmmCpuWidthOffset: 000120 01 00 04 08 D8 03 E8 03 EC 03 01 00 04 08 E0 03
> mSmmCpuWidthOffset: 000130 D8 03 DC 03 01 00 04 08 E4 03 D0 03 D4 03 01 00
> mSmmCpuWidthOffset: 000140 04 08 E8 03 C8 03 CC 03 01 00 04 08 EC 03 C0 03
> mSmmCpuWidthOffset: 000150 C4 03 01 00 04 08 F0 03 78 03 7C 03 01 00 04 08
> mSmmCpuWidthOffset: 000160 F4 03 70 03 74 03 01 00 04 08 FC 03 58 03 5C 03
> mSmmCpuWidthOffset: 000170 00 00 04 08 F8 03 50 03 54 03 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000180 48 03 4C 03 00 00
> mSmmCpuWidthOffset: }

)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/PlatformPei: sort #includes in "AmdSev.c"
Laszlo Ersek [Thu, 1 Mar 2018 16:52:37 +0000 (17:52 +0100)]
OvmfPkg/PlatformPei: sort #includes in "AmdSev.c"

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 14:02:11 +0000 (15:02 +0100)]
OvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "clear" reference to the C-bit with a "set" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "set" reference to the C-bit with a "clear" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment block
Laszlo Ersek [Thu, 1 Mar 2018 14:10:04 +0000 (15:10 +0100)]
OvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment block

Document the "Cr3BaseAddress" parameter, and correct several parameter
references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Replace any
leftover "clear" references to the C-bit with "set" references. Also
remove any excess space in the comment block, and unindent the trailing
"**/" if necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>