Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

[erdemaktas@google.com]

Hi all,

>>Can we please pry a little bit at that "one binary" requirement?

I think when we call it a "one binary" requirement, it sounds like we
are asking something new but what we are asking is pretty much
captured by James Bottomley.
We do not want to generate different binaries for AMD, Intel, Intel
with TDX, AMD with SEV/SNP etc therefore we were expecting the TDX
changes to be part of the upstream code.
Of course there can be tuning or customization for specific use cases
but those are all future and product specific questions. I just do not
see the reason why the upstreamed code should have a limitation of not
being able to generate a single binary for the same architecture.

-Erdem

On Mon, Apr 12, 2021 at 7:34 AM James Bottomley <jejb@linux.ibm.com> wrote:
>
> On Mon, 2021-04-12 at 11:54 +0000, Yao, Jiewen wrote:
> > I totally agree with you that from security perspective, the best
> > idea to isolate AMD SEV/Intel TDX from standard OVMF.
>
> There's a big difference between building tuned binaries and separating
> the subsystems entirely.  Ideally we don't want customers running
> images to have to build them differently for Intel or AMD (a bit like
> how QEMU/KVM hide the VM differences from users), and Confidential
> Computing shares a huge amount of interface similarity, so we wouldn't
> want that separated.  I think the rule should be that if both Intel and
> AMD expose a feature in different ways, OVMF tries to expose a uniform
> API for that feature over two differing implementations.
>
> > Do you want to propose move AMD SEV support to another SEC?
>
> You mean have an entirely separate SEC for AMD, OVMF and Intel?  I
> really wouldn't do that: much that's in the SEC: page table setup,
> memory mapping and decompression is common to all of them.  This all
> follows for a lot of the components.
>
> To build separate binaries, we just need separate dsc and fdf files.
> Then I think the goal would be to share as much as possible to avoid
> duplicating the maintenance and possibly diverging the user API.
>
> James
>
>
>
>
> 
>
>