On Tuesday, March 12, 2024 7:04 PM Gerd Hoffmann wrote: > 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? > For TD-Guest, VMM is out of TCB, the configuration is untrusted data. From the security perspective, it must be measured into RTMR[0]
> > 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? > The ACPI tables from QEMU has been measured in edk2 . There are detail message : https://edk2.groups.io/g/devel/message/99441 For smbios tables, we would double check it and update in next version. > 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. Yes , that's good idea. We would prepare the patch series in next version. > > 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. For etc/e820 , it is used in TD-Guest, PlatformInfoHob->LowMemory would be updated with the low memory size now. > 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. Yes, agree. > (2) Make sure we measure the fw_cfg entries in a deterministic > order so the measurements are stable. Yes, agree. > (3) Cache the measured data somewhere if needed multiple times > (or simply cache unconditionally). > Yes, agree. Cache the measured data into HOB in the PEI phase and cache the measured data into the global variables in the DXE phase. How about this? > 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. Yes, agree. > > > +#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. Yes, we would update in next version. Thanks Ceping -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116711): https://edk2.groups.io/g/devel/message/116711 Mute This Topic: https://groups.io/mt/104880546/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
