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.5659.1685438307909395040 for ; Tue, 30 May 2023 02:18:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=O+kfRq/0; 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 28DDA240103 for ; Tue, 30 May 2023 11:18:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1685438304; bh=1vo3ySskwp9/lDf/cWy04WkJ4BBeG1h44G5/SaUlCJY=; h=From:Message-Id:Mime-Version:Subject:Date:Cc:To:From; b=O+kfRq/0CyAPtfdbN3r3HP9Ru0o10LcFaoKJ3eZSrBEEdaURttV7a1WCl5Okebw0K kwXIn52p2ZIhBHpx4ZyxLML1lBf2fNjntDQpsu/jY08alJdQid0K+HIP8tIM56+n0f llhI1MO7viRff+RswTXKwr2Kic9nxFwU15+cbIN1kgtNU6Hagnu9Qal5p1jlpzhcGm A+y9OQ9bPg2sj3YAbEmL0Ue3GyUrk/LjxlJznBbe6g9aHVK9Wnmjlh+q1J0hgqlRrv plC94ZPQyfBiu34gocsv52gTx50+BKvH8/yZ0KED3l3swOZxT6RxNNkJUylWbQupOo vzRNhCxgcR0yQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QVmz26wTXz9rxF; Tue, 30 May 2023 11:18:22 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-Id: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers Date: Tue, 30 May 2023 09:18:12 +0000 In-Reply-To: <3425.1685437617401609070@groups.io> Cc: Ray Ni To: Ard Biesheuvel , edk2-devel-groups-io References: <3425.1685437617401609070@groups.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_65958021-A3EF-4739-9226-40A170E4FB6B" --Apple-Mail=_65958021-A3EF-4739-9226-40A170E4FB6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30. May 2023, at 11:06, Marvin H=C3=A4user = wrote: >=20 > Hi Ard, >=20 > Native PE toolchains *generally* also generate XIP images (/ALIGN =3D = /FILEALIGN, but with 32 Byte rather than 64 Byte alignment compared 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 perfectly safe for these, as they will have FileAlignment < = SectionAlignment (and by all chances, BaseTools is borked too). In my = opinion check for FileAlignment =3D=3D SectionAlignment. I can't vouch = for how likely FileAlignment has a sane value, the AUDK loader does not = read it at all and instead checks PointerToRawData =3D=3D = VirtualAddress, etc. >=20 > BaseTools generally has poor support for non-XIP vs XIP, probably due = to notorious 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]. There 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 former 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. >=20 > 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 does the dispatcher take this into account? Why is this = applied during PEI, how this this work with the notion of payloads? Sorry, I just realized this was a patch *series*! :( For the questions that are answered in commit messages or implicitly by = the code, please disregard, I'll read through them. Not sure the payload = situation is obvious, as it's not all that obvious to me how they work = in the first place (though I do know, you can both load a payload from = edk2 PEI and have edk2 DXE loaded as a payload from something else, so = this definitely is a concern in some way). >=20 > Thanks! >=20 > Best regards, > Marvin >=20 > [1] = https://github.com/tianocore/edk2/blob/0f9283429dd487deeeb264ee5670551d596= fc208/BaseTools/Conf/tools_def.template#L670-L672 >=20 > [2] = https://github.com/tianocore/edk2-platforms/blob/02fb8459d9c48a8ed4691e9c2= 2f2516c15073835/Silicon/Intel/CoffeelakeSiliconPkg/SiPkgBuildOption.dsc#L1= 29 >=20 > [3] = https://github.com/tianocore/edk2/blob/0f9283429dd487deeeb264ee5670551d596= fc208/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3881-L3897 --Apple-Mail=_65958021-A3EF-4739-9226-40A170E4FB6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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

Hi = Ard,

Native PE toolchains *generally* also generate XIP images = (/ALIGN =3D /FILEALIGN, but with 32 Byte rather than 64 Byte alignment = compared 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 perfectly safe for these, as they will = have FileAlignment < SectionAlignment (and by all chances, BaseTools = is borked too). In my opinion check for FileAlignment =3D=3D = SectionAlignment. I can't vouch for how likely FileAlignment has a sane = value, the 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 notorious = 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]. There 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 former 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 does the dispatcher take = this into account? Why is this applied during PEI, how this this work = with the notion of = payloads?

Sorry, I just = realized this was a patch *series*! :(
For the questions that = are answered in commit messages or implicitly by the code, please = disregard, I'll read through them. Not sure the payload situation is = obvious, as it's not all that obvious to me how they work in the first = place (though I do know, you can both load a payload from edk2 PEI and = have edk2 DXE loaded as a payload from something else, so this = definitely is a concern in some way).


= --Apple-Mail=_65958021-A3EF-4739-9226-40A170E4FB6B--