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.web10.5921.1685439716201135964 for ; Tue, 30 May 2023 02:41:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=F7FD7KRh; 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 44B3E240104 for ; Tue, 30 May 2023 11:41:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1685439714; bh=ySNa9luaI1B4GyEvWbkOqciZXiqMzApPfdWcljTGVf4=; h=Mime-Version:Subject:From:Date:Cc:Content-Transfer-Encoding: Message-Id:To:From; b=F7FD7KRhiRLMBFqrjZDdOZU2OEVD55ZjSM9O6vNJ2tHvKQMGx6HMS41tI8AbcFz+p 3owMFiz5dpTzrbkpUOevGEotSdeHBeve7qyS/xb1b4bctGcqbIQzYz5Exzqdv9ucgq S+9cfoByd19jCmIRdX56R6wA0FxwnaV69+nhb4ICeOMyz7hDUFvOlq7wLcV4Q/0Vll +fjqFFVnaNgtB/UmtvRTAL2HVuzgL2aJnTpEk72N9QPeesngOdtp19f3RjSKRAaWho 2Zeup0ZZqaGGU6+DqcrDrQcORf6Kg+VjyjfraaYcNRIKo+KcZBs6F9hc9i7wBcJvGB 4cM0sc3M4KKpg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QVnV92gRmz9rxV; Tue, 30 May 2023 11:41:53 +0200 (CEST) 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 From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Date: Tue, 30 May 2023 09:41:42 +0000 Cc: devel@edk2.groups.io Message-Id: References: <3425.1685437617401609070@groups.io> To: Ard Biesheuvel Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 30. May 2023, at 11:38, Ard Biesheuvel wrote: >=20 > On Tue, 30 May 2023 at 11:07, 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 >=20 > If XIP for PE images with 4k section alignment is an issue, we could > always explore loading them into a separate allocation from PEI, just > like we do with DXE core itself. >=20 > This would actually simplify the loader code quite a lot, as we'd be > able to use the PEI core image loader directly. However, it means we'd > have to pass this information (array of tuples > describing which images were already loaded by DxeIpl) via a HOB or > some other method. I took a *very brief* look at the entire series now. Is this just to = apply permissions before CpuDxe is loaded or is there another reason = this is not handled by DxeCore itself?=