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 <ler...@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....@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...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#76339): https://edk2.groups.io/g/devel/message/76339 Mute This Topic: https://groups.io/mt/83283616/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
