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

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

> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Wednesday, November 24, 2021 4:12 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: jejb@linux.ibm.com; devel@edk2.groups.io; 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
> 
>   Hi,
> 
> > 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 ".
> 
> exposure == "the need to process external input, which an attacker might
> use to exploit bugs in edk2 by crafting input data accordingly."

[Jiewen] Thanks.

> 
> There isn't much external input to process in PEI phase.  Virtual
> machines are a bit different than physical machines.  They need to
> process some input from the host here which describes the virtual
> hardware so they can initialize it properly.  For example parse the
> etc/e820 fw_cfg file to figure how much memory is installed (or parse
> the td hob in case tdx is used).
> 
> That platform-specific code for virtual machine initialization must do
> careful sanity checking when you don't want trust the VMM of course.
> Whenever that code lives in SEC or PEI doesn't change the picture much
> though.

[Jiewen] I am not sure what information you are trying to convey.
I never said that TDVF don’t need check the input after remove PEI.
The check is always needed, no matter in PEI or SEC. I totally agree.

However, what I want to say is PEI has much more unnecessary code than SEC.
You never know the quality of the those unnecessary code. Maybe it has a security bug, but it is just not triggered.
For example, can you guarantee PEI code has not bug? Or DXE IPL has not bug?

What I did is a process of risk management - if PEI is removed, I don’t need care the risk brought by PEI.
Unless you can prove that the risk of PEI is zero, then the risk is there.



> 
> > 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.
> 
> Attacking PEI is harder though because the external input it
> processes is limited when compared to DXE.
> 
> Once you are transitioned to DXE you can't call into PEI Modules
> any more.
> 
> So, how would an attacker trick PEI code into modifying HOBs (or
> carrying out other actions under attackers control)?

[Jiewen] I would disagree " Attacking PEI is harder though because the external input it processes is limited when compared to DXE " 
First, the number of extern input != the difficulty of the attack.
Second, the number of extern input != the severity of the consequence.

On how to trick PEI, if you search the public UEFI BIOS attack history in the web, you can find example.
The attack simply used an integer overflow, to cause buffer overflow.
And the buffer overflow can be used to inject shellcode, then gain the execution privilege.
Finally, it can control the whole system.

Modifying HOB is not a difficult task, as long as there is proper vulnerability, being used to gain a memory write.

In security world, we always say: Even if you cannot do it, you cannot assume other people cannot do it.
Unless you can prove it cannot be done. Otherwise, anything might be possible.

That is why people are in favor of crypto notation and formal verification to prove something is correct.




> 
> take care,
>   Gerd