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 917E2D808CC for ; Thu, 21 Mar 2024 12:25:26 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=qdk4bZWfvSRUiy8Bok+JZzndqulTTrKn9FtPOo0POSk=; 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=1711023925; v=1; b=Czs+HwciCcB9vJ1DzxcKByZ6yJJ+Z7z5YuKa/egvbFSovqJ9ESP33ogX1PacXKvUWBjEYA8N DODTXTo7lppV06rFgFDpSSG7akR2jMmhOAluhiYnxhDLVIxd1cE7HDtFtP15aygR8JRTHCUByVZ XmOjbXMuWKS/2r8ZHeQ6KWOapnKKzQivFUqvORmxYJk/Npjl8VZVoLOKJt7OZd5Ar75PUGMxs27 4AvGYndISDDRQhVk0UFsrT/DSpsRsbsKXxoY+XP5nb8ghYemtzD523uR6w9BYPcu4Ex/fX3VETl 5h3Sem8UiMRNYBEhQOpzzxKlQgbM+oMYO0RY3DYMT8EUw== X-Received: by 127.0.0.2 with SMTP id 3dAKYY7687511xbsImEe1clu; Thu, 21 Mar 2024 05:25:25 -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.web11.6128.1711023924592455700 for ; Thu, 21 Mar 2024 05:25:24 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-422-lvXnG8VGNRGm7YgCx4AkaQ-1; Thu, 21 Mar 2024 08:25:20 -0400 X-MC-Unique: lvXnG8VGNRGm7YgCx4AkaQ-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 DD486380214F; Thu, 21 Mar 2024 12:25:18 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9A7588173; Thu, 21 Mar 2024 12:25:18 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8534C1800DCA; Thu, 21 Mar 2024 13:25:13 +0100 (CET) Date: Thu, 21 Mar 2024 13:25:13 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, cepingx.sun@intel.com Cc: "Aktas, Erdem" , "Yao, Jiewen" , "Xu, Min M" , "Reshetova, Elena" 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: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 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: Thu, 21 Mar 2024 05:25:24 -0700 Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 29chg5YKYVwZjkHVzPq46rcex7686176AA= 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=Czs+Hwci; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On Thu, Mar 21, 2024 at 08:39:13AM +0000, sunceping wrote: > 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" Well, just try to read them. If present they can just be measured. If not present we can either skip them, or measure with an empty data field to indicate it is not present. > > > 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 ? See above for optional items. I'm more concerned about reordering. We have a number of DXE modules reading fw_cfg entries. The order the modules are scheduled depends multiple factors (order in the firmware volume, depex), so that order may change. With lazy loading and measurement changes in the initialization order would also change the measurements even if the content of the fw_cfg items files is identical, because the items are measured in B-A instead of A-B order. > > > 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. But then you have to find and update all callsites (or at least the ones where we care about measurement). > > 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? More like this: QemuFwCfgCacheAdd(int Item, int Size, bool Measure); > 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); > } Well, not that easy. Allocating memory is not always possible in early firmware phases, which is the reason why the code works with the stack and chunkwise reads. We might offer an QemuFwCfgCacheGet() API though. When storing cached items in HOBs we can hand out a pointer to the data in the HOB, and callers access the complete fw_cfg item then without having to allocate memory. > > Also note that not all fw_cfg entries are (pseudo-)files. > I am not sure what you mean about (pseudo-)files. Well, even though fw_cfg uses names which look like file paths for entries it's not a real filesystem, it's just a naming convention, that's why named them pseudo files. Some older fw_cfg items don't use this file-naming scheme, they have a fixed number instead (see QemuFwCfgItem*). > 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) ? It all comes down to QemuFwCfgSelectItem + QemuFwCfgReadBytes. There are some convenience functions to read (for example) integers, they internally call QemuFwCfgReadBytes though. QemuFwCfgFindFile also simply calls QemuFwCfgSelectItem + QemuFwCfgReadBytes. So making QemuFwCfgSelectItem + QemuFwCfgReadBytes aware of the cache should be all you need. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116959): https://edk2.groups.io/g/devel/message/116959 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] -=-=-=-=-=-=-=-=-=-=-=-