2014-01-22 09:38:50 +01:00
|
|
|
## @file
|
2015-07-01 05:08:29 +02:00
|
|
|
# Provides SMM variable service.
|
|
|
|
#
|
2014-01-22 09:38:50 +01:00
|
|
|
# This module installs SMM variable protocol into SMM protocol database,
|
2015-07-01 05:08:29 +02:00
|
|
|
# which can be used by SMM driver, and installs SMM variable protocol
|
2014-01-22 09:38:50 +01:00
|
|
|
# into BS protocol database, which can be used to notify the SMM Runtime
|
|
|
|
# Dxe driver that the SMM variable service is ready.
|
2015-07-01 05:08:29 +02:00
|
|
|
# This module should be used with SMM Runtime DXE module together. The
|
|
|
|
# SMM Runtime DXE module would install variable arch protocol and variable
|
2014-01-22 09:38:50 +01:00
|
|
|
# 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.
|
2015-07-01 05:08:29 +02:00
|
|
|
# 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.
|
2014-01-22 09:38:50 +01:00
|
|
|
#
|
2019-01-14 15:27:15 +01:00
|
|
|
# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:05:13 +02:00
|
|
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
2014-01-22 09:38:50 +01:00
|
|
|
#
|
|
|
|
##
|
|
|
|
|
|
|
|
[Defines]
|
|
|
|
INF_VERSION = 0x00010005
|
|
|
|
BASE_NAME = VariableSmm
|
2014-08-28 08:34:06 +02:00
|
|
|
MODULE_UNI_FILE = VariableSmm.uni
|
2014-01-22 09:38:50 +01:00
|
|
|
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
|
2019-01-03 19:28:24 +01:00
|
|
|
VariableTraditionalMm.c
|
2014-01-22 09:38:50 +01:00
|
|
|
VariableSmm.c
|
2019-09-28 00:34:14 +02:00
|
|
|
VariableNonVolatile.c
|
|
|
|
VariableNonVolatile.h
|
2019-09-24 02:32:07 +02:00
|
|
|
VariableParsing.c
|
|
|
|
VariableParsing.h
|
2019-09-24 01:48:09 +02:00
|
|
|
VariableRuntimeCache.c
|
|
|
|
VariableRuntimeCache.h
|
2015-01-05 04:38:36 +01:00
|
|
|
VarCheck.c
|
2014-01-22 09:38:50 +01:00
|
|
|
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
|
2015-07-01 05:08:29 +02:00
|
|
|
VariableExLib.c
|
2016-01-19 14:22:05 +01:00
|
|
|
TcgMorLockSmm.c
|
2018-12-21 03:30:22 +01:00
|
|
|
SpeculationBarrierSmm.c
|
2014-01-22 09:38:50 +01:00
|
|
|
|
|
|
|
[Packages]
|
|
|
|
MdePkg/MdePkg.dec
|
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
|
|
|
|
|
|
|
[LibraryClasses]
|
|
|
|
UefiDriverEntryPoint
|
|
|
|
MemoryAllocationLib
|
|
|
|
BaseLib
|
|
|
|
SynchronizationLib
|
|
|
|
UefiLib
|
2019-01-03 19:28:24 +01:00
|
|
|
MmServicesTableLib
|
2014-01-22 09:38:50 +01:00
|
|
|
BaseMemoryLib
|
|
|
|
DebugLib
|
|
|
|
DxeServicesTableLib
|
|
|
|
HobLib
|
|
|
|
PcdLib
|
2015-02-02 15:42:22 +01:00
|
|
|
SmmMemLib
|
2015-07-01 05:08:29 +02:00
|
|
|
AuthVariableLib
|
2015-08-25 05:01:56 +02:00
|
|
|
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
|
2014-01-22 09:38:50 +01:00
|
|
|
|
|
|
|
[Protocols]
|
2014-08-28 08:34:06 +02:00
|
|
|
gEfiSmmFirmwareVolumeBlockProtocolGuid ## CONSUMES
|
|
|
|
## CONSUMES
|
|
|
|
## NOTIFY
|
|
|
|
gEfiSmmFaultTolerantWriteProtocolGuid
|
|
|
|
## PRODUCES
|
|
|
|
## UNDEFINED # SmiHandlerRegister
|
|
|
|
gEfiSmmVariableProtocolGuid
|
2019-01-03 19:28:24 +01:00
|
|
|
gEfiMmEndOfDxeProtocolGuid ## NOTIFY
|
2015-01-05 04:38:36 +01:00
|
|
|
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
|
2014-01-22 09:38:50 +01:00
|
|
|
|
|
|
|
[Guids]
|
2016-03-25 10:24:37 +01:00
|
|
|
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
|
|
|
|
## SOMETIMES_PRODUCES ## GUID # Signature of Variable store header
|
2014-08-28 08:34:06 +02:00
|
|
|
## SOMETIMES_CONSUMES ## HOB
|
2015-07-01 05:08:29 +02:00
|
|
|
## SOMETIMES_PRODUCES ## SystemTable
|
|
|
|
gEfiAuthenticatedVariableGuid
|
|
|
|
|
2016-03-25 10:24:37 +01:00
|
|
|
## SOMETIMES_CONSUMES ## GUID # Signature of Variable store header
|
|
|
|
## SOMETIMES_PRODUCES ## GUID # Signature of Variable store header
|
2015-07-01 05:08:29 +02:00
|
|
|
## SOMETIMES_CONSUMES ## HOB
|
|
|
|
## SOMETIMES_PRODUCES ## SystemTable
|
2014-08-28 08:34:06 +02:00
|
|
|
gEfiVariableGuid
|
2015-07-01 05:08:29 +02:00
|
|
|
|
2014-08-28 08:34:06 +02:00
|
|
|
## SOMETIMES_CONSUMES ## Variable:L"PlatformLang"
|
|
|
|
## SOMETIMES_PRODUCES ## Variable:L"PlatformLang"
|
|
|
|
## SOMETIMES_CONSUMES ## Variable:L"Lang"
|
|
|
|
## SOMETIMES_PRODUCES ## Variable:L"Lang"
|
|
|
|
gEfiGlobalVariableGuid
|
2015-07-01 05:08:29 +02:00
|
|
|
|
2016-03-25 10:24:37 +01:00
|
|
|
gEfiMemoryOverwriteControlDataGuid ## SOMETIMES_CONSUMES ## Variable:L"MemoryOverwriteRequestControl"
|
|
|
|
gEfiMemoryOverwriteRequestControlLockGuid ## SOMETIMES_PRODUCES ## Variable:L"MemoryOverwriteRequestControlLock"
|
2016-01-19 14:22:05 +01:00
|
|
|
|
2015-07-01 05:08:29 +02:00
|
|
|
gSmmVariableWriteGuid ## PRODUCES ## GUID # Install protocol
|
2014-08-28 08:34:06 +02:00
|
|
|
gEfiSystemNvDataFvGuid ## CONSUMES ## GUID
|
2015-07-01 05:08:29 +02:00
|
|
|
gEdkiiFaultTolerantWriteGuid ## SOMETIMES_CONSUMES ## HOB
|
2016-03-25 10:24:37 +01:00
|
|
|
|
|
|
|
## SOMETIMES_CONSUMES ## Variable:L"VarErrorFlag"
|
|
|
|
## SOMETIMES_PRODUCES ## Variable:L"VarErrorFlag"
|
|
|
|
gEdkiiVarErrorFlagGuid
|
2014-01-22 09:38:50 +01:00
|
|
|
|
|
|
|
[Pcd]
|
2015-07-01 05:08:29 +02:00
|
|
|
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
|
2015-07-01 05:08:29 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize ## CONSUMES
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize ## CONSUMES
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize ## CONSUMES
|
2015-01-27 09:42:47 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxUserNvVariableSpaceSize ## CONSUMES
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdBoottimeReservedNvVariableSpaceSize ## CONSUMES
|
2015-07-01 05:08:29 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdReclaimVariableSpaceAtEndOfDxe ## CONSUMES
|
2019-01-14 15:27:15 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable ## SOMETIMES_CONSUMES
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved ## SOMETIMES_CONSUMES
|
2015-02-02 10:30:34 +01:00
|
|
|
|
2014-01-22 09:38:50 +01:00
|
|
|
[FeaturePcd]
|
2015-07-01 05:08:29 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics ## CONSUMES # statistic the information of variable.
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate ## CONSUMES # Auto update PlatformLang/Lang
|
2014-01-22 09:38:50 +01:00
|
|
|
|
|
|
|
[Depex]
|
|
|
|
TRUE
|
|
|
|
|
2014-08-28 08:34:06 +02:00
|
|
|
[UserExtensions.TianoCore."ExtraFiles"]
|
|
|
|
VariableSmmExtra.uni
|