For historical reasons, VariableRuntimeDxe performs virtual address
conversion on the FVB protocol member pointers of the protocol instance
that backs the EFI variable store. However, the driver that produces the
actual instance should be doing this, as it is the owner and provides
the actual implementation of those methods.
Unfortunately, we cannot simply remove this: existing FVB drivers may
rely on the Variable driver performing the conversion on their behalf.
So the Variable driver should convert the pointers only when the FVB
producer has not already done so.
The SetVirtualAddressMap event can be delivered in arbitrary order, so
we cannot rely on whether this driver converts its pointers before or
after the FVB protocol owner receives the event.
Fix this by recording the converted addresses in a shadow FVB protocol
rather than converting the live pointers directly. On the first runtime
variable access, check whether the FVB producer has performed its own
conversion; if not, swap in the shadow copy's converted pointers.
Without this fix, platforms where the FVB producer performs its own
SetVirtualAddressMap conversion (e.g., OP-TEE StandaloneMm-backed
EepromFvb on NXP LX2160A) suffer double pointer conversion, causing
runtime variable access to crash.
Signed-off-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Tested-by: Liz Fong-Jones <lizf@honeycomb.io>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
This change updates `VariableSmmRuntimeDxe` to correctly size its runtime
communication buffer when `EFI_MM_COMMUNICATION3_PROTOCOL` is present.
In the current flow, the runtime variable path may use MM communication
v3, but the input size is first validated against the global variable
`mVariableBufferPayloadSize`. The size is then validated a second time
during communication buffer initialization using the v3 header size,
which results in `GetVariable` calls with sufficiently large buffers
consistently failing.
This update makes the allocation logic v3‑aware so that the runtime
variable communication buffer matches the header format actually in use,
avoiding failures for larger variable transactions.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
When using MM communicate v3 to fetch variable, the header calculation
was incorrect, causing the variable driver on the secure environment to
have random behavior.
This change refactored the original routine by following the current
DXE instance (mostly).
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 support from MdeModulePkg. This also
drops irrelevant VALID_ARCHITECTURE comments from infs that
are not arch specific.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Running Codeql on MdeModulePkg/Universal/Variable drivers results
in codeql errors stemming for the following two checks.
- cpp/comparison-with-wider-type
- cpp/overflow-buffer
- cpp/missing-null-test
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Co-authored-by: Taylor Beebe <tabeebe@microsoft.com>
Co-authored-by: pohanch <125842322+pohanch@users.noreply.github.com>
Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com>
Co-authored-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Co-authored-by: Sean Brogan <sean.brogan@microsoft.com>
Co-authored-by: Aaron <aaronpop@microsoft>
As the MM cores begin to support MM Communicate v3, this update moves the
driver to communicate to MM agent through MM Communicate v3 PPI.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
As MM cores start to support MM communciate v3. This change moves the
variable driver to use MM communicate v3 if it is available, otherwise the
driver will fallback to v2 to keep the same functionality.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
On a MM system, the main UEFI variable logic resides in MMRAM. In
that case, the variable policy logic in `VarCheckPolicyLib`, such as
`VarCheckPolicyLibStandaloneMm` is linked against the MM driver also
in that case `VariableStandaloneMm`.
The MM variable driver indicates its presence to the RT DXE driver
via `gEfiSmmVariableProtocolGuid` to indicate variable read support
is available from MM. This triggers installation of the variable
architectural protocol in DXE.
Today, variable policy is initialized by calling
`VariablePolicySmmDxeMain()` in `VariableSmmRuntimeInitialize()`. In
turn, this installs `gEdkiiVariablePolicyProtocolGuid`. Functions in
`gEdkiiVariablePolicyProtocolGuid` may trigger MMIs. However, it is
possible that the MM variable driver which is linked against the code
with the variable policy MMI handlers (i.e. `VarCheckPolicyLib`) is
not loaded yet.
Therefore, this change moves invocation of
`VariablePolicySmmDxeMain()` to `SmmVariableReady()` which is called
on installation of `gEfiSmmVariableProtocolGuid` indicating variable
MM services are ready. `gEdkiiVariablePolicyProtocolGuid` is still
installed prior to the variable architectural protocol being
installed.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
If we search the codebase for &gEdkiiVariablePolicyProtocolGuid
we can find two drivers which install this policy:
VariableRuntimeDxe (installed in VariableDxe.c) and
VariableSmmRuntimeDxe (installed in VariablePolicySmmDxe.c).
The .inf file for VariableRuntimeDxe incorrectly lists the protocol
as CONSUMES in the comment, so change this to PRODUCES.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
In Standalone MM, there is no notification to MM drivers that variable
write is ready. Install gSmmVariableWriteGuid into MM handle database
for the notification.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
According to TCG's Platform Reset Attack Mitigation spec, the OS should
never create the MOR variable, only read and write it.
But some OSes (Fedora 24 and 25) don't follow the TCG's Platform Reset
Attack Mitigation spec and unintentionally create MOR variable.
The commit fda8f631ed added function
VariableHaveTcgProtocols() to check against Tcg/Tcg2 protocol to infer
whether the MOR variable is created by platform firmware or not. If not,
delete the variable created by OS and lock the variable to avoid OS to
create it.
But in VariableStandaloneMm, VariableHaveTcgProtocols() always returns
FALSE, it causes TCG MOR secure feature does not work in standalone MM
environment.
As Fedora 24 and 25 are EOL today, directly returns TRUE in the function
VariableHaveTcgProtocols() for VariableStandaloneMm, and rename the
function to VariableIsMorVariableLegitimate() to make it more obvious
what the narrow use-case is for which it exists.
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
This patch is to fix issue caused by uninitialized local
variable in Pei/Variable.c.
In the fucntion CalculateHobVariableCacheSize(), the local
variable VARIABLE_STORE_INFO StoreInfo is used without
initialization. When the uninitialized variable is passed
to CalculateAuthVarStorageSize() and GetNextVariablePtr(),
the field StoreInfo->FtwLastWriteData might be a uninitialized
non-zero value. Then the code execution will access the
invalid address StoreInfo->FtwLastWriteData->TargetAddress.
This might cause issue.
So in this commit, the local variable VARIABLE_STORE_INFO
StoreInfo is initialized by a ZeroMem() before use.
Signed-off-by: Dun Tan <dun.tan@intel.com>
VariableSmmIsBufferOutsideSmmValid function is to check the buffer
is outside SMM or not. This patch fix the issue that always return
true for MM.
Meanwhile, this patch renames VariableSmmIsBufferOutsideSmmValid
to VariableSmmIsNonPrimaryBufferValid.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Cc: Dun Tan <dun.tan@intel.com>
Cc: Yuanhao Xie <yuanhao.xie@intel.com>
Add a new function (VariableSmmIsPrimaryBufferValid) to check
Primary Buffer valid or not.
original function (VariableSmmIsBufferOutsideSmmValid) is used to
check the buffer outside MMRAM.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Cc: Dun Tan <dun.tan@intel.com>
Cc: Yuanhao Xie <yuanhao.xie@intel.com>
Add global variable mVariableRtCacheInfo to save the
content in gEdkiiVariableRuntimeCacheInfoHobGuid. With
this new global variable, 7 global variables can be
removed.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Refine the code logic in InitVariableCache().
In this commit, three times calling of
InitVariableCache() for different type cache are
merged into one calling. This commit is to make
the code looks cleaner and doesn't change any
code functionality.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Remove the usage of PcdEnableVariableRuntimeCache. We can
use the existence of gEdkiiVariableRuntimeCacheInfoHobGuid
to indicate if variable runtime cache is enabled or not.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Consume gEdkiiVariableRuntimeCacheInfoHobGuid in
VariableSmmRuntimeDxe driver to initialize the following
variable cache related buffer:
*mVariableRuntimeHobCacheBuffer
*mVariableRuntimeNvCacheBuffer
*mVariableRuntimeVolatileCacheBuffer
*mVariableRuntimeCachePendingUpdate
*mVariableRuntimeCacheReadLock
*mHobFlushComplete
The code to to allocate
and unblock the buffer for
different type cache in VariableSmmRuntimeDxe is also
removed in this commit.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Remove unneed FreePages() for RuntimeHobCacheBuffer which is
allocated in PEI phase.
So the global variable mVariableRuntimeHobCacheBufferSize
also can be removed.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Remove the two unnecessary global variables and
replace them by two local variables:
mVariableRuntimeNvCacheBufferSize
mVariableRuntimeVolatileCacheBufferSize
Signed-off-by: Dun Tan <dun.tan@intel.com>
Install the callback of gEfiPeiMemoryDiscoveredPpiGuid
to create gEdkiiVariableRuntimeCacheInfoHobGuid in
VariablePei module. When PcdEnableVariableRuntimeCache
is TRUE, the callback will be installed to allocate
the needed buffer for different type variable runtime
cache, unblock the buffer and build this HOB. Then the
runtime cache buffer address and size will be saved in
the HOB content.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Emit a DEBUG_WARN message if there is not enough flash space left to
write/update a variable. This condition is currently not logged
appropriately in all cases, given that full variable store can easily
render the system unbootable.
This new message helps identifying this condition.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
RuntimeDxe is used to back the runtime services time functions,
so align the description of the function return values with the
defined values for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4597
When creating a new variable, skip marking VAR_HEADER_VALID_ONLY so that
variable header + data update can be merged into one flash write. This
will greatly reduce the time taken for updating a variable and thus
increase performance. Removing VAR_HEADER_VALID_ONLY marking doesn't
have any function impact since it's not used by current code to detect
variable header + data corruption.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Gao Cheng <gao.cheng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Introduces two new APIs to EDKII_VARIABLE_POLICY_PROTOCOL:
1. GetVariablePolicyInfo()
2. GetLockOnVariableStateVariablePolicyInfo()
These allow a caller to retrieve policy information associated with
a UEFI variable given the variable name and vendor GUID.
GetVariablePolicyInfo() - Returns the variable policy applied to the
UEFI variable. If the variable policy is applied toward an individual
UEFI variable, that name can optionally be returned.
GetLockOnVariableStateVariablePolicyInfo() - Returns the Lock on
Variable State policy applied to the UEFI variable. If the Lock on
Variable State policy is applied to a specific variable name, that
name can optionally be returned.
These functions can be useful for a variety of purposes such as
auditing, testing, and functional flows.
Also fixed some variable name typos in code touched by the changes.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Message-Id: <20231030203112.736-2-mikuback@linux.microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4410
Inside TcgMorLockSmm.c, the SetVariableCheckHandlerMorLock() function
contains a scenario to prevent a possible dictionary attack on the MorLock
Key in accordance with the TCG Platform Reset Mitigation Spec v1.10.
The mechanism to prevent this attack must also change the MorLock Variable
Value to 0x01 to indicate Locked Without Key.
ASSERT_EFI_ERROR is added for error visibility since SetMorLockVariable
returns a status code
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Abhi Singh <Abhi.Singh@arm.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4464
This change introduced the Standalone MM based variable read capability
in PEI phase for applicable platforms (such as ARM platforms).
Similar to the x86 counterpart, MM communicate PPI is used to request
variable information from Standalone MM environment.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Co-authored-by: Ronny Hansen <hansen.ronny@microsoft.com>
Co-authored-by: Shriram Masanamuthu Chinnathurai <shriramma@microsoft.com>
Co-authored-by: Preshit Harlikar <pharlikar@microsoft.com>
Signed-off-by: Kun Qin <kuqin@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Update MdeModulePkg host-based unit test INF files to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4341
Commit 21320ef669 broke some tests in the AuthVar_Conf test
in edk2-test. There are 2 testcases that invoke SetVariable
with the following attribute value:
(EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS)
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated and the UEFI spec
says this should return EFI_UNSUPPORTED.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Sunny Wang <Sunny.Wang@arm.com>
Signed-off-by: Stuart Yoder <stuart.yoder@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479
Updates VariableRuntimeDxe, VariableSmm, and VariableStandaloneMm
to acquire variable flash information from the Variable Flash
Information library.
Note: This introduces a dependency on VariableFlashInfoLib in these
modules. Therefore, a platform building the variable modules must
specify an instance of VariableFlashInfoLib in their platform build.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3709
In EDKII implementation of variable policy, the DXE runtime agent would
communicate to MM to disable, register or query policies. However, these
operations populate the value of MessageLength that includes communicate
header to include MM communicate header, which mismatches with the
description of PI specification.
This fix will correct the MessageLength field calculation to exclude
the size of MM_COMMUNICATE_HEADER.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Only EFI_VARIABLE_NON_VOLATILE attribute is an invalid combination
of attribute bits, so update the variable driver to return
EFI_INVALID_PARAMETER so that we can prevent the invalid variable
being created.
This change also fixes the SCT failure below:
- RT.QueryVariableInfo - With being an invalid combination -- FAILURE
For details, please check the threads below:
- https://edk2.groups.io/g/devel/topic/86486174
- https://edk2.groups.io/g/devel/message/82466
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: G Edhaya Chandran <edhaya.chandran@arm.com>
Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdeModulePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3767
Update use of DEBUG_CODE(Expression) if Expression is a complex code
block with if/while/for/case statements that use {}.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760
Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When using will_return() on a pointer value, it must be
cast to UINTN to be compatible with 32-bit GCC builds.
This uses the same approach in samples provided in the
UnitTestFramworkPkg when passing pointer values to
UT_ASSERT_EQUAL().
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Commit a18a9bde36 ("MdeModulePkg/Variable/RuntimeDxe: Restore Variable
Lock Protocol behavior", 2020-12-15), for bug 3111, added two such sets of
debug messages that:
(a) are relevant for developers,
(b) yet should not necessarily poke end-users, because no functionality
suffers in practice.
Both message sets are in function VariableLockRequestToLock(): the first
is a generic interface deprecation warning; the second is the
double-locking situation, which we permit for compatibility (return status
EFI_SUCCESS).
Both message sets should be emitted with the DEBUG_WARN mask, not the most
serious DEBUG_ERROR mask. On some platforms, the serial console carries
both terminal traffic, and grave (DEBUG_ERROR-only) log messages. On such
platforms, both message sets may be perceived as a nuisance by end-users,
as there is nothing they can do, and there's nothing they *should* do --
in practice, nothing malfunctions.
(Such a platform is ArmVirtQemu, built with "-D
DEBUG_PRINT_ERROR_LEVEL=0x80000000".)
Cc: Bret Barkelew <bret.barkelew@microsoft.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3410
Fixes: a18a9bde36
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210521204037.11980-1-lersek@redhat.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
This changes added usage of MmUnblockMemoryLib to explicitly request
runtime cache regions(and its indicators) to be accessible from MM
environment when PcdEnableVariableRuntimeCache is enabled. It will bring
in compatibility with architectures that supports full memory blockage
inside MM.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Kun Qin <kun.q@outlook.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Message-Id: <MWHPR06MB31026EA41F28F2CE12B68574F3969@MWHPR06MB3102.namprd06.prod.outlook.com>
Instead of running StMM in SPM, OP-TEE creates a new secure partition,
which emulates SPM and isolates StMM from the rest of the Trusted
Applications (TAs). We can then compile StMM as an FD image and run it
in OP-TEE. With the addition of a new RPMB driver, we can leverage OP-TEE
and store variables to an RPMB device.
Since EDK2 upper layers expect byte addressable code, for the RPMB to
work, we need to allocate memory and sync it with the hardware on
read/writes. Since DynamicPCDs are not supported in that context we
can only use PatchablePCDs. So let's switch them to Pcd instead of
FixedPcd and accomodate the new driver. While at it, move the rest
of the variables under Pcd section, instead of FixedPcd -- this is in
line with how the variables are defined in the other Variable
modules.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=3111
Add host based unit tests for the multiple lock case using Variable Lock
Protocol, Variable Policy Protocol, and mixes of Variable Lock Protocol
and Variable Policy Protocol.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3111
The VariableLock shim currently fails if called twice because the
underlying Variable Policy engine returns an error if a policy is set
on an existing variable.
This breaks existing code which expect it to silently pass if a variable
is locked multiple times (because it should "be locked").
Refactor the shim to confirm that the variable is indeed locked and then
change the error to EFI_SUCCESS and generate a DEBUG_ERROR message so
the duplicate lock can be reported in a debug log and removed.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2522
Now that everything should be moved to
VariablePolicy, drop support for the
deprecated VarLock SMI interface and
associated functions from variable RuntimeDxe.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bret Barkelew <brbarkel@microsoft.com>
Signed-off-by: Bret Barkelew <brbarkel@microsoft.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Jian J Wang <jian.j.wang@intel.com>
