current in FDF spec 3.6 [FV] section it use "FV_EXT_ENTRY_TYPE" as
Keyword for <ExtendedFvEntry>, while in the code it use "FV_EXT_ENTRY".
To keep compatibility, this patch support both keyword in the code
first.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
current the PCD value in DSC file may be override by FDF file, then it
cause the 'DSC DEFAULT' in build report wrongly display the FDF value
but not the DSC file's value.
This patch add a attribute DscDefaultValue for PcdClassObject to save
the actual DSC file's PCD value and use this value to display for 'DSC
DEFAULT'.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This commit adds support for storing initial timer value
logged at the beginning of firmware image execution.
This timer value is required for firmware basic boot performance
data record referenced by Firmware Performance Data Table (FPDT).
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Alexei Fedorov <Alxei.Fedorov@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Graeme Gregory <graeme.gregory@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update FwVolDxe to get the authentication status
propagated from PEI-phase to DXE by FV3 HOB when producing FV
protocol.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update PeiCore to build FV3 HOB with the
authentication status and DxeCore to get the authentication
status from FV3 HOB when producing FVB Protocol.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add BuildFv3Hob API in HobLib.h and implement the API
in HobLib instances PeiHobLib, DxeHobLib and DxeCoreHobLib.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
CalculateCrc32() bases on the initialized mCrcTable. When CalculateCrc32()
is used, mCrcTable will take 1KB size in the image. When CalculateCrc32()
is not used, mCrcTable will not be built in the image, and no size impact.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
According to the TCG Platform Reset Attack Mitigation Specification (May
15, 2008):
> 5 Interface for UEFI
> 5.1 UEFI Variable
> 5.1.1 The MemoryOverwriteRequestControl
>
> Start of informative comment:
>
> [...] The OS loader should not create the variable. Rather, the firmware
> is required to create it and must support the semantics described here.
>
> End of informative comment.
However, some OS kernels create the MOR variable even if the platform
firmware does not support it (see one Bugzilla reference below). This OS
issue breaks the logic added in the last patch.
Strengthen the MOR check by searching for the TCG or TCG2 protocols, as
edk2's implementation of MOR depends on (one of) those protocols.
The protocols are defined under MdePkg, thus there's no inter-package
dependency issue. In addition, calling UEFI services in
MorLockInitAtEndOfDxe() is safe, due to the following order of events /
actions:
- platform BDS signals the EndOfDxe event group,
- the SMM core installs the SmmEndOfDxe protocol,
- MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services,
- some time later, platform BDS installs the DxeSmmReadyToLock protocol,
- SMM / SMRAM is locked down and UEFI services become unavailable to SMM
drivers.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
Suggested-by: Jiewen Yao <jiewen.yao@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The "MemoryOverwriteRequestControl" (a.k.a. MOR) variable comes from the
"TCG Platform Reset Attack Mitigation Specification":
https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf
The "MemoryOverwriteRequestControlLock" variable (a.k.a. MORL) is a
Microsoft extension, called "Secure MOR implementation":
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-requirements
Currently the VariableSmm driver creates MORL without regard to MOR. This
can lead to a situation where a platform does not support MOR from the
prerequisite spec (because it does not include the
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf" driver), but appears
to support MORL from the dependent Microsoft spec.
"winload.efi" notices this inconsistency, and disables the Device Guard
Virtualization Based Security in Windows Server 2016 and Windows 10 64-bit
Enterprise.
If the platform includes
"SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf", then MOR will exist
by the time EndOfDxe is reached, and VariableSmm can safely create MORL.
Otherwise, do not create MORL (delete it if it exists), and also prevent
other modules from creating it.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=727
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1496170
Reported-by: Ladi Prosek <lprosek@redhat.com>
Suggested-by: Jiewen Yao <jiewen.yao@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The SetMorLockVariable() function sets "mMorLockPassThru" to TRUE
temporarily, so that it can set the MOR Control Lock variable to
well-formed values without permission checks.
In the next patch, we'll need the same override for deleting the MOR
Control Lock variable; hence obey "mMorLockPassThru" in the deletion
branch of SetVariableCheckHandlerMorLock() as well.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
Introduce the MorLockInitAtEndOfDxe() hook, in order to allow
MorLockInit() to delay / queue operations until EndOfDxe. (Or, if the
platform never signals EndOfDxe, until ReadyToBoot.)
Call MorLockInitAtEndOfDxe() whenever we set "mEndOfDxe" to TRUE:
- in VariableRuntimeDxe:
- in the OnReadyToBoot() function,
- in the OnEndOfDxe() function;
- in VariableSmm:
- on the SMM_VARIABLE_FUNCTION_READY_TO_BOOT SMI request,
- in the SmmEndOfDxeCallback() function.
For now, implement MorLockInitAtEndOfDxe() as a no-op in both
VariableRuntimeDxe and VariableSmm.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
The MorLockInit() and SetVariableCheckHandlerMor() functions have separate
implementations for VariableRuntimeDxe (= unprivileged, unified
DXE_RUNTIME driver) and VariableSmm (= privileged, DXE_SMM back-end of the
split variable driver).
Move their declarations from "Variable.c" to "PrivilegePolymorphic.h", so
that the compiler enforce that the declarations and the definitions match.
(All C source files with the call sites and the function definitions
already include "PrivilegePolymorphic.h" via "Variable.h".)
At the same time:
- replace two typos in the MorLockInit() description:
- replace "EFI_SUCEESS" with "EFI_SUCCESS",
- replace "MOR Lock Control" with "MOR Control Lock";
- in the SetVariableCheckHandlerMor() description:
- replace @param with @param[in],
- correct the description of the Attributes parameter (suggested by Star
Zeng <star.zeng@intel.com>),
- rewrap the comment to 80 columns.
This change cleans up commit 2f6aa774fe ("MdeModulePkg: Add MorLock to
variable driver.", 2016-01-19).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
If the platform supports SMM, a gRT->SetVariable() call at boot time
results in the following call tree to SecureBootHook():
RuntimeServiceSetVariable() [VariableSmmRuntimeDxe.c, unprivileged]
SmmVariableHandler() [VariableSmm.c, PRIVILEGED]
VariableServiceSetVariable() [Variable.c, PRIVILEGED]
SecureBootHook() [VariableSmm.c, PRIVILEGED]
//
// do nothing
//
SecureBootHook() [Measurement.c, unprivileged]
//
// measure variable if it
// is related to SB policy
//
And if the platform does not support SMM:
VariableServiceSetVariable() [Variable.c, unprivileged]
SecureBootHook() [Measurement.c, unprivileged]
//
// measure variable if it
// is related to SB policy
//
In other words, the measurement always happens outside of SMM.
Because there are two implementations of the SecureBootHook() API, one
that is called from SMM and does nothing, and another that is called
outside of SMM and measures variables, the function declaration should be
in a header file. This way the compiler can enforce that the function
declaration and all function definitions match.
"Variable.h" is used for "including common header files, defining internal
structures and functions used by Variable modules". Technically, we could
declare SecureBootHook() in "Variable.h". However, "Measurement.c" and
"VariableSmmRuntimeDxe.c" themselves do not include "Variable.h", and that
is likely intentional -- "Variable.h" exposes so much of the privileged
variable implementation that it is likely excluded from these C source
files on purpose.
Therefore introduce a new header file called "PrivilegePolymorphic.h".
"Variable.h" includes this header (so that all C source files that have
been allowed to see the variable internals learn about the new
SecureBootHook() declaration immediately). In "Measurement.c" and
"VariableSmmRuntimeDxe.c", include *only* the new header.
This change cleans up commit fa0737a839 ("MdeModulePkg Variable: Merge
from Auth Variable driver in SecurityPkg", 2015-07-01).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>
Cc: Star Zeng <star.zeng@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>
Tested-by: Ladi Prosek <lprosek@redhat.com>
EFI_BOOT_SCRIPT_WRITE() interface is a var-arg interface.
Spec defines the order of parameters for
EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE as below:
typedef
EFI_STATUS
(EFIAPI *EFI_BOOT_SCRIPT_WRITE) (
IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
IN UINT16 OpCode,
IN EFI_BOOT_SCRIPT_WIDTH Width,
IN UINT16 Segment,
IN UINT64 Address,
IN UINTN Count,
IN VOID *Buffer
);
But implementation assumes Segment is in the very end, after Buffer.
Similar spec/implementation gaps are also found for
EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE.
The patch fixes the implementation to extract the arguments in
correct order.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Fix a bug to use module's Name attribute as compare for single module
build. ModuleFile.File can't be used to compare INF file, because it
is the relative path.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Current code logic not check the pointer before use it. This may
has potential issue, this patch add code to check it.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Commit 8932679df5 adds an ASSERT for
checking NULL pointer dereference.
The ASSERT added here is for addressing a false positive NULL pointer
dereference issue raised from static analysis.
This commit adds comments to clarify the reason for using ASSERT as the
check.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=720
The current implementation assumes there is only one hotplug resource
padding for each resource type. It's not true considering
DegradeResource(): MEM64 resource could be degraded to MEM32
resource.
The patch treat the resource paddings using the same logic as
treating typical/actual resources and the total resource of a bridge
is set to the MAX of typical/actual resources and resource paddings.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch adds a library that enables invocation of SVCs from Exception
Level EL0. It will be used by the Standalone MM environment to request
services from a software running in a privileged EL e.g. ARM Trusted
Firmware. The library is derived directly from Arm SMC Library.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
[ardb: assign frame pointer (AArch64)
keep stack alignment (ARM)]
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The ESRT hook call that I just added invokes the protocol before
retrieving a pointer to it, which interestingly enough did not
result in any crashes, nor did it get picked up by GCC. Clang did
notice, though, so let's fix it right away.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
SVCs are in the range 0xC4000060 - 0xC400007f.
The functions available to the secure MM partition:
1. Signal completion of MM event handling.
2. Set/Get memory attributes for a memory region at runtime.
3. Get version number of secure partition manager.
Also, it defines memory attributes required for set/get operations.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch adds a list of function IDs that fall under the standard
SMC range as defined in [1]
SMCs associated with Management Mode are in the range 0xC4000040 -
0xC400005f (64 bit) and 0x84000040 - 0x8400005f (32 bit).
The function(s) available to the normal world:
1. Request services from the secure MM environment using MM_COMMUNICATE.
It also defines MM return codes.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The ESRT management protocol needs to be invoked at the appropriate times
to get the ESRT config table to be published when the ReadyToBoot event
is signalled. So add this handling to the default ArmPkg implementation
of PlatformBootManagerLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The Juno and FVP platform implement the SBSA Watchdog timers.
Added PcdWatchdogCount to specify the number of Watchdog timers
that are available.
This allows configurability and an option to disable the watchdog
timers if required for testing.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The existing HardwareInterrupt protocol lacked a means to configure the
level/edge properties of an interrupt. The new HardwareInterrupt2
protocol introduced this capability.
This patch updates the GIC drivers to provide the new interfaces.
The changes comprise:
Update to use HardwareInterrupt2 protocol
Additions to register info in ArmGicLib.h
Added new functionality (GetTriggerType and SetTriggerType)
The requirement for this change derives from a problem detected on ARM
Juno boards, but the change is of generic (ARM) relevance.
This commit is in response to review on the mailing list and, as
suggested there, rolls Girish's updates onto Ard's original example.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Girish Pathak <girish.pathak@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Tested-by: Girish Pathak <girish.pathak@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The existing HardwareInterrupt protocol lacks the means to configure
the level/edge and polarity properties of an interrupt. So introduce a
new protocol HardwareInterrupt2, and add some new members that allow
manipulation of those properties.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Girish Pathak <girish.pathak@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Tested-by: Girish Pathak <girish.pathak@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Parse QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION from the bridges'
conventional config spaces. Translate the fields as follows:
* BusNumbers:
* 0 -- no reservation;
* (-1) -- firmware default, i.e. no reservation;
* otherwise -- reserve the requested value. (NB, bus number reservation
is not supposed to work before
<https://bugzilla.tianocore.org/show_bug.cgi?id=656> is fixed.)
* Io:
* 0 -- no reservation;
* (-1) -- keep our current default (512B);
* otherwise -- round up the requested value and reserve that.
* NonPrefetchable32BitMmio:
* 0 -- no reservation;
* (-1) -- keep our current default (2MB);
* otherwise -- round up the requested value and reserve that.
* Prefetchable32BitMmio:
* 0 -- no reservation, proceed to Prefetchable64BitMmio;
* (-1) -- firmware default, i.e. no reservation, proceed to
Prefetchable64BitMmio;
* otherwise -- round up the requested value and reserve that. (NB, if
Prefetchable32BitMmio is reserved in addition to
NonPrefetchable32BitMmio, then PciBusDxe currently runs into an
assertion failure. Refer to
<https://bugzilla.tianocore.org/show_bug.cgi?id=720>.)
* Prefetchable64BitMmio:
* only reached if Prefetchable32BitMmio was not reserved;
* 0 -- no reservation;
* (-1) -- firmware default, i.e. no reservation;
* otherwise -- round up the requested value and reserve that.
If QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION is missing, plus any
time the rounding fails, fall back to the current defaults.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.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>
Extract the SetIoPadding() and SetMmioPadding() functions, so that we can
set EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR fields using parameter names and
values that are more friendly than the original field names and their
expected values.
Introduce the HighBitSetRoundUp32() and HighBitSetRoundUp64() functions
for calculating the last parameter ("SizeExponent") of SetIoPadding() and
SetMmioPadding().
Put the new functions to use when requesting the default reservations. (In
order to be consistent with a later patch, "SizeExponent" is calculated
for SetIoPadding() with HighBitSetRoundUp64().)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.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>
Yonghong Zhu
Dandan Bi
Alexei Fedorov
Star Zeng
Liming Gao
Laszlo Ersek
Ruiyu Ni
Eric Dong
Hao Wu
Supreeth Venkatesh
Ard Biesheuvel
Sami Mujawar
Evan Lloyd