From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.6458.1685442326202656322 for ; Tue, 30 May 2023 03:25:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=F/WQgpm2; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7876124002A for ; Tue, 30 May 2023 12:25:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1685442322; bh=G1Li0/YF/hGp//7hIJNRScVsZ9RV8t9OC41wKZwuuh0=; h=From:Message-Id:Mime-Version:Subject:Date:Cc:To:From; b=F/WQgpm2lPAFMHsdcoh8be2OiBRSuop4eGQ6XNcPhEb2C6iLDzOtOt1b+w7gbkhYV K2t2oPs1h77flqz3g9Ey+ryLz2ZJlRVbBl5dyfjLKiTI6Zu+Fz1EVvsI3mqLtITZRj 0jQVDSEo+nnx0tc0fbsw/nuSW5rC/L2BHc7E3lYRHd0wqVlO5tB2UhneuPZBSl0Bl5 4NXpj1CFVzWaArD/eHu4H5d+ghTq3ubnBMyHwNPzvHraUU4qkeC/KnM0FYrdDQxois ggLhIWFrW/4cico1kFjG53OIbWjK16YkaIldBhN9qj6dNGqH5r+OY+J0T6GmxsbktE 2g/40iSJuElaw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QVpSK2QwRz6twg; Tue, 30 May 2023 12:25:21 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-Id: <00FE89CA-4AA8-422F-806D-F90711159272@posteo.de> 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 Date: Tue, 30 May 2023 10:25:10 +0000 In-Reply-To: Cc: edk2-devel-groups-io , Ray Ni To: Ard Biesheuvel References: <3425.1685437617401609070@groups.io> <8AB1A1CF-9BEA-4F01-8615-A379BC827E64@posteo.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_076F4ACF-3EE5-42DC-825A-04470F4A5BF4" --Apple-Mail=_076F4ACF-3EE5-42DC-825A-04470F4A5BF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30. May 2023, at 12:02, Ard Biesheuvel wrote: >=20 > On Tue, 30 May 2023 at 11:53, Marvin H=C3=A4user > wrote: >>=20 >>=20 >>=20 >> On 30. May 2023, at 11:48, Ard Biesheuvel wrote: >>=20 >> On Tue, 30 May 2023 at 11:47, Ard Biesheuvel wrote: >>=20 >>=20 >> On Tue, 30 May 2023 at 11:42, Marvin H=C3=A4user = wrote: >>=20 >>=20 >> I took a *very brief* look at the entire series now. Is this just to = apply permissions before CpuDxe is loaded >>=20 >>=20 >> Yes. >>=20 >>=20 >> Well, actually, the first part of the series gets rid of some >> pointless memory copies, which is an improvement in itself. >>=20 >>=20 >> Sorry, I didn't mean the series, I meant the choice to handle things = in DxeIpl over DxeCore in particular. >>=20 >> 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. :) >=20 > 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! >=20 > So this is not tractable in general, and the only options we have = (imo) are >=20 > - 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. >=20 > Clumping everything together into DxeCore does not appear to me as a > sustainable approach for this. --Apple-Mail=_076F4ACF-3EE5-42DC-825A-04470F4A5BF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 30. May = 2023, at 12:02, Ard Biesheuvel <ardb@kernel.org> wrote:

On Tue, 30 May 2023 at 11:53, Marvin = H=C3=A4user <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=C3=A4user <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.

= --Apple-Mail=_076F4ACF-3EE5-42DC-825A-04470F4A5BF4--