From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=REkAOpy8; spf=pass (domain: linaro.org, ip: 209.85.166.172, mailfrom: ard.biesheuvel@linaro.org) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) by groups.io with SMTP; Fri, 19 Apr 2019 11:11:40 -0700 Received: by mail-it1-f172.google.com with SMTP id 139so9378504ita.4 for ; Fri, 19 Apr 2019 11:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xwYvnJfMGCiiABGmxhJkELrogAG8t6HeUhLgDXBaBWA=; b=REkAOpy8/DedAjxEEQHhr5Le18TA9+EPTaA2RS6FcleE7GhyEaT71IzAREaPT24cF4 7UerfxWhXzDBrABu12BiJkdA7UElYWmlZrxQTgPtpejlg1PgceCZMWQGjNZbtVKHnIg3 +2fvpn4RdD9ndrsZx4AU7N2tDNNzPE+Zd3drzbrbyLkjq/L4B+UJ9zUQlfye26CMZJra 1XsDpmj6/irr7itcSzCZl5ElWT2DR3zm+8cSNdmgdZQh81tbb+mdhOxX7VjRYh0+Q7rp SXC6YBZuqGvEz85suL0jPTGsa91Vae4frmhEdf1cOo9lM7ceERQcrA2sfLbg6lddI+2F ePRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xwYvnJfMGCiiABGmxhJkELrogAG8t6HeUhLgDXBaBWA=; b=AxyPisXSVHv//x453yAMGoRKaQlt+dIcIvur1wRQDfXkSVeDj1vx0DYGIXGFFhFCiH BgImnQtRmDj3tQ85VrywVzLy5KTPI6TIFq9rEP6qDz8nVlTBGIZWJetsHsNRDuPMvQgX EdjjUIkrm8kpVNqtZVYykOZNqtywQEmd4Dt1F4IpTb3dk3TXvHdS1NeVaRbj+5EN6Ihf uNT87mzjRbYS+KBWSFqWn2NDcgb8anSyutvdyBmX4jKqlVBgNGvwCW3sjDF0U4zRBqA8 uBVoN2jFprLnsh+T+6EzcXaRWtcBOpeRChFB5+18MQMZrILvWa9KzEz3Ej9duN0fS3Ak dwQQ== X-Gm-Message-State: APjAAAUBZh5YAvZ8LCPdzzsFcSYNu8d45FkHA9dVyl4PJicGxJTlaIu9 WtftzNscbTu7FakRR7XCS91oPLA0brEfDFCPmEK1+Q== X-Google-Smtp-Source: APXvYqx5W3vPgH6IFlLpkJKBWiz51ERysfnRmXHQ/80R1Dv0z7+8mc7DogxXTsDH3iHTDb399m+Vro2Y2ImNq2E6/p0= X-Received: by 2002:a24:1312:: with SMTP id 18mr3539018itz.121.1555697499216; Fri, 19 Apr 2019 11:11:39 -0700 (PDT) MIME-Version: 1.0 References: <20190419141319.11084-1-ard.biesheuvel@linaro.org> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 19 Apr 2019 20:11:26 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH resend] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory To: "Kinney, Michael D" Cc: "devel@edk2.groups.io" , "ming.huang@linaro.org" , "Wu, Hao A" , "Wang, Jian J" Content-Type: text/plain; charset="UTF-8" On Fri, 19 Apr 2019 at 20:08, Kinney, Michael D wrote: > > Ard, > > Where is the use of ESRT at runtime? > DxeCapsuleLibFmp is invoked at runtime by the UpdateCapsule() and QueryCapsuleCapabilities() code. The Canonical FWTS crashes on this runtime service on some ARM and x86 systems due to this issue, hence the patch. > The SetVa conversion of the ESRT table may be an old artifact > that we should consider removing. > No, it is definitely live code. > > > -----Original Message----- > > From: devel@edk2.groups.io > > [mailto:devel@edk2.groups.io] On Behalf Of Ard > > Biesheuvel > > Sent: Friday, April 19, 2019 10:54 AM > > To: edk2-devel-groups-io ; > > Kinney, Michael D > > Cc: ming.huang@linaro.org; Wu, Hao A > > ; Wang, Jian J > > > > Subject: Re: [edk2-devel] [PATCH resend] > > MdeModulePkg/EsrtDxe: allocate ESRT table from > > RtServicesData memory > > > > On Fri, 19 Apr 2019 at 19:42, Ard Biesheuvel > > wrote: > > > > > > On Fri, 19 Apr 2019 at 19:36, Michael D Kinney > > > wrote: > > > > > > > > Hi Ard, > > > > > > > > The UEFI Specification Section 23.3 says: > > > > > > > > "The ESRT shall be stored in memory of type > > EfiBootServicesData." > > > > > > > > If an RT driver needs ESRT info after > > ExitBootServices(), then the > > > > RT driver should collect that information before > > ExitBootServices(). > > > > > > > > > > But that means that before EBS(), we will have to > > make a copy of the > > > ESRT into runtime services data, and we will end up > > using twice as > > > much memory - one copy in boot services data for the > > OS, and one copy > > > in runtime services data for the firmware itself. I > > understand the > > > reasoning behind preferring boot over runtime, so > > that the OS is not > > > burdened with it if it does not care. But it this > > case, the RT > > > services data will be allocated regardless, and so we > > end up using > > > less memory if we expose that same copy to the OS. > > > > > > > Actually, DxeCapsuleLibVirtualAddressChangeEvent() in > > DxeCapsuleLibFmp > > updates the ESRT pointer to virtual, so this code is > > clearly based on > > the assumption that the ESRT resides in memory that is > > covered by a > > runtime VA mapping. > > > > Could we instead clarify the UEFI spec to something > > like > > > > "The ESRT shall be stored in memory of type > > EfiBootServicesData unless > > the runtime services implementations themselves need to > > access it at > > OS runtime, in which case it may be stored in > > EfiRuntimeServicesData." > > > > >