From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.12049.1629877948305514663 for ; Wed, 25 Aug 2021 00:52:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=K5j8QeIJ; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629877946; 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=dGPUDuqdSZNOUvP47wBfttGXlV73jt9nuZLh8CIbWGw=; b=K5j8QeIJnnEr7mL5BT03QBacs5RecYzBxWkpunw0Rvs2mVS2/Egtvp/R/DtxRJGqxNNq/S NIXiZ3A6SgmTxfqlgxqX+9FGRsF70Ddh0BD2W4WQxXRTbyNUsZm2WWBA6vP6MHgzCYXycb 50K3L/dIYIgg+k8MTXHQxaAiaXPr8ng= 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-314-bpNT7ce_MP2wS7vAvLU_FA-1; Wed, 25 Aug 2021 03:52:22 -0400 X-MC-Unique: bpNT7ce_MP2wS7vAvLU_FA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 06858185302F; Wed, 25 Aug 2021 07:52:21 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F63210023B0; Wed, 25 Aug 2021 07:52:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8E2AA1800903; Wed, 25 Aug 2021 09:52:18 +0200 (CEST) Date: Wed, 25 Aug 2021 09:52:18 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: Ard Biesheuvel , "Xu, Min M" , "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Message-ID: <20210825075218.mpmkcwu3zo6tykm2@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.84 on 10.5.11.22 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, > fw_cfg is just a KVM/QEMU specific way to pass some parameter, but not > all parameter. For example, OVMF today still get the memory size from > CMOS. > https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/MemDetect.c#L278 Patches to fix that are on the list. > In TDVF design, we choose the use TDX defined initial pointer to pass > the initial memory information - TD_HOB, instead of CMOS region. > Please help me understand what is the real concern here. Well, qemu settled to the fw_cfg design or a number of reasons. It is pretty flexible for example. The firmware can ask for the information it needs at any time and can store it as it pleases. I'd suggest to not take it for granted that an additional alternative way to do basically the same thing will be accepted to upstream qemu. Submit your patches to qemu-devel to discuss that. > That means, if you get the same data twice from the fw_cfg, the TDVF > must measure them twice. And TDVF may need handle the case that the > data in first call is different with the data in second call. Most fw_cfg entries are constant anyway, so we can easily avoid a second call by caching the results of the first call if that helps TDVF. > Using HOB in the initial pointer can be an alternative pattern to > mitigate such risk. We just need measure them once then any component > can use that. Also, it can help the people to evaluate the RTMR hash > and TD event log data for the configuration in attestation flow, > because the configuration is independent with the code execution flow. Well, it covers only the memory map, correct? All other configuration is still loaded from fw_cfg. I can't see the improvement here. How do you pass the HOB to the guest? Copy data to guest ram? Map a ro page into guest address space? What happens on VM reset? > Please be aware that confidential computing (TDX) changes the threat > model completely, any input from VMM is considered as malicious. > Current solution might be OK for normal OVMF. But it does not mean the > same solution is still the best one for confidential computing use > case. Well, SEV seems to be happy with fw_cfg. Any input from AMD on the topic? take care, Gerd