From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mx.groups.io with SMTP id smtpd.web08.279.1623358923469518770 for ; Thu, 10 Jun 2021 14:02:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20161025 header.b=l2k9WAaW; spf=pass (domain: google.com, ip: 209.85.210.178, mailfrom: erdemaktas@google.com) Received: by mail-pf1-f178.google.com with SMTP id u18so2623562pfk.11 for ; Thu, 10 Jun 2021 14:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vmv5t1JEpbD00b9YP+Kse56HWF6IozBQJ2SbXHa2WLk=; b=l2k9WAaWS+Rdrc13xInARFZOL2xqDu06duof66T0jw1NKrG/bbHh/IIuitszsvswzm amX/MUVHsLN0IOXZh1i9W42j0laAql13OcPFiTnYdz2/uKE7dssNgM1ns/aiKTSuMG9o jh7D3vlXNNZH+5GXXtGPHvRtyvqtCVTbQbqM3hA2mz+zKu9M4f/atYF1VwgQwJpSFQvR vGseJZkBIl8k5/ZhhUlFjaYkxWWt7IRYrQZv6i83wlknC+oCmbzxrr3S9kGV0aeYo9aW 4obF2m4oq/w+h7vyCjnpswECl3b0XSdT/b0fElyr2XUyoXDg6U7G9feOf0qj30VGCF21 L18Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vmv5t1JEpbD00b9YP+Kse56HWF6IozBQJ2SbXHa2WLk=; b=Hk7ubBK5vLBRjXNB5QtlkvO1B+jNvDwVCid4CmpS8ifGVi3uXBXF1ikup+bwrc5KT6 854DSNFi0u/MZjY68/Kg68dcsamaThOdrcjdCgW8KXbJnq20Cl6kP4ENZWEK1AuJg10j rTB/7DldqZa4sSarwscPlKp4K/eoU2a5d+HDe80fAaW8jAT3hcNe7F/mqbri/eLhVfnv 4C5RMhE2QN/keAx8Tigauf+K+0AwyYu29HRpBNMN3RLbXZySzA80X/UZ0EvMYPWmjVi9 P/9HfPqASBqG6g6mMA5VoZhlpYIax9n4boA5RWrrn9rENaJXEg+dXV3c5agNO1I2GLm5 HyOA== X-Gm-Message-State: AOAM531NNS3zFw0oLYf4NzmD7WVAxbv+biRWwLF7ozpkZ8XQ7+JI8tfF qunVcMLN7KLrFDsD2zqf2iCGW50eJe52O4sxvnKZVw== X-Google-Smtp-Source: ABdhPJy+bEht4l8fvBrv7d4RyZT1SwN/A1UDwi6IFnEmFklcsjsafi/9D+4Fh0+tEdKPuNYyudlldJWvkTkyYfIh/Aw= X-Received: by 2002:a63:62c2:: with SMTP id w185mr325742pgb.76.1623358922511; Thu, 10 Jun 2021 14:02:02 -0700 (PDT) MIME-Version: 1.0 References: <8eabf1c1fba9bfcb7f6eb2247a1ba336e04952ca.camel@linux.ibm.com> In-Reply-To: <8eabf1c1fba9bfcb7f6eb2247a1ba336e04952ca.camel@linux.ibm.com> From: "Erdem Aktas" Date: Thu, 10 Jun 2021 14:01:51 -0700 Message-ID: Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: James Bottomley Cc: Paolo Bonzini , "Xu, Min M" , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" , Laszlo Ersek , Brijesh Singh , Tom Lendacky , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." Content-Type: text/plain; charset="UTF-8" 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 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 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 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