From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web10.38707.1629809761949606240 for ; Tue, 24 Aug 2021 05:56:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OW/BfY6I; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 24F1D6103E for ; Tue, 24 Aug 2021 12:56:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629809761; bh=h048X76WLZH+pTutUHOY1FiPF/e/DXsHhkCpZUi4ybE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OW/BfY6ImuOTuv6ZSoCnvnnJCPoqlXZbCZEBlGQzg25T/jwycXf6cWKemjgmpxCjk +YwflK2La+LIVOXWKsYWhOcvVtw5vDJyCSrBvC5X5PfZVqOi+Dqf/0ixAP3pJWDgwy 4sZ8XknAsOoK7z+WZIYTDH0T0qbuSrgSVYD5wjDENfT36K6oKiPVZLre8oMmzOI/45 uleEwbVa1Pu59T5z3VrIzFR+OqLBzYaOhYQVPa8HnBw65W0Mszu3qh30F5+fo1wLP7 EIRZzDejexWhrqwhWuMG+BTnDq8AxtRdR0O6GGYJ/3ZUedZnecwwhjqEbORvvCFg59 q2JxDm8EWWrvA== Received: by mail-ot1-f44.google.com with SMTP id i8-20020a056830402800b0051afc3e373aso34472083ots.5 for ; Tue, 24 Aug 2021 05:56:01 -0700 (PDT) X-Gm-Message-State: AOAM531ZIin3rfNN3KPpa7HnmsNYUeCz+EeUDCNjZxShqC+mewwvKdoE ZGbYYjXC7SE7CfOzDPj/dzFBFp4SSeTxYYhY+1w= X-Google-Smtp-Source: ABdhPJyv1lqM1ostxjfi01LtQhwAPSS1V4lZyrZ9tec/BUrF2azfJZHSQsHuRz9pHjBGARV6b35f0qSsV8/Eo3LGurI= X-Received: by 2002:a05:6830:124b:: with SMTP id s11mr1503215otp.90.1629809760490; Tue, 24 Aug 2021 05:56:00 -0700 (PDT) MIME-Version: 1.0 References: <95f116893a4a17c7e0966e240a650f871c9f9392.1628767741.git.min.m.xu@intel.com> <20210819064937.o646vxjebwzgfgoz@sirius.home.kraxel.org> <20210820072253.plne3mudm3dj6777@sirius.home.kraxel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 24 Aug 2021 14:55:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c To: "Xu, Min M" Cc: Gerd Hoffmann , "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Content-Type: text/plain; charset="UTF-8" On Tue, 24 Aug 2021 at 14:07, Xu, Min M wrote: > > On August 20, 2021 3:23 PM, Gerd Hoffmann wrote: > > On Thu, Aug 19, 2021 at 02:27:16PM +0000, Min Xu wrote: > > > On August 19, 2021 2:50 PM, Gerd Hoffmann wrote: > > > > > +/** > > > > > + In Tdx guest, some information need to be passed from host VMM > > > > > +to > > > > guest > > > > > + firmware. For example, the memory resource, etc. These > > > > > + information are prepared by host VMM and put in HobList which > > > > > + is described in > > > > TdxMetadata. > > > > > > > > What kind of information is passed to the guest here? > > > Please see > > > > > https://software.intel.com/content/dam/develop/external/us/en/document > > > s/tdx-virtual-firmware-design-guide-rev-1.pdf > > > Section 4.2 TD Hand-Off Block (HOB) > > > > So basically the physical memory map. > > qemu has etc/e820 for that. > > > > > > qemu has fw_cfg to pass information from the VMM to the guest > > firmware. > > > > What are the reasons to not use fw_cfg? > > > Not all the VMM support fw_cfg. Cloud-Hypervisor is the example. > > > > I can't see any support for Cloud-Hypervisor in OVMF. > Right that currently OVMF is not supported by Cloud-Hypervisor in Td guest. But we're > planning to support Cloud-Hypervisor to launch OVMF in Td guest and have done > some POC. If cloud hypervisor support is coming to OVMF, please contribute those patches first, so they can be discussed in public. Adding special facilities here to accommodate out of tree functionality that may look completely differently after review is not the right way to approach this. -- Ard. > > > > Also FreeBSD's bhyve doesn't support fw_cfg either and has its own ways to > > detect memory. Cloud-Hypervisor can surely do that too. > > > > So, why does this matter? > Yes, Cloud-Hypervisor has some POC to launch OVMF in Non-Td guest. In that POC > Cloud-Hypervisor leverage a 4k page in MEMFD and pass ACPI data to guest > Firmware in that memory. > https://github.com/cloud-hypervisor/edk2 "ch" branch > https://github.com/cloud-hypervisor/edk2/commit/52cb72a748ef70833100ca664f6c2a704c28a93f > > > > > https://github.com/cloud-hypervisor/cloud-hypervisor > > > TD Hob list gives Cloud-Hypervisor a chance to pass information to guest > > firmware. > > > For example, ACPI can be downloaded from QEMU via fw_cfg to firmware. > > > But Cloud-Hypervisor cannot pass ACPI via fw_cfg. In this situation, > > > TD Hob can resolve this problem. > > > > Sure, but again, why does this matter? For qemu? > I don't quite understand the question here(For qumu?). > What I mean in my last answer is that TD Hob can resolve the problem when the host VMM > doesn't support fw_cfg communication mechanism. > For the host VMMs which doesn't support fw_cfg, when ACPI data need to be passed to guest > firmware, a 4k page (to hold ACPI data) is added in MEMFD. Then when SMBIOS is needed, > shall we add another page in MEMFD? If the ACPI data is too big to be held in a 4k page, then > the size of the reserved memory region in MEMFD is the restriction. > > > > I don't like the idea to have TDX take a completely different code paths. > > That increases the code complexity and makes testing harder for no good > > reason. > TD Hob is not a completely different code path. This is a useful supplement to the fw_cfg which > is not supported by some host VMM. > From another perspective TD Hob can be treated as a set of launch parameter by host VMM. > It provides the flexibility for the host VMM to bring up the guest firmware with more parameters. > Another benefit is that TD Hob can be measured into some secure register (for example, in TD guest > it is RTMR registers, like the TPM PCR) so that attestation can be done based on the measurement. > > Thanks Gerd for the comments. I am not sure if my explanation addressed your concern. Your comments > is always welcomed. > > > > Thanks! > Min