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

["Yao, Jiewen" <jiewen.yao@intel.com>]

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 objection 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@linux.ibm.com>
> Sent: Tuesday, November 23, 2021 11:38 PM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>; Xu, Min M <min.m.xu@intel.com>;
> Ard Biesheuvel <ardb+tianocore@kernel.org>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Brijesh Singh <brijesh.singh@amd.com>; Erdem
> Aktas <erdemaktas@google.com>; Tom Lendacky <thomas.lendacky@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
>