Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[heyi.guo]

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

Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[Yao, Jiewen]

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.guo@linaro.org" <heyi.guo@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

Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[heyi.guo]

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 +0000, 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.guo@linaro.org" <heyi.guo@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

Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[Yao, Jiewen]

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.guo@linaro.org [mailto:heyi.guo@linaro.org]
> Sent: Monday, August 13, 2018 9:07 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: heyi.guo@linaro.org; edk2-devel@lists.01.org; Zhang, Chao B
> <chao.b.zhang@intel.com>
> 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 +0000, 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.guo@linaro.org"
> <heyi.guo@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

Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[heyi.guo]

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 +0000, 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.guo@linaro.org [mailto:heyi.guo@linaro.org]
> > Sent: Monday, August 13, 2018 9:07 AM
> > To: Yao, Jiewen <jiewen.yao@intel.com>
> > Cc: heyi.guo@linaro.org; edk2-devel@lists.01.org; Zhang, Chao B
> > <chao.b.zhang@intel.com>
> > 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 +0000, 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.guo@linaro.org"
> > <heyi.guo@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

Re: Question about SecurityPkg/DxeTcg2PhysicalPresenceLib

[Laszlo Ersek]

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