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.85358.1682442690013859664 for ; Tue, 25 Apr 2023 10:11:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vIlyDisi; 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 47ABE60AC4 for ; Tue, 25 Apr 2023 17:11:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE09BC433D2 for ; Tue, 25 Apr 2023 17:11:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682442688; bh=1jiPVklJylb5wb2cXPaJs/qcsIOZjw9v4nhyCstkqhU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vIlyDisi63em3/bbA1zwrmwBGd9hpZR3UXYSLntFjK28Jkhx0Vj2BYDYtOjhouSsE OmyZfce9BGhsrA09CW10o3V/CviaW/ymf4ZWMMos1YxTDez/7MgwucDYVj1Cs4suu5 l/08ONLD9a7HhX6g1RF9wHz2E8LcGfe3BAsk21lXlXgsVjGxcdr8EfPxj6pxAOka/I KSR0A1mUF2pYZlw5v7pQemJ7JR6XzgmCl/VWXwsyuvUQIjHqCthas277u1MkN4YXm7 swRU9EGwbcQmwocpheNXyiAi+yAX5ZPbKHN+fYH3GSB3IZuGZAtPefOba78mE6mGGT wNVbjfQC52j3A== Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-4edc63c82d1so6194640e87.0 for ; Tue, 25 Apr 2023 10:11:28 -0700 (PDT) X-Gm-Message-State: AAQBX9dCHm4dAyzmuIii4R0CtuLgwDUp4lu1ZEDaE0nrvZeLuq/+A7vj vPKKItxk2Kr+XiUXw4tojChxsz5soVQNPfV5/UA= X-Google-Smtp-Source: AKy350Z88BUCOEpUY0urF7m1bY5R3dNFtolNR33bQPLcqJCBs9casToOon8Ieds6f4KU4dQngkocqPv4Ud4v6yj+VCc= X-Received: by 2002:ac2:5507:0:b0:4db:513f:fe2a with SMTP id j7-20020ac25507000000b004db513ffe2amr4895720lfk.23.1682442686689; Tue, 25 Apr 2023 10:11:26 -0700 (PDT) MIME-Version: 1.0 References: <20230424100552.2718-1-dun.tan@intel.com> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 25 Apr 2023 18:11:15 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [Patch V3 0/8] Create page table by CpuPageTableLib in DxeIpl To: devel@edk2.groups.io, ray.ni@intel.com Cc: "Kinney, Michael D" , "Tan, Dun" Content-Type: text/plain; charset="UTF-8" On Tue, 25 Apr 2023 at 03:45, Ni, Ray wrote: > > > > > -----Original Message----- > > From: devel@edk2.groups.io On Behalf Of Ard > > Biesheuvel > > Sent: Tuesday, April 25, 2023 2:07 AM > > To: Kinney, Michael D > > Cc: devel@edk2.groups.io; Tan, Dun > > Subject: Re: [edk2-devel] [Patch V3 0/8] Create page table by > > CpuPageTableLib in DxeIpl > > > > On Mon, 24 Apr 2023 at 19:51, Kinney, Michael D > > wrote: > > > > > > Hi Ard, > > > > > > Thanks for the feedback. Let's work on this approach. > > > > > > Are there similar needs for CPU related services in the DXE Core before > > > the CPU AP is loaded? > > > > > > If we are going to define a new lib class to abstract DXE IPL requirements, > > > it would be good to cover DXE Core requirements too. > > > > > > > Yeah, excellent point. > > > > The problem I have had to work around in my strict permissions series > > (which includes the linked patch) is that there is a window from the > > moment DXE core is dispatched until the moment the CPU arch protocol > > DXE driver is dispatched where we don't have an architectural means to > > manipulate memory permissions. > > > > So what we'd need here is a library version of the following method > > > > typedef > > EFI_STATUS > > (EFIAPI *EFI_CPU_SET_MEMORY_ATTRIBUTES)( > > IN EFI_CPU_ARCH_PROTOCOL *This, > > IN EFI_PHYSICAL_ADDRESS BaseAddress, > > IN UINT64 Length, > > IN UINT64 Attributes > > ); > > What's your idea here? > Besides HandOffToDxeCore(), you require a 2nd lib API as above for > early DXE phase before CPU AP is available? > > Why do we want to combine two APIs into one lib class? > If combined, what lib class name do you think is proper to describe the lib purpose? > > It seems to me lacking of CPU AP in early DXE phase is acknowledged by PI spec. > Having the 2nd API for DXE early phase is like a workaround to fix PI spec gap, do you think so? > Perhaps. Maybe the problem here is that there setting memory permissions is not part of the PEI CPU arch protocol. It would make sense for shadowed PEIMs as well as the DXE core to be mapped with strict permissions at dispatch time (if the section alignment permits it). For XIP PEIMs, nothing would change, and if PEI executes in place from DRAM, the whole FV can be mapped read-only. Or perhaps this should be a separate PPI altogether, and we could define it as one that is callable from DXE core if the CPU arch protocol has not been dispatched yet. I don't really care whether or not we add this to the PI spec tbh > > > > *However*, I am aware that the X86 DXE IPL code deviates from this, as > > it needs to build long mode compatible page tables before switching > > from IA32 to X64, right? > > DXEIPL creates long mode page table with following characteristics: > * 1:1 mapping to cover the entire memory space > * Set the bottom 4K of BSP stack as not-present - prevent stack overflow > * Set the entire BSP stack as NX - prevent buffer overflow attack > * Set the [0-4k] region as not-present - null protection > > But it doesn't set DxeCore code region as RO, or data region as NX. > > I describe the X86 DXEIPL page table behavior as above. Because I hope > you could explain a bit more on your thoughts. I don't quite understand > your above wordings. > I guess the long mode switch is sufficiently special that it will be very hard to define a sane API that covers all of this. OTOH, it seems like a missed opportunity to rely on DXE IPL to create all these restricted mappings, and invent something completely new just to remap the DXE core text and data sections RO / XP. And note that, for arm64, this should occur before the code is actually called, since the restricted mode we would like to enable for EDK2 does not permit memory that is both writable and executable at all.