From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers To: Ard Biesheuvel ,devel@edk2.groups.io From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= X-Originating-Location: Kaiserslautern, Rheinland-Pfalz, DE (95.88.195.80) X-Originating-Platform: Mac Safari 16.5 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 30 May 2023 02:06:57 -0700 References: In-Reply-To: Message-ID: <3425.1685437617401609070@groups.io> Content-Type: multipart/alternative; boundary="2MgS0v8LoKYCQWQIsrUJ" --2MgS0v8LoKYCQWQIsrUJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ard, Native PE toolchains *generally* also generate XIP images (/ALIGN =3D /FILE= ALIGN, but with 32 Byte rather than 64 Byte alignment compared to GCC49+ / = CLANGDWARF) [1]. However, because they are underaligned by default (even fo= r RT images that run in an OS context and MM drivers... sigh...), platforms= manually override SectionAlignment, but not necessarily FileAlignment [2],= breaking XIP. I don't think what you are doing is perfectly safe for these= , as they will have FileAlignment < SectionAlignment (and by all chances, B= aseTools is borked too). In my opinion check for FileAlignment =3D=3D Secti= onAlignment. I can't vouch for how likely FileAlignment has a sane value, t= he AUDK loader does not read it at all and instead checks PointerToRawData = =3D=3D VirtualAddress, etc. BaseTools generally has poor support for non-XIP vs XIP, probably due to no= torious underalignment since the very beginning. For PEIM XIPs for example,= which must ship pre-relocated at least for Intel, GenFv just relocates the= image in-memory and then copies the changes back to the FFS file [3]. Ther= e is no concept of changing the image file size within the procedure and as= such, a non-XIP image cannot be converted to XIP on demand. This would be = useful for a distinction between pre-memory and post-memory PEIMs, the form= er of which must be XIP (thus aligned), while the latter can be loaded and = relocated in-RAM (thus can be underaligned w.r.t. FileAlignment), but alas. Are there any docs w.r.t. the use-case for this? Since when are DXE XIPs a = thing? The code above is opportunistic (i.e., failures are ignored), how do= es the dispatcher take this into account? Why is this applied during PEI, h= ow this this work with the notion of payloads? Thanks! Best regards, Marvin [1] https://github.com/tianocore/edk2/blob/0f9283429dd487deeeb264ee5670551d= 596fc208/BaseTools/Conf/tools_def.template#L670-L672 [2] https://github.com/tianocore/edk2-platforms/blob/02fb8459d9c48a8ed4691e= 9c22f2516c15073835/Silicon/Intel/CoffeelakeSiliconPkg/SiPkgBuildOption.dsc#= L129 [3] https://github.com/tianocore/edk2/blob/0f9283429dd487deeeb264ee5670551d= 596fc208/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3881-L3897 --2MgS0v8LoKYCQWQIsrUJ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ard,

Native PE toolchains *generally* also generate XIP image= s (/ALIGN =3D /FILEALIGN, but with 32 Byte rather than 64 Byte alignment co= mpared to GCC49+ / CLANGDWARF) [1]. However, because they are underaligned = by default (even for RT images that run in an OS context and MM drivers... = sigh...), platforms manually override SectionAlignment, but not necessarily= FileAlignment [2], breaking XIP. I don't think what you are doing is perfe= ctly safe for these, as they will have FileAlignment < SectionAlignment = (and by all chances, BaseTools is borked too). In my opinion check for File= Alignment =3D=3D SectionAlignment. I can't vouch for how likely FileAlignme= nt has a sane value, the AUDK loader does not read it at all and instead ch= ecks PointerToRawData =3D=3D VirtualAddress, etc.

BaseTools gene= rally has poor support for non-XIP vs XIP, probably due to notorious undera= lignment since the very beginning. For PEIM XIPs for example, which must sh= ip pre-relocated at least for Intel, GenFv just relocates the image in-memo= ry and then copies the changes back to the FFS file [3]. There is no concep= t of changing the image file size within the procedure and as such, a non-X= IP image cannot be converted to XIP on demand. This would be useful for a d= istinction between pre-memory and post-memory PEIMs, the former of which mu= st be XIP (thus aligned), while the latter can be loaded and relocated in-R= AM (thus can be underaligned w.r.t. FileAlignment), but alas.

Ar= e there any docs w.r.t. the use-case for this? Since when are DXE XIPs a th= ing? The code above is opportunistic (i.e., failures are ignored), how does= the dispatcher take this into account? Why is this applied during PEI, how= this this work with the notion of payloads?

Thanks!

= Best regards,
Marvin

[1] https://github.com/tianocore/edk2/blob/0f92= 83429dd487deeeb264ee5670551d596fc208/BaseTools/Conf/tools_def.template#L670= -L672

[2] https://github.com/tianocore/edk2-platforms/blob/02fb8459d9c48a8ed4691e9= c22f2516c15073835/Silicon/Intel/CoffeelakeSiliconPkg/SiPkgBuildOption.dsc#L= 129

[3] https://github.com/tianocore/edk2/blob/0f9283429d= d487deeeb264ee5670551d596fc208/BaseTools/Source/C/GenFv/GenFvInternalLib.c#= L3881-L3897 --2MgS0v8LoKYCQWQIsrUJ--