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

144 lines
5.8 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 - 2016, Intel Corporation. All rights reserved.<BR>
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
# which accompanies this distribution. The full text of the license may be found at
# http://opensource.org/licenses/bsd-license.php
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#
##
[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
VariableSmm.c
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
[Packages]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
[LibraryClasses]
UefiDriverEntryPoint
MemoryAllocationLib
BaseLib
SynchronizationLib
UefiLib
SmmServicesTableLib
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
gEfiSmmEndOfDxeProtocolGuid ## 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
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxUserNvVariableSpaceSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdBoottimeReservedNvVariableSpaceSize ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdReclaimVariableSpaceAtEndOfDxe ## CONSUMES
[FeaturePcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics ## CONSUMES # statistic the information of variable.
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate ## CONSUMES # Auto update PlatformLang/Lang
[Depex]
TRUE
[UserExtensions.TianoCore."ExtraFiles"]
VariableSmmExtra.uni