[L] Change in coreboot[master]: drivers/smm_payload_interface: Add initial support for SMM payload

[Benjamin Doron (Code Review)]

Attention is currently required from: Benjamin Doron, Martin L Roth, Michał Żygowski, Paul Menzel.

Hello Angel Pons, Lean Sheng Tan, Martin L Roth, Patrick Rudolph, build bot (Jenkins),

I'd like you to reexamine a change. Please visit

https://review.coreboot.org/c/coreboot/+/70378?usp=email

to look at the new patch set (#12).

The following approvals got outdated and were removed:
Verified+1 by build bot (Jenkins)

Change subject: drivers/smm_payload_interface: Add initial support for SMM payload
......................................................................

drivers/smm_payload_interface: Add initial support for SMM payload

UEFI Secure Boot is a security feature that protects the chain-of-trust.
With proper implementation and configuration, it ensures that the user's
bootloader and OS start as desired, without malicious modification.

The protection of key variables is critical to Secure Boot, so, note
that the UEFI variable protocol provides the Variable Policy to
restrict write permissions, and variables have an `Attributes` field,
enabling protections such as hiding at runtime or "authenticating" write
requests.

Presently, coreboot's UefiPayload can support the Authenticated
Variables required by Secure Boot using SMMSTORE. Simply use this GUID
signature on the variable store to advertise support. However, this does
not offer the expected guarantees: Usually, when `gRT->SetVariable()` is
called, SMM is entered via EDK2 "SMM communication" for VariableSmm to
perform verification of the write request, then write SPI flash.

However, the SMMSTORE SMI handler can be initiated manually (outside of
the `gRT->SetVariable()` -> FaultTolerantWrite protocol ->
FirmwareVolumeBlock protocol == SMMSTORE). In this case, the variable
driver cannot verify a write request is permitted. In addition, the
variable driver - in this case, VariableRuntimeDxe - will be vulnerable
to malicious patching. Therefore, a more integrated solution is required
for Secure Boot.

The solution here is to initialise SMM in EDK2, following UefiPayload
work for slimbootloader. This approach has several challenges, to be
resolved as below:
- coreboot provides register definitions in CBMEM to avoid
  silicon-dependence in payload.
- Payloads are not on the S3 resume path. While TSEG is preserved,
  coreboot must perform SMM relocate and trigger a payload SMI, which
  will lock SMM using the SMRRs. These are privileged MSRs.

A minimal 4K communication region is shared with the payload, located
in SMRAM. CPU-specific SMBASEs are stored here, to be provided to common
code for relocation, as well as the payload's SMI number to trigger for
final SMM lockdown.

TEST= Successful with UefiPayload patches, tested on ADLRVP.
- Cold boot: Verify that payload initialises SMM and writes variables.
- S3 resume: Verify that SMI succeeds with debug log output.

Change-Id: I3dd505a154175b6da8929b1157723de1645ca8fa
Signed-off-by: Benjamin Doron 
---
A Documentation/drivers/smm_payload_interface.md
M Makefile.inc
M src/Kconfig
M src/commonlib/include/commonlib/coreboot_tables.h
A src/drivers/smm_payload_interface/Kconfig
A src/drivers/smm_payload_interface/Makefile.inc
A src/drivers/smm_payload_interface/cbtable.c
A src/drivers/smm_payload_interface/ramstage.c
A src/drivers/smm_payload_interface/util.c
A src/drivers/smm_payload_interface/util_common.c
A src/drivers/smm_payload_interface/util_hob.c
A src/include/smm_payload_interface.h
M src/lib/coreboot_table.c
M src/security/lockdown/Kconfig
14 files changed, 649 insertions(+), 4 deletions(-)

git pull ssh://review.coreboot.org:29418/coreboot refs/changes/78/70378/12