audk/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf

150 lines
5.9 KiB
INI
Raw Normal View History

## @file
# Provides SMM variable service.
#
# This module installs SMM variable protocol into SMM protocol database,
# which can be used by SMM driver, and installs SMM variable protocol
# into BS protocol database, which can be used to notify the SMM Runtime
# Dxe driver that the SMM variable service is ready.
# This module should be used with SMM Runtime DXE module together. The
# SMM Runtime DXE module would install variable arch protocol and variable
# write arch protocol based on SMM variable module.
#
# Caution: This module requires additional review when modified.
# This driver will have external input - variable data and communicate buffer in SMM mode.
# This external input must be validated carefully to avoid security issues such as
# buffer overflow or integer overflow.
# The whole SMM authentication variable design relies on the integrity of flash part and SMM.
# which is assumed to be protected by platform. All variable code and metadata in flash/SMM Memory
# may not be modified without authorization. If platform fails to protect these resources,
# the authentication service provided in this driver will be broken, and the behavior is undefined.
#
# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = VariableSmm
MODULE_UNI_FILE = VariableSmm.uni
FILE_GUID = 23A089B3-EED5-4ac5-B2AB-43E3298C2343
MODULE_TYPE = DXE_SMM_DRIVER
VERSION_STRING = 1.0
PI_SPECIFICATION_VERSION = 0x0001000A
ENTRY_POINT = VariableServiceInitialize
#
# The following information is for reference only and not required by the build tools.
#
# VALID_ARCHITECTURES = IA32 X64
#
[Sources]
Reclaim.c
Variable.c
VariableTraditionalMm.c
VariableSmm.c
VariableNonVolatile.c
VariableNonVolatile.h
VariableParsing.c
VariableParsing.h
MdeModulePkg/Variable: Add RT GetVariable() cache support REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2220 This change reduces SMIs for GetVariable () by maintaining a UEFI variable cache in Runtime DXE in addition to the pre- existing cache in SMRAM. When the Runtime Service GetVariable() is invoked, a Runtime DXE cache is used instead of triggering an SMI to VariableSmm. This can improve overall system performance by servicing variable read requests without rendezvousing all cores into SMM. The runtime cache can be disabled with by setting the FeaturePCD gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache to FALSE. If the PCD is set to FALSE, the runtime cache will not be used and an SMI will be triggered for Runtime Service GetVariable () and GetNextVariableName () invocations. The following are important points regarding the behavior of the variable drivers when the variable runtime cache is enabled. 1. All of the non-volatile storage contents are loaded into the cache upon driver load. This one time load operation from storage is preferred as opposed to building the cache on demand. An on- demand cache would require a fallback SMI to load data into the cache as variables are requested. 2. SetVariable () requests will continue to always trigger an SMI. This occurs regardless of whether the variable is volatile or non-volatile. 3. Both volatile and non-volatile variables are cached in a runtime buffer. As is the case in the current EDK II variable driver, they continue to be cached in separate buffers. 4. The cache in Runtime DXE and SMM are intended to be exact copies of one another. All SMM variable accesses only return data from the SMM cache. The runtime caches are only updated after the variable I/O operation is successful in SMM. The runtime caches are only updated from SMM. 5. Synchronization mechanisms are in place to ensure the runtime cache content integrity with the SMM cache. These may result in updates to runtime cache that are the same in content but different in offset and size from updates to the SMM cache. When using SMM variables with runtime cache enabled, two caches will now be present. 1. "Runtime Cache" - Maintained in VariableSmmRuntimeDxe. Used to service Runtime Services GetVariable () and GetNextVariableName () callers. 2. "SMM Cache" - Maintained in VariableSmm to service SMM GetVariable () and GetNextVariableName () callers. a. This cache is retained so SMM modules do not operate on data outside SMRAM. Because a race condition can occur if an SMI occurs during the execution of runtime code reading from the runtime cache, a runtime cache read lock is introduced that explicitly moves pending updates from SMM to the runtime cache if an SMM update occurs while the runtime cache is locked. Note that it is not expected a Runtime services call will interrupt SMM processing since all CPU cores rendezvous in SMM. It is possible to view UEFI variable read and write statistics by setting the gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics FeaturePcd to TRUE and using the VariableInfo UEFI application in MdeModulePkg to dump variable statistics to the console. By doing so, a user can view the number of GetVariable () hits from the Runtime DXE variable driver (Runtime Cache hits) and the SMM variable driver (SMM Cache hits). SMM Cache hits for GetVariable () will occur when SMM modules invoke GetVariable (). Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2019-09-24 01:48:09 +02:00
VariableRuntimeCache.c
VariableRuntimeCache.h
VarCheck.c
Variable.h
MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new header 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 fa0737a839d0 ("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>
2017-09-30 13:40:32 +02:00
PrivilegePolymorphic.h
VariableExLib.c
TcgMorLockSmm.c
SpeculationBarrierSmm.c
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
[LibraryClasses]
UefiDriverEntryPoint
MemoryAllocationLib
BaseLib
SynchronizationLib
UefiLib
MmServicesTableLib
BaseMemoryLib
DebugLib
DxeServicesTableLib
HobLib
PcdLib
SmmMemLib
AuthVariableLib
VarCheckLib
MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable 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>
2017-10-03 17:55:09 +02:00
UefiBootServicesTableLib
[Protocols]
gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
## CONSUMES
## NOTIFY
gEfiSmmFaultTolerantWriteProtocolGuid
## PRODUCES
## UNDEFINED # SmiHandlerRegister
gEfiSmmVariableProtocolGuid
gEfiMmEndOfDxeProtocolGuid ## NOTIFY
gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable 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>
2017-10-03 17:55:09 +02:00
gEfiTcgProtocolGuid ## SOMETIMES_CONSUMES
gEfiTcg2ProtocolGuid ## SOMETIMES_CONSUMES
[Guids]
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
## SOMETIMES_PRODUCES ## GUID # Signature of Variable store header
## SOMETIMES_CONSUMES ## HOB
## SOMETIMES_PRODUCES ## SystemTable
gEfiAuthenticatedVariableGuid
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
## SOMETIMES_PRODUCES ## GUID # Signature of Variable store header
## SOMETIMES_CONSUMES ## HOB
## SOMETIMES_PRODUCES ## SystemTable
gEfiVariableGuid
## SOMETIMES_CONSUMES ## Variable:L"PlatformLang"
## SOMETIMES_PRODUCES ## Variable:L"PlatformLang"
## SOMETIMES_CONSUMES ## Variable:L"Lang"
## SOMETIMES_PRODUCES ## Variable:L"Lang"
gEfiGlobalVariableGuid
gEfiMemoryOverwriteControlDataGuid ## SOMETIMES_CONSUMES ## Variable:L"MemoryOverwriteRequestControl"
gEfiMemoryOverwriteRequestControlLockGuid ## SOMETIMES_PRODUCES ## Variable:L"MemoryOverwriteRequestControlLock"
gSmmVariableWriteGuid ## PRODUCES ## GUID # Install protocol
gEfiSystemNvDataFvGuid ## CONSUMES ## GUID
gEdkiiFaultTolerantWriteGuid ## SOMETIMES_CONSUMES ## HOB
## SOMETIMES_CONSUMES ## Variable:L"VarErrorFlag"
## SOMETIMES_PRODUCES ## Variable:L"VarErrorFlag"
gEdkiiVarErrorFlagGuid
[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase ## SOMETIMES_CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64 ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize ## CONSUMES
MdeModulePkg/Variable/RuntimeDxe: introduce PcdMaxVolatileVariableSize The variable driver doesn't distinguish "non-volatile non-authenticated" variables from "volatile non-authenticated" variables, when checking individual variable sizes against the permitted maximum. PcdMaxVariableSize covers both kinds. This prevents volatile non-authenticated variables from carrying large data between UEFI drivers, despite having no flash impact. One example is EFI_TLS_CA_CERTIFICATE_VARIABLE, which platforms might want to create as volatile on every boot: the certificate list can be several hundred KB in size. Introduce PcdMaxVolatileVariableSize to represent the limit on individual volatile non-authenticated variables. The default value is zero, which makes Variable/RuntimeDxe fall back to PcdMaxVariableSize (i.e. the current behavior). This is similar to the PcdMaxAuthVariableSize fallback. Whenever the size limit is enforced, consult MaxVolatileVariableSize as the last option, after checking - MaxAuthVariableSize for VARIABLE_ATTRIBUTE_AT_AW, - and MaxVariableSize for EFI_VARIABLE_NON_VOLATILE. EFI_VARIABLE_HARDWARE_ERROR_RECORD is always handled separately; it always takes priority over the three cases listed above. Introduce the GetMaxVariableSize() helper to consider PcdMaxVolatileVariableSize, in addition to GetNonVolatileMaxVariableSize(). GetNonVolatileMaxVariableSize() is currently called at three sites, and two of those need to start using GetMaxVariableSize() instead: - VariableServiceInitialize() [VariableSmm.c]: the SMM comms buffer must accommodate all kinds of variables, - VariableCommonInitialize() [Variable.c]: the preallocated scratch space must also accommodate all kinds of variables, - InitNonVolatileVariableStore() [Variable.c] can continue using GetNonVolatileMaxVariableSize(). Don't modify the ReclaimForOS() function as it is specific to non-volatile variables and should ignore PcdMaxVolatileVariableSize. Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.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: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> [lersek@redhat.com: set MaxVolatileVariableSize where Star suggested] Reviewed-by: Star Zeng <star.zeng@intel.com>
2018-03-28 15:55:42 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxUserNvVariableSpaceSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdBoottimeReservedNvVariableSpaceSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdReclaimVariableSpaceAtEndOfDxe ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable ## SOMETIMES_CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved ## SOMETIMES_CONSUMES
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics ## CONSUMES # statistic the information of variable.
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate ## CONSUMES # Auto update PlatformLang/Lang
[Depex]
TRUE
[UserExtensions.TianoCore."ExtraFiles"]
VariableSmmExtra.uni