My apology - fix typo: objection on the discussion => objective on the discussion.
> -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen > Sent: Wednesday, November 24, 2021 11:16 AM > To: j...@linux.ibm.com; devel@edk2.groups.io > Cc: Gerd Hoffmann <kra...@redhat.com>; Xu, Min M <min.m...@intel.com>; > Ard Biesheuvel <ardb+tianoc...@kernel.org>; Justen, Jordan L > <jordan.l.jus...@intel.com>; Brijesh Singh <brijesh.si...@amd.com>; Erdem > Aktas <erdemak...@google.com>; Tom Lendacky <thomas.lenda...@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 <j...@linux.ibm.com> > > Sent: Tuesday, November 23, 2021 11:38 PM > > To: devel@edk2.groups.io; Yao, Jiewen <jiewen....@intel.com> > > Cc: Gerd Hoffmann <kra...@redhat.com>; Xu, Min M <min.m...@intel.com>; > > Ard Biesheuvel <ardb+tianoc...@kernel.org>; Justen, Jordan L > > <jordan.l.jus...@intel.com>; Brijesh Singh <brijesh.si...@amd.com>; Erdem > > Aktas <erdemak...@google.com>; Tom Lendacky > <thomas.lenda...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
