Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF


Erdem Aktas
 

Hi all,

Sorry for the late reply. I like to add some clarification on "one
binary". I feel like the way everyone uses the term "one binary" in
the email threads is causing some confusion.

As I have tried to explain before, we are not looking for everything
in a single binary. As Laszlo has mentioned in a lot of places, some
additional features are TDX specific and not worth pushing into the
OvmfPkgX64.dsc.

What we are asking with "one binary" is: Simply enabling OVMF + a
guest OS to boot in a TDX domain without breaking any existing
functionality. Intel should put everything else (specifically related
to remote attestation) in a separate platform configuration. This
aligns well with Laszlo's perspective and it is similar to what AMD is
doing as far as I can see.

Enabling a minimum functionality in OvmfPkgX64.dsc without breaking
existing functionality will allow a lot of flexibility for us for
integration/testing and productionization.
A separate platform configuration file can be used to provide all the
security guarantees that TDX provides.

Based on the above clarification, Intel has updated their slides
accordingly - I really appreciate their hard work and community
collaboration spirit. I am hoping that this clears up the confusion.

On Thu, Jun 3, 2021 at 9:12 AM Laszlo Ersek <lersek@redhat.com> wrote:

My point is that the "one binary" that the slide deck refers to (i.e.,
OvmfPkgX64.dsc) might prove OK for utilizing the Intel TDX *technology*
in itself. Simply enabling OVMF + a guest OS to boot in a TDX domain.
This is what we are asking as a single binary.

But "OvmfPkgX64.dsc" is *not* the "one binary" that is suitable for
remote attestation, which has a much broader scope, involving multiple
computers, networking, deployment, guest-owner/host-owner separation,
whatever. For the latter, we needed a separate platform anyway, even
with only SEV in mind; that's why "OvmfPkg/AmdSev/AmdSevX64.dsc" exists.
This is okay for us.

(10) This slide (slide 11) basically describes an intrusive
reorganization of "OvmfPkgX64.fdf". I don't think I can agree to that.
While confidential computing is important, it is not relevant for many
users. Even if we don't cause outright regressions for existent setups,
the maintenance cost of the traditional OVMF platform will skyrocket.

The big bunch of areas that SEV-ES introduced to MEMFD is already a big
complication. I'd feel much better if we could isolate all that to a
dedicated "remote attested boot" firmware platform, and not risk the
functionality and maintenance of the traditional platform. I think this
ties in with my comment (1).

For example, seeing a configuration firmware volume (CFV) with secure
boot keys embedded, in the "usual" FDF, will confuse lots of people, me
included. In the traditional OVMF use case, we use a different method:
namely OvmfPkg/EnrollDefaultKeys, for "priming" a variable store
template, in the build environment.
Embedding secure keys might be a good idea to remove the VMM from the
TCB but I agree with Laszlo, OvmfPkgX64 is not the best place to do
this. The existing secure boot flow should not be changed. Any
additional improvement to reduce the TCB can go TDX specific platform
communication.

(12) My comment is that the GUID-ed structure chain already starts at a
fixed GPA (the "AMD SEV option"). Ordering between GUID-ed structures is
irrelevant, so any TDX-specific structures should be eligible for
appending to, prepending to, or intermixing with, other (possibly
SEV-specific) structures. There need not be a separate entry point, just
different GUIDS.
I think there is a confusion in slide #13. I agree that the GUIDed
table should solve this issue. And I do not think there is any
dependency on SEV patches. I am assuming anyone can easily add an
entry to the GUIDed table and based on other responses, this seems
like a trivial implementation.

(13) Regarding "4G-0x20[0x10] is OVMF AP reset vector (used in OVMF
implementation)" -- I think this is a typo: this "AP reset vector" is
*not* used in OVMF. To my knowledge, it is a vestige from the UefiCpuPkg
reset vector. In OVMF, APs are booted via MpInitLib (in multiple
firmware phases), using INIT-SIPI-SIPI, and the reset vector for the
APs, posited through those IPIs, is prepared in low RAM.
I am guessing what Intel refers to is "SEV-ES resetblock" which sets
the AP reset vector (jump address) address.

(22) EmuVariableFvbRuntimeDxe

Ouch, this is an unpleasant surprise.

First, if you know for a fact that pflash is not part of the *board* in
any TDX setup, then pulling
Copying configuration variables into configuration volume is "good"
to reduce the TCB but not necessary to boot a guest with TDX is
enabled. Again it goes under the topic of what is minimum and what is
secure and TDX specific platform configuration.
So I think it should not be part of OvmfPkgX64.dsc


On Thu, Jun 3, 2021 at 4:19 PM Yao, Jiewen <jiewen.yao@intel.com> wrote:

Hi Laszlo.

To clarify your "one binary" feedback below, do you mean you suggest A) create a separate DSC (for example OvmfPkg/ConfidentialComputing.dsc) for a full solution including AMD SEC + Intel TDX + NonConfidentialComputing?
Or B) to create a standalone DSC for Intel TDX (for example, create a OvmfPkg/IntelTdx/IntelTdxXS64.dsc) ?

To me, A) does not change too much, we just create another DSC file - that is it.
Then the original OvmfPkgX64.dsc will only be used for POC/Testing purpose. It does not provide any security guarantee.
(The threat model is: we don't trust VMM. Without attestation, you don't know if VMM modified the OVMF.)
I think we should separate what is minimum which should go to the
OvmfPkgX64.dsc to enable the TDX and what is required for removing the
VMM from the TCB. Anything improving security guarantees can go to TDX
specific configuration files.


On Sun, Jun 6, 2021 at 5:49 AM Xu, Min M <min.m.xu@intel.com> wrote:

On June 6, 2021 7:30 PM, Michael Brown Wrote:
On 06/06/2021 03:03, Min Xu wrote:
(11) "Page table should support both 4-level and 5-level page table"

As a general development strategy, I would suggest building TDX
support in small, well-isolated layers. 5-level paging is not enabled
(has never been tested, to my knowledge) with OVMF on QEMU/KVM,
regardless of confidential computing, for starters. If 5-level paging
is a strict requirement for TDX, then it arguably needs to be
implemented independently of TDX, at first. So that the common edk2
architecture be at least testable on QEMU/KVM with 5-level paging
enabled.
Yes, 5-level paging is a strict requirement for TDX. I would wait for
the conclusion of the *one binary*.
The "one binary" decision isn't relevant here, is it? It would make more
sense to implement 5-level paging within the base EDK2 architecture. This
would allow that feature to be tested in isolation from TDX (and
consequently tested more widely), and would reduce the distance between
standard builds and TDX builds.
In our first version of TDVF, a static 5-level page table is used. It is simple and
straight forward. But for *one binary* solution, we have to consider the compatibility
with the current 4-level page table. That's why I said "I would wait for the conclusion
of the *one binary*"

Thanks for the suggestion. We will discuss the it internally first.

Michael

Join devel@edk2.groups.io to automatically receive all group messages.