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.web10.241.1684857100847202461 for ; Tue, 23 May 2023 08:51:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qYiKj+OL; 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 4C390633F7 for ; Tue, 23 May 2023 15:51:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5859C4339B for ; Tue, 23 May 2023 15:51:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684857099; bh=pVPvJ8IAdhGQ2lEl5k0zuREucvKddfRvt/DAm4vbmvY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qYiKj+OLTjYHjm+MDkMV6Q7eyedEZUA5OcNNxuhYKYYG0sKIJ4YqJ5Zs28CqxumvE Pk2zSoPcMMLP7UckhhYmypO53HdCwg7KhEX6hDcEwrHp0oPm62xdX5bzSitZ9sVMOT agKvbf4uJAh9yELiagae6bwJIvOn/8olh5OY1Sc8lKQ+0Otx/yvlRknVuuw0Wzmd9i MkRbJCXwKCQbzHV85vR4tx0IZUScv+XHuMOh8IH9aLSUjEwKDo9Y+iu7wTTGViF30i AS7O40tSfzs9UwXQqsHmY+DrILPgWL1F+S2ueVkhQeniomW2/iZfHXfZmmD0JYrkrN PU59Eqq/Ub9pQ== Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-4f4b256a0c9so2534604e87.2 for ; Tue, 23 May 2023 08:51:39 -0700 (PDT) X-Gm-Message-State: AC+VfDxFp/RkCXg0tx/jAb7koqAHHSvHiLNEtUAgNpx+CT5cvYQtgX0c fLQetxiVxZBXeCjuG/EsXNOPp07r9A+iilE3tVI= X-Google-Smtp-Source: ACHHUZ7xcc/eYKxETfaN8/Bn4syxF0T1Xllo7gV32R89LTSDpPcTAAiJUUPHL1fsX+Ke2C2lyvBrtrZX4fepZHfTdn0= X-Received: by 2002:a2e:a3c5:0:b0:2ae:e214:482f with SMTP id w5-20020a2ea3c5000000b002aee214482fmr4586434lje.52.1684857097647; Tue, 23 May 2023 08:51:37 -0700 (PDT) MIME-Version: 1.0 References: <1718e8ad-6ba3-5da8-85c5-76e48c42110d@redhat.com> <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 23 May 2023 17:51:25 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] managing memory attributes in PEI To: devel@edk2.groups.io, michael.d.kinney@intel.com Cc: "lersek@redhat.com" , "Ni, Ray" , "Yao, Jiewen" , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny Content-Type: text/plain; charset="UTF-8" On Tue, 23 May 2023 at 17:15, Michael D Kinney wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Tuesday, May 23, 2023 7:59 AM > > To: Kinney, Michael D > > Cc: devel@edk2.groups.io; lersek@redhat.com; Ni, Ray ; > > Yao, Jiewen ; Gerd Hoffmann > > ; Taylor Beebe ; Oliver Smith- > > Denny > > Subject: Re: [edk2-devel] managing memory attributes in PEI > > > > On Tue, 23 May 2023 at 16:49, Kinney, Michael D > > wrote: > > > > > > Ard, > > > > > > I would prefer to keep the IA32 PEI support for OVMF. > > > > > > > Sure. But does that imply that all enhancements regarding memory > > protections should be introduced there as well? > > I would prefer to not support these protections in IA32 PEI. Same > for IA32 DXE. Can the proposed PPI do nothing for IA32? > Absolutely. I was just trying to narrow down whether your 'keeping IA32' meant just keeping it in working order, or have it keep up with future enhancements. My intent is to implement an optional PPI that will be used by the PEI image loader to map PE code and data sections with the appropriate permissions if they are suitably aligned. Only the DXE core would generally fit this description, but there is no reason to disallow this for shadowed PEIMs that happen to be built as PE32 binaries with 4k section alignment (although I'm not convinced of the value add there) If the PPI is not exposed (for any reason) things should just keep working as they do today. Given that OVMF no longer functionally depends on IA32 PEI, we simply won't bother to implement the PPI at all for IA32.