Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-menu-wait

["sunceping" <cepingx.sun@intel.com>]

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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-