]> git.proxmox.com Git - mirror_edk2.git/commit - OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
OvmfPkg/PlatformBootManagerLib: process TPM PPI request
authorMarc-André Lureau <marcandre.lureau@redhat.com>
Fri, 18 May 2018 12:23:04 +0000 (14:23 +0200)
committerLaszlo Ersek <lersek@redhat.com>
Tue, 22 May 2018 14:30:44 +0000 (16:30 +0200)
commit8d65d3b25e35a2e968395d261b34416776b95d9e
treeb967aeeb81deccd4c1de4c4a477ef2a003efe1d5
parentb9777bb42e4fbd5a570cab501cf0d2eaa7e2a525
OvmfPkg/PlatformBootManagerLib: process TPM PPI request

Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI
requests from PlatformBootManagerAfterConsole().

Laszlo understanding of edk2 is that the PPI operation processing was
meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI
drivers couldn't interfere with PPI opcode processing *at all*.

He suggested that we should *not* call
Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because,
an "auth" console, i.e. one that does not depend on a 3rd party
driver, is *in general* impossible to guarantee. Instead we could opt
to trust 3rd party drivers, and use the "normal" console(s) in
AfterConsole(), in order to let the user confirm the PPI requests. It
will depend on the user to enable Secure Boot, so that the
trustworthiness of those 3rd party drivers is ensured. If an attacker
roots the guest OS from within, queues some TPM2 PPI requests, and
also modifies drivers on the EFI system partition and/or in GPU option
ROMs (?), then those drivers will not load after guest reboot, and
thus the dependent console(s) won't be used for confirming the PPI
requests.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf