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

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

> This strict isolation between DXE and PEI means that once we're in DXE,
> any bugs in PEI can't be exploited to attack the DXE environment.  

[jiewen] I would disagree the statement above. 
There is not strict isolation. Actually no isolation at all.
The DXE is loaded by PEI. 
A bug in PEI has global impact and it can definitely be used to attack the DXE.

thank you!
Yao, Jiewen


> 在 2021年11月23日，下午10:27，James Bottomley <jejb@linux.ibm.com> 写道：
> 
> On Tue, 2021-11-23 at 13:07 +0000, Yao, Jiewen wrote:
>> Comment below only:
>> 
>>> I am persuaded to let config-a adopt the OVMF way, because the
>>> threat model of config-A is same as the normal OVMF.
>>> But config-B is NOT.
>>> Different threat model drives different solution.
>>> I completely don't understand why they must be same.
>> 
>> I don't understand why you want separate them.  Improving OvmfPkg
>> security is good for both OVMF and TDVF.  For TDVF it is clearly much
>> more important due to the different threat model, but it is good for
>> OVMF too.  Likewise edk2 in general.
>> 
>> [Jiewen] My answer is very clear as I mentioned multiple times.
>> The threat model is different.
>> IMHO, talking about "Improving OvmfPkg security" without a clear
>> threat model is *meaningless*.
>> All mitigation must be based upon threat mode and security objective.
>> Otherwise, what you are doing might be either unnecessary or
>> insufficient.
> 
> Can we take a step back and look at the bigger picture.  The way EFI is
> supposed to operate, according to the architecture model:
> 
> https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
> (Figure 1 and Table 4)
> 
> is that SEC is supposed to be as small and compact as possible, so it
> could be ROM installed without worrying about upgrade issues.  It's job
> is only to get the CPU initialized to the point it can run PEI, measure
> PEI and transfer control.  Security depends on the smallness of SEC
> because if it's rom installed (as a root of trust ought to be) it can't
> be upgraded to fix a bug.
> 
> PEI is supposed to initialize the hardware: set up the CPU, memory
> Application Processors and board configuration so we're in a known
> state with described features for DXE.  It then measures DXE (only if
> SEC didn't measure it) and hands off to DXE.  PEI code is designed not
> to interact with anything except setup to minimize external
> exploitation of internal bugs.
> 
> DXE is supposed to contain only runtime code, including device drivers.
> 
> The security point here is that the job of PEI is over as soon as it
> hands off to DXE, so at that point all the PEI code could be discarded
> (it usually isn't, but it could be).
> 
> This strict isolation between DXE and PEI means that once we're in DXE,
> any bugs in PEI can't be exploited to attack the DXE environment.  This
> allows us to minimize DXE which is where most of the main risk of
> configuration based exploitation is.
> 
> In this security model, you increase security by moving as much code as
> you can from DXE to PEI because the true attack surface is DXE.
> 
> To a lot of us, cutting out PEI, which requires redistributing code
> into DXE sounds like an increase not a reduction in the attack surface
> of the code.  You can argue that OVMF doesn't obey the model above and
> has a lot of initialization code in DXE anyway, but then the correct
> route would be to fix our PEI/DXE separation to recover the security
> properties.
> 
>>> If you force me to add PEI to config-B. Finally, that causes TDVF
>>> config-B is compromised due to an issue in PEI.
>>> Who will take the responsibility?  Will you or RedHat take that?
>> 
>> Bugs happen.  There could also be bugs in the additional SEC code you
>> need for platform setup in a non-PEI configuration ...
>> 
>> [Jiewen] I agree. That is why we need smaller code.
>> We can just focus on review that small portion of code what we have
>> written for TDVF, instead of the whole PEI.
>> We have process to review and maintain the extra TDVF code.
> 
> This depends ... if you agree with the security model outlined above,
> bugs in PEI are less of a problem because they can't be exploited.  Or
> do you not agree with this security model?
> 
> Security isn't about total bug elimination, it's about exploit
> elimination.  You fix a security vulnerability either by fixing the bug
> that can be exploited or removing the ability to exploit it.  This is
> the reason for technologies like NX ... they don't stop people
> exploiting bugs to write code to the stack, but they do mean that once
> you have the code on the stack you can no-longer execute it and the
> attackers have to move on to other means of gaining control.
> 
> The great thing about exploit elimination vs bug elimination is the
> former can usually be done on a whole class of bugs and the latter
> requires a whack-a-mole per bug type approach.
> 
> James
> 
>