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.web11.5990.1685440050500068123 for ; Tue, 30 May 2023 02:47:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Y6aZV/9r; 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 0042F62C8D for ; Tue, 30 May 2023 09:47:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65172C4339B for ; Tue, 30 May 2023 09:47:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685440049; bh=stP+le4KdsD16dZhjX0kkI+vEkgFbfeCXzYjiuB6UoE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Y6aZV/9r3ktvMiitxRh1gc2NUee0YZ2maHQihfwg+5lc768D+8iOuOitn5cpGT5qo Pgfy6AUG51hkKOHMgl+98JG7HtyDakjlPZllRJbJFBPwEQ/wm6j30LjbsRZU7aeRAl j4UTekuna8SfuNJ7c7lvlEj7VmBDVQ8QMz+lEuec68gdVlthPowsITYtLS8nsZBRdQ RDxfO4HtKkJNBRvc9GGSQSv4HIiX/9gSB6X+6SFMQBM9F/kIRU2FrOxOmh/8ENbJfQ qcacMC5CBGMqu7sGNgFP3sEKxoX0GaUIEHwoArdc8RiSP6eWdrwLoFpZe2/I5iN7Xy pDw4GaC2HsOww== Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-4f4d80bac38so4560321e87.2 for ; Tue, 30 May 2023 02:47:29 -0700 (PDT) X-Gm-Message-State: AC+VfDwQIprws7GvAi9SY+L8BOEld/U0EC04Qh/kbW7kU0Fw43geXwM1 4gC2ibYsgUKqKwH1N1yTnwYhce8FF5Bzr8/Bq/0= X-Google-Smtp-Source: ACHHUZ4QrsVmiBxW7ejzVFsMejgSlkuoYUeqNazmiTkx9J+1A1n5w851vzDLAJLtF3qbD/nvCIGlR7LQPsDbnEGMShg= X-Received: by 2002:a2e:86cf:0:b0:2a8:c75c:96cb with SMTP id n15-20020a2e86cf000000b002a8c75c96cbmr458320ljj.1.1685440047406; Tue, 30 May 2023 02:47:27 -0700 (PDT) MIME-Version: 1.0 References: <3425.1685437617401609070@groups.io> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 30 May 2023 11:47:16 +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:42, Marvin H=C3=A4user wrote= : > > > > On 30. May 2023, at 11:38, Ard Biesheuvel wrote: > > > > On Tue, 30 May 2023 at 11:07, Marvin H=C3=A4user w= rote: > >> > >> Hi Ard, > >> > >> Native PE toolchains *generally* also generate XIP images (/ALIGN =3D = /FILEALIGN, but with 32 Byte rather than 64 Byte alignment compared to GCC4= 9+ / CLANGDWARF) [1]. However, because they are underaligned by default (ev= en for RT images that run in an OS context and MM drivers... sigh...), plat= forms 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 chanc= es, BaseTools is borked too). In my opinion check for FileAlignment =3D=3D = SectionAlignment. I can't vouch for how likely FileAlignment has a sane val= ue, the AUDK loader does not read it at all and instead checks PointerToRaw= Data =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 exa= mple, which must ship pre-relocated at least for Intel, GenFv just relocate= s 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 a= nd as such, a non-XIP image cannot be converted to XIP on demand. This woul= d 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. > >> > > > > 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. > > I took a *very brief* look at the entire series now. Is this just to appl= y permissions before CpuDxe is loaded Yes. > or is there another reason this is not handled by DxeCore itself?