From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web11.8861.1685520359082865521 for ; Wed, 31 May 2023 01:05:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=qAntU17H; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5A390240104 for ; Wed, 31 May 2023 10:05:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1685520357; bh=KD0digro/JzUqWkyRUsjqi9RCOik7IZGK7TgLcLcSAE=; h=Content-Transfer-Encoding:From:Mime-Version:Subject:Date: Message-Id:Cc:To:From; b=qAntU17Hv3I+y9hU0+GYGvF2oKDbujsvBw5tachEfl3R0vlwv9F2YqVfN4ZvE9yd0 ddMmqissAWehfBNyAljb7X6i/p43bp2qswa14bSmhrRY0yY2hZ9ej1Cl228J67dPzb RckSsYd6auiRTfbTpsh12Tj/Kz6Y7kAKYtCFaqLtZryQ5c+DZJp9ztX4OaebujO4mU f7Nl0/7fjtfwHMzafxivA2pznyVaAER6RzI7XZ6ARFFi/Qnwgsn6gzDFFb9HVwxGIA cNe9wAoUgq94/qt+K/ELqUD32t3VMC4aWVMgXp2Oxrx7uvGULlU8bHYbm+eR8DylJZ 06QCAY4KRHC0w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QWMJz74Rkz6ty7; Wed, 31 May 2023 10:05:55 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers Date: Wed, 31 May 2023 08:05:55 +0000 Message-Id: <325F4E7D-7A99-4465-A7C9-AD6584CB58FC@posteo.de> References: Cc: devel@edk2.groups.io, Ard Biesheuvel , "Liu, Zhiguang" In-Reply-To: To: "Ni, Ray" Content-Type: multipart/alternative; boundary=Apple-Mail-06E4D462-22C2-4394-9108-094DD87DB6F3 Content-Transfer-Encoding: 7bit --Apple-Mail-06E4D462-22C2-4394-9108-094DD87DB6F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ray,

This is handled b= y GenFw. For ELF-based toolchains, this is done as part of the conversion [= 1]. For others, a =E2=80=9CGenFw post-processing=E2=80=9D step takes care o= f it [2]. Though you are right, this is not obvious and external tools may = forget this step (but still produce valid XIP-alike PEs). Consequently, I g= uess I=E2=80=99ll recommend against my former suggestion to check FileAlign= =3D=3D SectAlign and to instead just check the actual section info [3].

While this looks safe for no= w, GenFv would be a much more logical place for XIP conversion. This way, e= verything is XIP and when page-aligning all images, the flash storage quick= ly runs out of space (at least without compression). That GenFv has no logi= c to grow image files also kept me from implementing a new 2-section approa= ch to XIP where metadata and sections are stored separately, such that the = header metadata doesn=E2=80=99t need to be section-aligned.

(Completely irrelevant to this discussi= on, but while we=E2=80=99re at it, the flat storage hierarchy also makes me= mory protection for XIP a pain, as there will be FFS metadata inbetween 4K-= aligned (or maybe even more in the future?) images, thus virtually always y= ielding padding. If all images were stored consecutively and the FFS metada= ta rather pointed to their locations, a lot if padding could be avoided. Th= ough this would need some analysis as to how much you actually save, as add= ing an offset variable will obviously grow the FFS overhead. It would also = be nice to somehow encode the offset implicitly, where the first one is exp= licitly provided and the rest is just adding up the size of the previous on= e, but that might screw over some existing parsers.)
=
Best regards,
Marvin
=


[2] https://github.= com/tianocore/edk2/blob/d8e5d35ede7158ccbb9abf600e65b9aa6e043f74/BaseTools/= Source/C/GenFw/GenFw.c#L2088

<= div dir=3D"ltr">
On 31. May 2023, at 09:14, Ni= , Ray <ray.ni@intel.com> wrote:

=EF=BB=BF

When a PE has a global large variable, there could b= e a .bss section whose actual size is 0 or very small but the eventual size= when loading to memory will be larger.

Can XIP work with this section? @Liu, Zhiguang brought this question when discussing with m= e offline= =F0=9F=98=8A

 

Thanks,
Ray

 

From: devel@edk2.groups.io <devel@edk2.gro= ups.io> On Behalf Of Marvin H=C3=A4user
Sent: Tuesday, May 30, 2023 6:25 PM
To: Ard Biesheuvel <ardb@kernel.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Ni, Ray <r= ay.ni@intel.com>
Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Rel= ocate and remap XIP capable DXE drivers

 

 

On 30. May 2023, at 12:02, Ard Biesheuvel <ardb@kernel.org> wrote:

 

On Tue, 30 May 2023 at 11:53, Marvin H=C3=A4user &= lt;mhaeuser@posteo.de= > wrote:




On 30. May 2023, at 11:48, Ard Biesheuvel <ardb@kernel.org> wrote:

On Tue, 30 May 2023 at 11:47, Ard Biesheuvel <ardb@kernel.org> wrote:


On Tue, 30 May 2023 at 11:42, Marvin H=C3=A4user <mhaeuser@posteo.de> wrote:


I took a *very brief* look at the entire series now. Is this just to apply = permissions before CpuDxe is loaded


Yes.


Well, actually, the first part of the series gets rid of some
pointless memory copies, which is an improvement in itself.


Sorry, I didn't mean the series, I meant the choice to handle things in Dxe= Ipl over DxeCore in particular.

Is there even a non-FOSS producer of the CpuArch protocol? To my understand= ing, all (common) Intel platforms use the one in UefiCpuPkg. ARM and friend= s feel a lot less proprietary to begin with, but I could be wrong. We were = quite successful so far with just merging CpuArch into DxeCore and setting it up quite early, but of course = not at an industry-wide scale. :)


What about the dependencies of CpuArch protocol? On ARM, this is the
GIC driver (for the interrupt controller), which has its own platform
specific dependencies.

 

Hmm, was that for the exception handler? I forgot th= at was in CpuDxe too, I specifically meant the memory permission related th= ings, sorry!




So this is not tractable in general, and the only options we have (imo) are=

- add memory permission attribute handling to DxeCore directly (via a
library with arch specific implementations)

 

Yes, this.



- add a way to dispatch the CpuDxe *and its depend= encies* without the
need to manipulate memory permissions

 

That would be awful and I'd prefer your current solu= tion over this.




Clumping everything together into DxeCore does not appear to me as a
sustainable approach for this.

 

--Apple-Mail-06E4D462-22C2-4394-9108-094DD87DB6F3--