<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Ray,</div><div dir="ltr"><br></div><div dir="ltr">This is handled by GenFw. For ELF-based toolchains, this is done as part of the conversion [1]. For others, a “GenFw post-processing” step takes care of 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 guess I’ll recommend against my former suggestion to check FileAlign == SectAlign and to instead just check the actual section info [3].</div><div dir="ltr"><br></div><div dir="ltr">While this looks safe for now, GenFv would be a much more logical place for XIP conversion. This way, everything is XIP and when page-aligning all images, the flash storage quickly runs out of space (at least without compression). That GenFv has no logic to grow image files also kept me from implementing a new 2-section approach to XIP where metadata and sections are stored separately, such that the header metadata doesn’t need to be section-aligned.</div><div dir="ltr"><br></div><div dir="ltr">(Completely irrelevant to this discussion, but while we’re at it, the flat storage hierarchy also makes memory 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 yielding padding. If all images were stored consecutively and the FFS metadata rather pointed to their locations, a lot if padding could be avoided. Though this would need some analysis as to how much you actually save, as adding 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 explicitly provided and the rest is just adding up the size of the previous one, but that might screw over some existing parsers.)</div><div dir="ltr"><br></div><div dir="ltr">Best regards,</div><div dir="ltr">Marvin</div><div dir="ltr"><br></div><div dir="ltr">[1] <a href="https://github.com/tianocore/edk2/blob/d8e5d35ede7158ccbb9abf600e65b9aa6e043f74/BaseTools/Source/C/GenFw/Elf64Convert.c#L1297">https://github.com/tianocore/edk2/blob/d8e5d35ede7158ccbb9abf600e65b9aa6e043f74/BaseTools/Source/C/GenFw/Elf64Convert.c#L1297</a></div><div dir="ltr"><br></div><div dir="ltr">[2]<a href="https://github.com/tianocore/edk2/blob/d8e5d35ede7158ccbb9abf600e65b9aa6e043f74/BaseTools/Source/C/GenFw/GenFw.c#L2088"> https://github.com/tianocore/edk2/blob/d8e5d35ede7158ccbb9abf600e65b9aa6e043f74/BaseTools/Source/C/GenFw/GenFw.c#L2088</a></div><div dir="ltr"><br></div><div dir="ltr">[3] <a href="https://github.com/acidanthera/audk/blob/d9bb10ae3b73134eb434b309cb0db3fa4282a838/MdePkg/Library/BasePeCoffLib2/PeCoffLoad.c#L134">https://github.com/acidanthera/audk/blob/d9bb10ae3b73134eb434b309cb0db3fa4282a838/MdePkg/Library/BasePeCoffLib2/PeCoffLoad.c#L134</a></div><div dir="ltr"><br><blockquote type="cite">On 31. May 2023, at 09:14, Ni, Ray <ray.ni@intel.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@font-face { font-family: Helvetica; } @font-face { font-family: SimSun; } @font-face { font-family: "Cambria Math"; } @font-face { font-family: DengXian; } @font-face { font-family: Calibri; } @font-face { font-family: "@DengXian"; } @font-face { font-family: "@SimSun"; } p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif; } a:link, span.MsoHyperlink { color: blue; text-decoration: underline; } span.EmailStyle20 { font-family: Calibri, sans-serif; color: windowtext; } .MsoChpDefault { font-size: 10pt; } @page WordSection1 { size: 8.5in 11in; margin: 1in; } div.WordSection1 { page: WordSection1; }</style> <div class="WordSection1"> <p class="MsoNormal">When a PE has a global large variable, there could be a .bss section whose actual size is 0 or very small but the eventual size when loading to memory will be larger.<o:p></o:p></p> <p class="MsoNormal">Can XIP work with this section? <a id="OWAAMC7CE2046DF8546419A86AC3488F742AA" href="mailto:zhiguang.liu@intel.com"> <span style="font-family:"Calibri",sans-serif;text-decoration:none">@Liu, Zhiguang</span></a> brought this question when discussing with me offline<span style="font-family:"Segoe UI Emoji",sans-serif">😊</span><o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Thanks,<br> Ray<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class="MsoNormal"><b>From:</b> devel@edk2.groups.io <devel@edk2.groups.io> <b> On Behalf Of </b>Marvin Häuser<br> <b>Sent:</b> Tuesday, May 30, 2023 6:25 PM<br> <b>To:</b> Ard Biesheuvel <ardb@kernel.org><br> <b>Cc:</b> edk2-devel-groups-io <devel@edk2.groups.io>; Ni, Ray <ray.ni@intel.com><br> <b>Subject:</b> Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers<o:p></o:p></p> </div> </div> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal">On 30. May 2023, at 12:02, Ard Biesheuvel <<a href="mailto:ardb@kernel.org">ardb@kernel.org</a>> wrote:<o:p></o:p></p> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On Tue, 30 May 2023 at 11:53, Marvin Häuser <</span><a href="mailto:mhaeuser@posteo.de"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">mhaeuser@posteo.de</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">> wrote:<br style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px;word-spacing:0px"> <br> </span><o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br> <br> <br> On 30. May 2023, at 11:48, Ard Biesheuvel <<a href="mailto:ardb@kernel.org">ardb@kernel.org</a>> wrote:<br> <br> On Tue, 30 May 2023 at 11:47, Ard Biesheuvel <<a href="mailto:ardb@kernel.org">ardb@kernel.org</a>> wrote:<br> <br> <br> On Tue, 30 May 2023 at 11:42, Marvin Häuser <<a href="mailto:mhaeuser@posteo.de">mhaeuser@posteo.de</a>> wrote:<br> <br> <br> I took a *very brief* look at the entire series now. Is this just to apply permissions before CpuDxe is loaded<br> <br> <br> Yes.<br> <br> <br> Well, actually, the first part of the series gets rid of some<br> pointless memory copies, which is an improvement in itself.<br> <br> <br> Sorry, I didn't mean the series, I meant the choice to handle things in DxeIpl over DxeCore in particular.<br> <br> Is there even a non-FOSS producer of the CpuArch protocol? To my understanding, all (common) Intel platforms use the one in UefiCpuPkg. ARM and friends 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. :)<o:p></o:p></span></p> </blockquote> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br> What about the dependencies of CpuArch protocol? On ARM, this is the<br> GIC driver (for the interrupt controller), which has its own platform<br> specific dependencies.</span><o:p></o:p></p> </div> </blockquote> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Hmm, was that for the exception handler? I forgot that was in CpuDxe too, I specifically meant the memory permission related things, sorry!<o:p></o:p></p> </div> <p class="MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br> So this is not tractable in general, and the only options we have (imo) are<br> <br> - add memory permission attribute handling to DxeCore directly (via a<br> library with arch specific implementations)</span><o:p></o:p></p> </div> </blockquote> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">Yes, this.<o:p></o:p></p> </div> <p class="MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">- add a way to dispatch the CpuDxe *and its dependencies* without the<br> need to manipulate memory permissions</span><o:p></o:p></p> </div> </blockquote> <div> <p class="MsoNormal"><o:p> </o:p></p> </div> <div> <p class="MsoNormal">That would be awful and I'd prefer your current solution over this.<o:p></o:p></p> </div> <p class="MsoNormal"><br> <br> <o:p></o:p></p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br> Clumping everything together into DxeCore does not appear to me as a<br> sustainable approach for this.</span><o:p></o:p></p> </div> </blockquote> </div> <p class="MsoNormal"><o:p> </o:p></p> <div> <p class="MsoNormal"></o:p></span></p> </div> </div> </div></blockquote></body></html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links:<p> You receive all messages sent to this group. <p> <a target="_blank" href="https://edk2.groups.io/g/devel/message/105486">View/Reply Online (#105486)</a> | | <a target="_blank" href="https://groups.io/mt/99197142/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <br> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com]<br> <div width="1" style="color:white;clear:both">_._,_._,_</div>