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

["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