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.6005.1685440120420998286 for ; Tue, 30 May 2023 02:48:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tfiGXtA5; 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 EABC161DCD for ; Tue, 30 May 2023 09:48:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F041C433EF for ; Tue, 30 May 2023 09:48:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685440119; bh=/JCPrBfD33nYPFirOLhkoBCkEdke44zNR5kXMym9ezY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tfiGXtA50ss6W29qqA8Sr4twKBtwAd561vVNwfVbnwsRHhYygDUltFwJwPA1H1W2I Gpg3f4vfEKO/44zh032Ec8WCTHfjv/TuHxgFGrAglpNg0LdZnFCRnZv4dHmcKoO9rK 2PzfLg9orfBPu0Vq9LaHwLVQCrSUEl0xaoY6xZYwRUrki0QgCZtYs8ElgMVQsMmwGJ WVpBOgxrtEh+lQ0ov4HDeQ0E1YRr+ALzSVHFZ54YS3+JvXsVSNYBibCxf95+DqAMaj Z1z50dFn7xE/M5qQTS6QR+fg/ms4GyrLtTSI4FHl8JUQanP52oUecfnz9LrOoFZSL9 hH2Sepu2ZwjnA== Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2af2db78b38so45352821fa.3 for ; Tue, 30 May 2023 02:48:39 -0700 (PDT) X-Gm-Message-State: AC+VfDz/lJkJdNM70DgbbTdrHFOvQzTdOfI8SRECbeWHZNrWim2hy58K S06kfe7IsYQYKfqxbKaTZILrEuEY4DK7GQNMq3M= X-Google-Smtp-Source: ACHHUZ6Iab4JtzJ+qr/vRi1bXJ8irLrieBrpvJr5klp3iLhgyh7DuSvpuB8IlNFDYjlc7ia5u4jYHzVIjnW7qb9mmvk= X-Received: by 2002:a2e:740e:0:b0:2a7:6f82:4a87 with SMTP id p14-20020a2e740e000000b002a76f824a87mr437914ljc.35.1685440117365; Tue, 30 May 2023 02:48:37 -0700 (PDT) MIME-Version: 1.0 References: <3425.1685437617401609070@groups.io> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 30 May 2023 11:48:25 +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:47, Ard Biesheuvel wrote: > > On Tue, 30 May 2023 at 11:42, Marvin H=C3=A4user wro= te: > > > > > > > On 30. May 2023, at 11:38, Ard Biesheuvel wrote: > > > > > > 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 /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 FileAlign= ment [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 c= hances, 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 PointerT= oRawData =3D=3D VirtualAddress, etc. > > >> > > >> BaseTools generally has poor support for non-XIP vs XIP, probably du= e to notorious underalignment since the very beginning. For PEIM XIPs for e= xample, which must ship pre-relocated at least for Intel, GenFv just reloca= tes 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 wo= uld be useful for a distinction between pre-memory and post-memory PEIMs, t= he former of which must be XIP (thus aligned), while the latter can be load= ed and relocated in-RAM (thus can be underaligned w.r.t. FileAlignment), bu= t 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 ap= ply permissions before CpuDxe is loaded > > Yes. > Well, actually, the first part of the series gets rid of some pointless memory copies, which is an improvement in itself.