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.6172.1685440939230537813 for ; Tue, 30 May 2023 03:02:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gFWLGknp; 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 B51EA61CCF for ; Tue, 30 May 2023 10:02:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A276C433D2 for ; Tue, 30 May 2023 10:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685440938; bh=dtcFmi89zDXexXYEbdFxu6DEy50j1gXeRjb25B/SjO0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gFWLGknp58q18zmqCM+ZLEshn3xFkGx2X2wHFLtvDPbJNJMqINMhibFyBHMbAXTEz EQAkdswziB91lEesCnkMk4WFtiM3lyX79ratarSod2T0vq0t0dH40KaOz0mmgd6G+B Hl3QC0nHugYZj0AOSenE+g/q15tQmOqAnhO7xTY9+bqb4ugrku3yHwBTpK7BKhZJfO 61xwhY58EQYU3QwdEjrO7e08jXm/4Z/N3bBX/9cSFXDANuTVUtjLwjfyKK0aB7GOX8 jZpuPaSMZL1bG1Re6rJluDTwaOGvcZpbsJYUlwtE2TVwFBNpsFw9ixA8mvCnivPM7D BsiHLsqTcYiyw== Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2af2c7f2883so44242061fa.3 for ; Tue, 30 May 2023 03:02:18 -0700 (PDT) X-Gm-Message-State: AC+VfDxPeg2tzJERH/oFUAo6vjAkuqidNrdbzRe0iZjsZokW5J/o34wA 9lsy1stlSclDTdwVxa209E9fMWdJS8UqGIq0rLo= X-Google-Smtp-Source: ACHHUZ42iZ5Q+NZf2fjgGVPcKk/wNKU8WyBXz4UGhk1Ne7F69BvHC3fQfa3O78XMWQG9VFbew362jb9/66RLhIE+f7Q= X-Received: by 2002:a2e:a1d0:0:b0:2ad:94cd:3cb7 with SMTP id c16-20020a2ea1d0000000b002ad94cd3cb7mr563459ljm.51.1685440936213; Tue, 30 May 2023 03:02:16 -0700 (PDT) MIME-Version: 1.0 References: <3425.1685437617401609070@groups.io> <8AB1A1CF-9BEA-4F01-8615-A379BC827E64@posteo.de> In-Reply-To: <8AB1A1CF-9BEA-4F01-8615-A379BC827E64@posteo.de> From: "Ard Biesheuvel" Date: Tue, 30 May 2023 12:02:04 +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: devel@edk2.groups.io, mhaeuser@posteo.de Cc: Ray Ni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 30 May 2023 at 11:53, Marvin H=C3=A4user wrote= : > > > > On 30. May 2023, at 11:48, Ard Biesheuvel wrote: > > 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: > > > I took a *very brief* look at the entire series now. Is this just to appl= y 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 D= xeIpl over DxeCore in particular. > > Is there even a non-FOSS producer of the CpuArch protocol? To my understa= nding, all (common) Intel platforms use the one in UefiCpuPkg. ARM and frie= nds feel a lot less proprietary to begin with, but I could be wrong. We wer= e quite successful so far with just merging CpuArch into DxeCore and settin= g 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. 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) - add a way to dispatch the CpuDxe *and its dependencies* without the need to manipulate memory permissions Clumping everything together into DxeCore does not appear to me as a sustainable approach for this.