Re: [edk2-devel] [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers

["Marvin Häuser" <mhaeuser@posteo.de>]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]


> On 30. May 2023, at 12:02, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> On Tue, 30 May 2023 at 11:53, Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>> wrote:
>> 
>> 
>> 
>> On 30. May 2023, at 11:48, Ard Biesheuvel <ardb@kernel.org> wrote:
>> 
>> On Tue, 30 May 2023 at 11:47, Ard Biesheuvel <ardb@kernel.org> wrote:
>> 
>> 
>> On Tue, 30 May 2023 at 11:42, Marvin Häuser <mhaeuser@posteo.de> wrote:
>> 
>> 
>> I took a *very brief* look at the entire series now. Is this just to apply 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.
>> 
>> 
>> Sorry, I didn't mean the series, I meant the choice to handle things in DxeIpl over DxeCore in particular.
>> 
>> Is there even a non-FOSS producer of the CpuArch protocol? To my understanding, all (common) Intel platforms use the one in UefiCpuPkg. ARM and friends feel a lot less proprietary to begin with, but I could be wrong. We were quite successful so far with just merging CpuArch into DxeCore and setting it up quite early, but of course not at an industry-wide scale. :)
> 
> What about the dependencies of CpuArch protocol? On ARM, this is the
> GIC driver (for the interrupt controller), which has its own platform
> specific dependencies.

Hmm, was that for the exception handler? I forgot that was in CpuDxe too, I specifically meant the memory permission related things, sorry!

> 
> So this is not tractable in general, and the only options we have (imo) are
> 
> - add memory permission attribute handling to DxeCore directly (via a
> library with arch specific implementations)

Yes, this.

> - add a way to dispatch the CpuDxe *and its dependencies* without the
> need to manipulate memory permissions

That would be awful and I'd prefer your current solution over this.

> 
> Clumping everything together into DxeCore does not appear to me as a
> sustainable approach for this.


[-- Attachment #2: Type: text/html, Size: 12207 bytes --]