From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 17314AC1099 for ; Tue, 12 Mar 2024 11:04:14 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=TgAyWJ1LgmhOAteGaZvFuzkyM+xDI37WoWoZr9vEYhk=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20240206; t=1710241453; v=1; b=5NTc1OMcweBUOksl5S3DWZV0bjIQOkLsk8/q3I1QpcNZam3NRxferiPdQ0keDEWHVJNXw8TI vrxmVJULNl0H8E56Ep+ozml+OnopcUPWdbSQzTggUbAOvA6rfdm1PsLZZUO2L1OBsHKVZoJrZ1X UvczOO3rKqj7DWLvOwyljHnWmL6XZG41k/pingICDYAAJYdTh+925WSfp+u4nBfHpgDTRBoaQnl K3rOTuofs3QVF2LQ0Fg5jPHx3EsTDVHd8Qya48I3Gzp/Jy2N59eTfJd+5LOMJj3AtRV9uQrBE6O Xvsi+ZgY6dc59V+aLaoHG4G4ScA7EvSEZcXB/NYua6xxw== X-Received: by 127.0.0.2 with SMTP id a2utYY7687511x4H0aKYXTtw; Tue, 12 Mar 2024 04:04:13 -0700 X-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.6037.1710241452908361558 for ; Tue, 12 Mar 2024 04:04:13 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-210-fsdX_DOyNR6iXx58OFc86g-1; Tue, 12 Mar 2024 07:04:10 -0400 X-MC-Unique: fsdX_DOyNR6iXx58OFc86g-1 X-Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AC8B5101A523; Tue, 12 Mar 2024 11:04:09 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.160]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 86FB5492BC4; Tue, 12 Mar 2024 11:04:09 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 486BA18009A3; Tue, 12 Mar 2024 12:04:08 +0100 (CET) Date: Tue, 12 Mar 2024 12:04:08 +0100 From: "Gerd Hoffmann" To: Ceping Sun Cc: devel@edk2.groups.io, Erdem Aktas , Jiewen Yao , Min Xu , Elena Reshetova Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-menu-wait Message-ID: References: <20240312235146.3777997-1-cepingx.sun@intel.com> MIME-Version: 1.0 In-Reply-To: <20240312235146.3777997-1-cepingx.sun@intel.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Tue, 12 Mar 2024 04:04:13 -0700 Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 8I6Oi6lmPzytMgYBbnC6RfF8x7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=5NTc1OMc; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Wed, Mar 13, 2024 at 07:51:46AM +0800, Ceping Sun wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4415 > > Refer to the section 8.3.4 of tdx-virtual-firmware-design-guide spec, > OVMF would uses FW_CFG_IO_SELECTOR(0x510) and FW_CFG_IO_DATA(0x511) > to get configuration data from QEMU. From the security perspective, > if TDVF uses this method, configuration data must be measured into > RTMR[0]. > > Currently, the etc/boot-menu-wait is using in TDVF, it required to be > measured into RTMR[0]. That config item doesn't change the control flow. Do we have to measure it? > This is the first patch and will continue to be updated to measure > additional configuration data. What else is in the pipeline? At least ACPI and smbios tables I assume? I'd like to have a more complete picture first. Also I think it makes sense to have a single patch series implementing all of it instead of merging it piece by piece, to avoid having multiple edk2 releases where the measurements are changing. Note that the current code (looking at a non-tdx build) reads several fw_cfg items multiple times. Entries 0 and 1 (used for probing fw_cfg presence), 0x19 (file directory) are read most frequently. etc/e820 is scanned multiple times too; tvdf in tdx mode wouldn't use it though. If we are going to measure the fw_cfg bits used by ovmf / tdvf I think we have to: (1) Make sure we read + measure the data once. (2) Make sure we measure the fw_cfg entries in a deterministic order so the measurements are stable. (3) Cache the measured data somewhere if needed multiple times (or simply cache unconditionally). We probably wouldn't measure all fw_cfg entries. The ones used by direct kernel boot can be skipped for example. The kernel image will be measured anyway before it is launched. > +#define EV_POSTCODE_INFO_QEMU_BOOTMENU_WAIT_TIME_DATA "QEMU BOOTMENU WAIT TIME" "QEMU FW CFG" ? I think it makes sense to have one name and one struct for all qemu fw_cfg items. Or maybe two, one for the file-name based entries and one for the others. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116677): https://edk2.groups.io/g/devel/message/116677 Mute This Topic: https://groups.io/mt/104880546/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-