From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.5890.1685439529846522947 for ; Tue, 30 May 2023 02:38:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EE2+eFFW; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5A09E6231F for ; Tue, 30 May 2023 09:38:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3149C4339B for ; Tue, 30 May 2023 09:38:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685439528; bh=+yhvOgYMimJd8WsvJgiWxX/Wn6tiuTIiccclhhXfwoY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EE2+eFFW6K7j7FH1hWr93TZ3v1A+zEc/YrX7M5Zy9VC5UJ5a8w73tFjt8qjD+pG5p zfTIasgCaaQk9Wxp/Wh5jROfnpZPPkruVkGz13tKy6XIxFgdwL1meLFBg6lPvcFxYJ 5O86ZZpt8KKXlQbPshh77gNkC3f7ldzsp/6hWit9Xw2+eSHZ1OQYC9LJVwUnL6scS1 vubjAnF8mMgpwbjjwWQhNaJAJcNJGXZTIeH6Jh4htG3rKAG23su4CJxbOoBEzM7w8C vstrCC5ZdtMf11nmtmXk9Dcso1XlD4hrU2RJ1lZZDIe/aj9ePpObIco76GHfg4A8+u gYeUIszNLRi8w== Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2af177f12a5so43732401fa.2 for ; Tue, 30 May 2023 02:38:48 -0700 (PDT) X-Gm-Message-State: AC+VfDy4bOZOVvtyTehAOsMoDGroTsVL5+hXDcWDPrHL0zvkjYR6i25N meHT5J1/lUL58pLpOttwEkw5Qu24XDti6QgRwmQ= X-Google-Smtp-Source: ACHHUZ4Y8kpb3z0ZnH8k83u8JdKdeGXUYn3FfvCf/meAD5vBZyV0N3/srBSuo/4gg6CdwGuouIzgNtMQCz3ghaun/iQ= X-Received: by 2002:a2e:8283:0:b0:2ac:598e:e946 with SMTP id y3-20020a2e8283000000b002ac598ee946mr517443ljg.3.1685439526718; Tue, 30 May 2023 02:38:46 -0700 (PDT) MIME-Version: 1.0 References: <3425.1685437617401609070@groups.io> In-Reply-To: <3425.1685437617401609070@groups.io> From: "Ard Biesheuvel" Date: Tue, 30 May 2023 11:38:35 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2023 at 11:07, Marvin H=C3=A4user wrote= : > > Hi Ard, > > Native PE toolchains *generally* also generate XIP images (/ALIGN =3D /FI= LEALIGN, 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...), platfor= ms manually override SectionAlignment, but not necessarily FileAlignment [2= ], breaking XIP. I don't think what you are doing is perfectly safe for the= se, as they will have FileAlignment < SectionAlignment (and by all chances,= BaseTools is borked too). In my opinion check for FileAlignment =3D=3D Sec= tionAlignment. I can't vouch for how likely FileAlignment has a sane value,= the AUDK loader does not read it at all and instead checks PointerToRawDat= a =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 exampl= e, which must ship pre-relocated at least for Intel, GenFv just relocates t= he image in-memory and then copies the changes back to the FFS file [3]. Th= ere 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 b= e useful for a distinction between pre-memory and post-memory PEIMs, the fo= rmer of which must be XIP (thus aligned), while the latter can be loaded an= d relocated in-RAM (thus can be underaligned w.r.t. FileAlignment), but ala= s. > 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. 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.