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

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

On Wednesday, March 20, 2024 6:05 PM Gerd Hoffmann wrote:
> 
> We don't need to read + cache all fw_cfg data.  We only need to cache the
> entries which (a) must be measured, and (b) will not be measured in some
> other way.
> 
I am afraid that it is difficult to determine which fw_cfg items 
are need to be cached and measured, since there are some fw_cfg items are
optional with special qemu cmd.
Example : 
fw_cfg item: opt/ovmf/X-PciMmio64Mb  
depends on qemu command: "-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=N"

> The big entries I'm aware of are:
>  (1) kernel for direct boot (no fw_cfg measurement needed, binary
>      will be measured before launch).
>  (2) ACPI tables (no fw_cfg measurement needed, acpi tables are
>      measured when installed).
>  (3) smbios tables (to be decided, could be handled similar to ACPI).
> 
> Anything else where you have size concerns?
So far I don't find other big entries.

> 
> > Further more this is not a lazy mode which means some fw_cfg data may
> > be read but it is not to be consumed later.
> 
> The problem with lazy mode is that the measurement order is not fixed.
We'd better define what's the "fixed measurement order".
Think about such scenario:
There are 5 fw_cfg items ("A-B-C-D-E"), and C is an optional one which depends on special qemu cmd
 (example : etc/boot-menu-wait depends on qemu command: " -boot menu=on,splash-time=N").
	
So, there are two measurement orders in different qemu command:
1, "A-B-C-D-E" (with qemu command "-boot menu=on,splash-time=N ")
2, "A-B-D-E" (without qemu command "-boot menu=on,splash-time=N ") 

Is the "A-B-C-D-E" or "A-B-D-E"  fixed order ? 

What's your thoughts ?

> 
> > We propose below solution :
> >
> > Add a new API in QemuFwCfgLib,
> > RETURN_STATUS QemuFwCfgGetData(fw_cfg_name, *size, *value,
> FW_CFG_GET_DATA_FLAG flag).
> 
> I'd suggest to *not* touch the existing interfaces for reading entries.
> Instead change the existing functions to first check the cache, in case there is
> no cache entry go read from fw_cfg.
Actually we don't touch the existing interface for reading entries.
The API is newly added.

>
> Add a new interface for adding fw_cfg entries to the cache, with optional
> measurement.
Do you mean to add a new API (example : QemuFwCfgReadBytes2(*size, *buffer, Flag))
 with optional measurement to cache fw_cfg data?

> 
> >  And it can reduce the code complexity because it pack 3 fw_cfg call
> > (QemuFwCfgFindFile/QemuFwCfgSelectItem/QemuFwCfgReadBytes) into one
> call.
> 
> There are a few places in the code which expect they can read fw_cfg files in
> multiple chunks (i.e. call QemuFwCfgReadBytes multiple times).
> 
Actually we can handle the case with the new API.
For example, etc/e820 is read in chunks. 
Current code like below:
  QemuFwCfgSelectItem (FwCfgItem);
  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
    QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
    Callback (&E820Entry, PlatformInfoHob);
  }

We can update it like below:
  QemuFwCfgGetData("etc/e820", &FwCfgSize,  Buffer, Flag);
  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) { 
    EFI_E820_ENTRY64 *E820Entry = (EFI_E820_ENTRY64 *)(Buffer + Processed);
    Callback (E820Entry, PlatformInfoHob);
  }

> Also note that not all fw_cfg entries are (pseudo-)files.
I am not sure what you mean about (pseudo-)files.

Could you give some instructions?

Base on your comments,  does this mean there are other fw_cfg data 
which are read from QEMU via different method (not QemuFwCfgFindFile/QemuFwCfgSelectItem/QemuFwCfgReadBytes) ?

If it is the case, could you please give an example? 

Thanks 
Ceping


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116950): https://edk2.groups.io/g/devel/message/116950
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]
-=-=-=-=-=-=-=-=-=-=-=-