Re: [edk2] Question about SecurityPkg/DxeTcg2PhysicalPresenceLib
Hello Heyi,
(+ Marc-André and Stefan)
On 08/14/18 08:18, heyi@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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about SecurityPkg/DxeTcg2PhysicalPresenceLib
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? Thanks, Heyi On Mon, Aug 13, 2018 at 01:10:57AM +, Yao, Jiewen wrote: > The code in SecurityPkg\Library\DxeTcg2PhysicalPresenceLib can be treated as > the example for the platform with trusted console. > > If a platform does not have a trusted graphic console, the platform may > implement another DxeTcg2PhysicalPresenceLib instance to get user > confirmation. For example, use the serial port, special hot key, etc. > > Thank you > Yao Jiewen > > > -Original Message- > > From: heyi@linaro.org [mailto:heyi@linaro.org] > > Sent: Monday, August 13, 2018 9:07 AM > > To: Yao, Jiewen > > Cc: heyi@linaro.org; edk2-devel@lists.01.org; Zhang, Chao B > > > > Subject: Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib > > > > Is there any work around if we don't have such trusted console on available > > hardware platforms? Is there any example implementation which we can refer > > to? > > > > Thanks, > > > > Heyi > > > > On Fri, Aug 10, 2018 at 09:12:46AM +, Yao, Jiewen wrote: > > > by design a platform need define a trusted console and only connect this > > trusted console before endofdxe > > > > > > thank you! > > > Yao, Jiewen > > > > > > > > > > 在 2018年8月10日，下午4:50，"heyi@linaro.org" > > 写道： > > > > > > > > Hi folks, > > > > > > > > The function Tcg2PhysicalPresenceLibProcessRequest in > > DxeTcg2PhysicalPresenceLib > > > > requires to be invoked after console is ready, and in the function it > > > > will call > > > > VariableLockProtocol->RequestToLock(), while variable RequestToLock() > > requires > > > > to be called before "End Of Dxe" event, or else it will return > > ACCESS_DENIED. > > > > > > > > However, in PI spec 1.6, section 5.1.2.1 "End of DXE Event", it says > > > > "Prior to > > > > connecting consoles, the platform should signal the event 'End of > > > > DXE'". So > > > > there seems to be contradiction between these implementations and PI > > spec. > > > > > > > > If we follow below work flow: > > > > End of DXE -> connect console -> Tcg2PhysicalPresenceLibProcessRequest() > > -> > > > > Variable RequestToLock() -> we will get ACCESS_DENIED. > > > > > > > > Please advise, > > > > > > > > Thanks, > > > > > > > > Heyi ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about SecurityPkg/DxeTcg2PhysicalPresenceLib
The code in SecurityPkg\Library\DxeTcg2PhysicalPresenceLib can be treated as the example for the platform with trusted console. If a platform does not have a trusted graphic console, the platform may implement another DxeTcg2PhysicalPresenceLib instance to get user confirmation. For example, use the serial port, special hot key, etc. Thank you Yao Jiewen > -Original Message- > From: heyi@linaro.org [mailto:heyi@linaro.org] > Sent: Monday, August 13, 2018 9:07 AM > To: Yao, Jiewen > Cc: heyi@linaro.org; edk2-devel@lists.01.org; Zhang, Chao B > > Subject: Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib > > Is there any work around if we don't have such trusted console on available > hardware platforms? Is there any example implementation which we can refer > to? > > Thanks, > > Heyi > > On Fri, Aug 10, 2018 at 09:12:46AM +, Yao, Jiewen wrote: > > by design a platform need define a trusted console and only connect this > trusted console before endofdxe > > > > thank you! > > Yao, Jiewen > > > > > > > 在 2018年8月10日，下午4:50，"heyi@linaro.org" > 写道： > > > > > > Hi folks, > > > > > > The function Tcg2PhysicalPresenceLibProcessRequest in > DxeTcg2PhysicalPresenceLib > > > requires to be invoked after console is ready, and in the function it > > > will call > > > VariableLockProtocol->RequestToLock(), while variable RequestToLock() > requires > > > to be called before "End Of Dxe" event, or else it will return > ACCESS_DENIED. > > > > > > However, in PI spec 1.6, section 5.1.2.1 "End of DXE Event", it says > > > "Prior to > > > connecting consoles, the platform should signal the event 'End of DXE'". > > > So > > > there seems to be contradiction between these implementations and PI > spec. > > > > > > If we follow below work flow: > > > End of DXE -> connect console -> Tcg2PhysicalPresenceLibProcessRequest() > -> > > > Variable RequestToLock() -> we will get ACCESS_DENIED. > > > > > > Please advise, > > > > > > Thanks, > > > > > > Heyi ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about SecurityPkg/DxeTcg2PhysicalPresenceLib
Is there any work around if we don't have such trusted console on available hardware platforms? Is there any example implementation which we can refer to? Thanks, Heyi On Fri, Aug 10, 2018 at 09:12:46AM +, Yao, Jiewen wrote: > by design a platform need define a trusted console and only connect this > trusted console before endofdxe > > thank you! > Yao, Jiewen > > > > 在 2018年8月10日，下午4:50，"heyi@linaro.org" 写道： > > > > Hi folks, > > > > The function Tcg2PhysicalPresenceLibProcessRequest in > > DxeTcg2PhysicalPresenceLib > > requires to be invoked after console is ready, and in the function it will > > call > > VariableLockProtocol->RequestToLock(), while variable RequestToLock() > > requires > > to be called before "End Of Dxe" event, or else it will return > > ACCESS_DENIED. > > > > However, in PI spec 1.6, section 5.1.2.1 "End of DXE Event", it says "Prior > > to > > connecting consoles, the platform should signal the event 'End of DXE'". So > > there seems to be contradiction between these implementations and PI spec. > > > > If we follow below work flow: > > End of DXE -> connect console -> Tcg2PhysicalPresenceLibProcessRequest() -> > > Variable RequestToLock() -> we will get ACCESS_DENIED. > > > > Please advise, > > > > Thanks, > > > > Heyi ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about SecurityPkg/DxeTcg2PhysicalPresenceLib
by design a platform need define a trusted console and only connect this trusted console before endofdxe thank you! Yao, Jiewen > 在 2018年8月10日，下午4:50，"heyi@linaro.org" 写道： > > Hi folks, > > The function Tcg2PhysicalPresenceLibProcessRequest in > DxeTcg2PhysicalPresenceLib > requires to be invoked after console is ready, and in the function it will > call > VariableLockProtocol->RequestToLock(), while variable RequestToLock() requires > to be called before "End Of Dxe" event, or else it will return ACCESS_DENIED. > > However, in PI spec 1.6, section 5.1.2.1 "End of DXE Event", it says "Prior to > connecting consoles, the platform should signal the event 'End of DXE'". So > there seems to be contradiction between these implementations and PI spec. > > If we follow below work flow: > End of DXE -> connect console -> Tcg2PhysicalPresenceLibProcessRequest() -> > Variable RequestToLock() -> we will get ACCESS_DENIED. > > Please advise, > > Thanks, > > Heyi ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
