[edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

Wed Nov 24 03:21:16 UTC 2021

My apology - fix typo: objection on the discussion => objective on the discussion.

> -----Original Message-----
> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Yao, Jiewen
> Sent: Wednesday, November 24, 2021 11:16 AM
> To: jejb at linux.ibm.com; devel at edk2.groups.io
> Cc: Gerd Hoffmann <kraxel at redhat.com>; Xu, Min M <min.m.xu at intel.com>;
> Ard Biesheuvel <ardb+tianocore at kernel.org>; Justen, Jordan L
> <jordan.l.justen at intel.com>; Brijesh Singh <brijesh.singh at amd.com>; Erdem
> Aktas <erdemaktas at google.com>; Tom Lendacky <thomas.lendacky at amd.com>
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
> 
> I think we are discussing under different context.
> 
> First, the term "isolation" shall be clarified.
> In my context, "isolation" means two domain cannot impact each other.
> The isolation is enforced by a 3rd higher privileged component. Examples: Ring3
> apps are isolated by OS. TDs are isolated by TDX Module. That is why I say: there
> is no isolation.
> 
> In your context, if one domain jumps to another domain and never jump back,
> then you call it "isolation".
> 
> 
> Second, in EDKII, we have similar concept - we call trust region (TR):
> 1) Recovery Trust Region (PEI)
> 2) Main Trust Region (DXE-before EndOfDxe)
> 3) MM Trust Region (SMM)
> 4) Boot Trust Region (DXE w/o CSM-after EndOfDxe)
> 5) Legacy Trust Region (DXE with CSM-after EndOfDxe)
> 6) OS Trust Region (OS Boot)
> 
> We use term "transition" to describe the domain jump. We don’t use term
> "isolation".
> We use "isolation" where two co-existed RT cannot tamper each other. For
> example, MM trust region and Boot Trust Region are isolated.
> Actually, the only isolation example we have in BIOS is x86 SMM or ARM
> TrustZone.
> 
> We have below security assumption:
> 1) What can be trusted? The later launched TR can trust the earlier TR. Here
> "trust" means "use data input without validation"
> For example:
> 1.1) Main TR can trust the input from Recovery TR.
> 1.2) MM RT can trust the input from Main TR.
> 
> 2) What cannot be trusted? Here "not trust" means "validate data input before
> use "
> For example:
> 2.1) MM RT cannot trust the input from Boot TR.
> 2.2) Recovery RT cannot trust the input from Boot TR.
> 
> However, TR just means a region definition to help us do security analysis.
> It is NOT related to any security exposure, severity, or exploitability.
> There is no conclusion that a bug in PEI is more or less exploitable than DXE or
> SMM.
> 
> 
> Here, I have comment for the sentence below:
> 
> 1. " the PEI domain has very limited exposure, it's the DXE domain that has full
> exposure "
> [Jiewen] I don’t understand how that is concluded, on " limited exposure ", " full
> exposure ".
> 
> 2. "bugs in PEI code can't be used to exploit the system when it has transitioned
> to the DXE domain."
> [Jiewen] I disagree. A bug in PEI code may already modify the HOB, while the
> HOB is an architecture data input for DXE.
> If DXE relies on some malicious data from PEI, DXE might be exploited later.
> 
> 3. " but it does mean that there are fewer exploitability classes in PEI than DXE
> because the security domain is much less exposed."
> [Jiewen] I don’t understand how that is concluded, on  "fewer", "less".
> In history, there are security bugs in PEI and there are security bugs in DXE. I
> won't say fewer or less.
> Also because we use *LOCK* mechanism, and some LOCKs are enforced in PEI
> phase.
> A bug in PEI might be more severe than a bug in DXE.
> 
> 
> 
> Hi James
> Sorry, I am a little lost now.
> To be honest, I am not sure what is objective on the discussion.
> Are you question the general threat model analysis on UEFI PI architecture?
> Or are you trying to persuade me we should include PEI in TDVF, because you
> think it is safer to add code in PEI ?
> Or something else?
> 
> Please enlighten me that.
> 
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -----Original Message-----
> > From: James Bottomley <jejb at linux.ibm.com>
> > Sent: Tuesday, November 23, 2021 11:38 PM
> > To: devel at edk2.groups.io; Yao, Jiewen <jiewen.yao at intel.com>
> > Cc: Gerd Hoffmann <kraxel at redhat.com>; Xu, Min M <min.m.xu at intel.com>;
> > Ard Biesheuvel <ardb+tianocore at kernel.org>; Justen, Jordan L
> > <jordan.l.justen at intel.com>; Brijesh Singh <brijesh.singh at amd.com>; Erdem
> > Aktas <erdemaktas at google.com>; Tom Lendacky
> <thomas.lendacky at amd.com>
> > Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm
> to
> > support Tdx
> >
> > On Tue, 2021-11-23 at 15:10 +0000, Yao, Jiewen wrote:
> > > I would say the PEI owns the system and all memory (including the
> > > DXE).
> > >
> > > A bug in PEI may override the loaded DXE memory or the whole system.
> >
> > That's not the correct way to analyse the security properties.  From
> > the security point of view this is a trapdoor system: once you go
> > through the door, you can't go back (the trapdoor being the jump from
> > PEI to DXE).  The trapdoor isolates the domains and allows you to
> > analyse the security properties of each separately.  It also allows
> > separation of exposure ... which is what we use in this case: the PEI
> > domain has very limited exposure, it's the DXE domain that has full
> > exposure but, because of the trapdoor, bugs in PEI code can't be used
> > to exploit the system when it has transitioned to the DXE domain.
> >
> > > In history I did see PEI security issues.
> > > Some security issue in PEI caused system compromised completely. You
> > > even have no chance to run DXE.
> >
> > The security domain analysis above doesn't mean no bug in PEI is ever
> > exploitable but it does mean that there are fewer exploitability
> > classes in PEI than DXE because the security domain is much less
> > exposed.
> >
> > James
> >
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84012): https://edk2.groups.io/g/devel/message/84012
Mute This Topic: https://groups.io/mt/86739864/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-