From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.11237.1629872560451069708 for ; Tue, 24 Aug 2021 23:22:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dbkiq1Mk; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629872559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LPRSqYZOJWE1M9Bp6UygxGG3OpgOVa5iwwr4wUoTHf0=; b=dbkiq1Mkw1Af65frPOltojmaHFehZfJYLGV5RvpbNJwCOjfIjrpOHAhmiFjXsL9rcQKAqm +hFnQx0tFzb+fO81CjBDuofd2PP1GwpjCRXrXMT8HHOnqOG+Q5C8vw7FEy90Oh6fp6SOHt c6q/pGh1uZ8c+aJxT2b+M9FhX2LQPAc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-447-qmvp-PwHMoaI7LNsfiad1w-1; Wed, 25 Aug 2021 02:22:35 -0400 X-MC-Unique: qmvp-PwHMoaI7LNsfiad1w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9DED48799EC; Wed, 25 Aug 2021 06:22:33 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F6FB1893C; Wed, 25 Aug 2021 06:22:33 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 5AB851800843; Wed, 25 Aug 2021 08:22:30 +0200 (CEST) Date: Wed, 25 Aug 2021 08:22:30 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Message-ID: <20210825062230.m5ugbo6xons5fvrn@sirius.home.kraxel.org> References: <95f116893a4a17c7e0966e240a650f871c9f9392.1628767741.git.min.m.xu@intel.com> <20210819064937.o646vxjebwzgfgoz@sirius.home.kraxel.org> <20210820072253.plne3mudm3dj6777@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > 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. > > 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 Post the Cloud-Hypervisor patches to the list for review if you want them included in OVMF. out-of-tree patches lingering in some random branch @ github do not matter. > > > 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?). Well, each VMM has different interfaces for guest <-> host communication. qemu/kvm uses fw_cfg. Xen and Bhyve have something different, and Cloud-Hypervisor seems to have something different again. > 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. Sure. If Cloud-Hypervisor wants use that (for both TDX and non-TDX probably), fine. Submit the patches and we can discuss details. But why do you want switch qemu/kvm from fw_cfg to TD Hob? > > 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. The code uses that unconditionally though and not only in case fw_cfg is not available. > 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. I'm wondering what you are running on the host? I assumed we are discussing qemu/kvm as VMM, is that actually the case? Or do you use Cloud Hypervisor? qemu doesn't provide a TD Hob. So, when running qemu you probably have some out-of-tree patches adding that. Have you submitted them upstream? What is the status? I suspect you need to come up with some *very* good arguments to get that accepted. The need to bring parameters to the guest firmware is the reason why fw_cfg exists in the first place ... > 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. fw_cfg is measured too (according to one of the tdx pdfs, don't remember which one). take care, Gerd