Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[Laszlo Ersek <lersek@redhat.com>]

Hello Heyi,

(+ Marc-André and Stefan)

On 08/14/18 08:18, heyi.guo@linaro.org wrote:
> Hi Jiewen,
>
> I searched the code in EDK2, and found there is another implementation
> of DxeTcg2PhysicalPresenceLib for OVMF: the function
> Tcg2PhysicalPresenceLibProcessRequest() is called in
> PlatformBootManagerAfterConsole() on OVMF, and it doesn't invoke
> VariableLockProtocol->RequestToLock() in
> Tcg2PhysicalPresenceLibProcessRequest().
>
> Is this also an reference solution? Does it have any drawback
> comparing with the implementation in SecurityPkg?

we didn't specifically intend the solution seen in OvmfPkg as a
"reference solution", but you are welcome to copy it if you wish.

With Marc-André and Stefan we had discussed the exact dependency problem
that you point out for a very long time. I have three comments on that
now.


(1) The answer that Jiewen gave you first (i.e., set up one trusted
console in the BeforeConsole PlatformBootManager hook) is documented in
the edk2 tree.

Unfortunately, it is not documented in the "PlatformBootManagerLib.h"
class header. But it is documented near the BeforeConsole call site in
BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]:

>   // Do the platform init, can be customized by OEM/IBV
>   // Possible things that can be done in PlatformBootManagerBeforeConsole:
>   // > Update console variable: 1. include hot-plug devices; 2. Clear ConIn and add SOL for AMT
>   // > Register new Driver#### or Boot####
>   // > Register new Key####: e.g.: F12
>   // > Signal ReadyToLock event
>   // > Authentication action: 1. connect Auth devices; 2. Identify auto logon user.
>   //
>   PERF_INMODULE_BEGIN("PlatformBootManagerBeforeConsole");
>   PlatformBootManagerBeforeConsole ();
>   PERF_INMODULE_END("PlatformBootManagerBeforeConsole");

See the "connect Auth devices" action.


(2) In a virtual machine especially, where the hardware configuration
might change from boot to boot, it's basically impossible to identify a
trusted console device for TPM / "physical presence" purposes. This is
why we needed a different solution for OvmfPkg.

The "trusted console before EndOfDxe" platform requirement is
impractical in general as well. To my understanding, the point of
processing (=confirming) the queued TPM2 PPI opcodes before EndOfDxe is
that 3rd-party UEFI drivers not interfere with their display and
acceptance. But, if you have a physical computer with only a USB
keyboard and a discrete PCIE GPU, then your *only* console, trusted or
not, is that pair of devices. For them to function together as a
console, the UEFI driver in the GPU option ROM has to be executed. And
that will only ever occur after EndOfDxe.

(BTW this example applies to virtual machines directly; you may have a
VM with an assigned (VFIO) GPU, and no other display device, not even a
serial port. In that case, no driver that is built into OVMF will let
you output anything to the screen.)


(3) The solution we chose can be read in the messages of the commits
that introduced (a) the Tcg2PhysicalPresenceLibProcessRequest()
implementation, (b) the call to the same, in OvmfPkg. (Just use
"git-blame".) Namely,

- b9777bb42e4f ("OvmfPkg: add Tcg2PhysicalPresenceLibQemu", 2018-05-22)

- 8d65d3b25e35 ("OvmfPkg/PlatformBootManagerLib: process TPM PPI
                request", 2018-05-22)

In the first patch, all code related to TCG2_PHYSICAL_PRESENCE*_VARIABLE
are dropped from the library instance, because QEMU's virtual TPM device
provides a non-standard hardware mechanism for queueing PPI opcodes for
after reboot. This obviates the info channel through UEFI variables (and
eliminates a *huge* complication with ACPI code that enters SMM for
variable access, etc).

(Our understanding is that the *queueing* of PPI opcodes is not a
firmware-privileged operation (i.e. a privileged user at the OS level is
allowed to do it); only the interactive *confirmation* of the queued PPI
opcodes is firmware-privileged.)

In the second patch, the solution is to consider all consoles trusted,
and to rely on the user to enable Secure Boot. Then Secure Boot will
verify those 3rd-party UEFI drivers as well that are necessary for
setting up consoles. If an attacker manages to compromise the OS and to
queue some crafted PPI opcodes, the firmware will still faithfully ask
the user for confirming those (i.e. the attacker cannot hide or
mis-represent the queued PPI opcodes). Because, the drivers instrumental
to console setup are protected from instruction stream tampering with
Secure Boot. (They are not protected from data-attacks by SB, but
neither are DXE drivers that are built directly into the system
firmware.)

Thanks
Laszlo