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 A7C307803E7 for ; Wed, 20 Mar 2024 10:04:42 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=2I/qBQxWoC6VoHTBWUKsfNMk0hSNN/QfQk2BOlH48Xw=; 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=1710929081; v=1; b=ZjLcVyCRGiVrKU2D0QCYqctRFEDzhLiF4vgysqWxCMTSRNZ3BxVh8IFtCmjK7ayI/VHbbPEY Nla11Sgspq5bJk/dnh/ARrglTK0F5L3A+fZ7w2n4myEARXpz0VAHtlOlo9kAvol8fe97u2vkGFI uVjBvPWW0l2CnQf10J6P4Vg5b3MuLi9RZ7vWlJVlw4/OntrHDEx422yGYJQkkMO4X3LTeGwZLiD 1WicV1TJHZYIKC5dnfIlKZhyCrapApu0NIgake80Tu+aws97CPBbzhd8YNrZAbO98BE7bg4G3Km aIii8A0PQAE+eVCbFpapUS3OU3ECvqXTmq/insy5EqhjA== X-Received: by 127.0.0.2 with SMTP id zWHxYY7687511xMoo1CSapbu; Wed, 20 Mar 2024 03:04:41 -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.40147.1710929080662160647 for ; Wed, 20 Mar 2024 03:04:40 -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-64-f_07cW8vOzKxKXPEmiKEVQ-1; Wed, 20 Mar 2024 06:04:36 -0400 X-MC-Unique: f_07cW8vOzKxKXPEmiKEVQ-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 04595800265; Wed, 20 Mar 2024 10:04:36 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D3151492BD0; Wed, 20 Mar 2024 10:04:35 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8D6A51800D4F; Wed, 20 Mar 2024 11:04:30 +0100 (CET) Date: Wed, 20 Mar 2024 11:04:30 +0100 From: "Gerd Hoffmann" To: "Sun, CepingX" Cc: "devel@edk2.groups.io" , "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.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: Wed, 20 Mar 2024 03:04:40 -0700 Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: vvJVS2f8KA4uLFRqVOUANJGpx7686176AA= 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=ZjLcVyCR; 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 20, 2024 at 08:41:41AM +0000, Sun, CepingX wrote: > > On Thursday, March 14, 2024 5:31 PM Gerd Hoffmann wrote: > > Load, measure and cache all fw_cfg entries we care about early in the PEI phase > > (or SEC phase for pei-less builds), so we can > > (a) easily have a fixed order, and > > (b) store them all in HOBs? > > > > Which implies SEC/PEI must read all relevant fw_cfg entries, even in case they > > are used only later in the DXE phase. > > > > Advantage is we have a single cache which can be used in all firmware phases. > > When using global variables in DXE we still can end up reading entries multiple > > times, either because entries are needed by both PEI and DXE, or because > > multiple DXE modules need them (global variables are per module). > > > We have some concerns that in above solution the size of a single cache is large > ( because all fw_cfg data need to be read from qemu). 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. 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? > 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 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. Add a new interface for adding fw_cfg entries to the cache, with optional measurement. Populate the cache with all entries which need fw_cfg measurement. Additionally cache entries which are used frequently (QemuFwCfgItemSignature + QemuFwCfgItemInterfaceVersion + QemuFwCfgItemFileDir are candidates). Note that QemuFwCfgItemFileDir must be cached for security reasons (so the hypervisor can't present different versions of the file list) even though I don't think we need to measure it. > Pros: > Caller can decide how to get the fw_cfg data from QEMU (cache? Measurement?) Cache and measurement are not independent options. Measurement without caching doesn't make sense. > 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). Also note that not all fw_cfg entries are (pseudo-)files. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116932): https://edk2.groups.io/g/devel/message/116932 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] -=-=-=-=-=-=-=-=-=-=-=-