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.383.1685566901498734745 for ; Wed, 31 May 2023 14:01:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fbhuPY5s; 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 0256D63A50 for ; Wed, 31 May 2023 21:01:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFB50C433A7 for ; Wed, 31 May 2023 21:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685566900; bh=aFpOYTx5gOT2zOhMp+20eR+wsvtYVXLyZBIF16X/CXc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fbhuPY5s4t25ttNppyllHD8ZurN3KX/ml3telmF1ykdAbp2/ng6J2fgkl9oSZ6N4S SlwFSIoUx+YOnnrQPU2RPSicPr24M5jW3YStiPgsPy1ou2TmZlyWa3tmrP/L+qvB2h L1zoJMJS60R0obr9NTADBv8AHbRzCrpIWTOxSiXjagyFafF/ZNfSnN9yGq8aiPm7AP mZFNDoOAr054NzPA92oFh57hlku0KKnqkSjwzMgz6TgE2eH9DvYqAcVBq/3sXf2Z3O oFn5gLMzVhaaHvt0LbzWHkUhFO30InSyUbfQRiu6ElmN5YrIgGP8srMhb3xFkmQEou smy/srHeVZiQQ== Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2af318fa2b8so1545171fa.0 for ; Wed, 31 May 2023 14:01:39 -0700 (PDT) X-Gm-Message-State: AC+VfDw7/iwMKFoOGfr2jAz3kJ1J2odt6pNqQr2tZrDEzBoEJINLtMej t4YaYUYElhMtbCyzAZvn2VNO7uS+Y05oNI61/9U= X-Google-Smtp-Source: ACHHUZ7toef5MAC3HrdqxG9ujkxTbYVlq6hBZLoyISzieW5CLEBgPcEMIzX6IDL2YW9/0QcfMU/qpFrlWwjJ1iGIQLQ= X-Received: by 2002:a2e:8283:0:b0:2ac:598e:e946 with SMTP id y3-20020a2e8283000000b002ac598ee946mr3801790ljg.3.1685566897867; Wed, 31 May 2023 14:01:37 -0700 (PDT) MIME-Version: 1.0 References: <20230525143041.1172989-1-ardb@kernel.org> <20230525143041.1172989-10-ardb@kernel.org> <405e7f96-c06b-b905-0be9-16003f75ffb7@amd.com> In-Reply-To: <405e7f96-c06b-b905-0be9-16003f75ffb7@amd.com> From: "Ard Biesheuvel" Date: Wed, 31 May 2023 23:01:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 09/10] MdeModulePkg/DxeIpl: Use memory attribute PPI to remap the stack NX To: Tom Lendacky Cc: devel@edk2.groups.io, ray.ni@intel.com, "Tan, Dun" , Abner Chang , "Yao, Jiewen" , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , "Bi, Dandan" , "Gao, Liming" , "Kinney, Michael D" , Leif Lindholm , Sunil V L , "Warkentin, Andrei" Content-Type: text/plain; charset="UTF-8" On Wed, 31 May 2023 at 21:04, Tom Lendacky wrote: > > On 5/30/23 20:29, Ni, Ray via groups.io wrote: > > +@Abner Chang and @Tom Lendacky > > > >> -----Original Message----- > >> From: Tan, Dun > >> Sent: Tuesday, May 30, 2023 6:25 PM > >> To: Ni, Ray ; Ard Biesheuvel ; > >> devel@edk2.groups.io > >> Cc: Yao, Jiewen ; Gerd Hoffmann > >> ; Taylor Beebe ; Oliver Smith- > >> Denny ; Bi, Dandan ; Gao, > >> Liming ; Kinney, Michael D > >> ; Leif Lindholm ; > >> Sunil V L ; Warkentin, Andrei > >> > >> Subject: RE: [RFC PATCH 09/10] MdeModulePkg/DxeIpl: Use memory > >> attribute PPI to remap the stack NX > >> > >> Ray, > >> I think using MemoryAttribute PPI also looks good for X64 DxeIpl. > >> The only question that comes to my mind is the AMD sev feature. Since the > >> MemoryAttribute can't handle the AMD sev feature requirements(remapping > >> ghcb range from non-1:1 mapping to 1:1-mapping), we may need to find an > >> appropriate place to remap the Ghcb range. > > I'm not sure I follow. How and where would the PPI be used? And what is > meant by "remapping the ghcb range from non-1:1 mapping to 1:1 mapping? > The problem is that, for some reason, the x86 code that recreates the page tables in permanent PEI memory is part of the DxeIpl, and executes just before handing over to DXE core (as opposed to when permanent PEI memory first becomes available.) So we ended up with a highly bespoke API that creates a new set of page tablles from scratch, with special handling of the DXE stack and GHCB region, as they need special permissions in the page tables. IMHO it would make more sense to - create the new page tables as soon as PEI permanent memory becomes available - map the GHCB region shared from a SEV specific PEIM - map shadowed PEIMs RO as they are being dispatched - map the PEI stack and DXE stack NX as they are allocated (or even better, map all memory NX by default and convert to R-X as needed) Most of these cases could make use of the new generic MemoryAttributes PPI that I am proposing, but this requires some refactoring first to move the pieces out of DxeIpl that are better done elsewhere. The generic DxeIpl code that I am proposing only manages the permissions of the DXE stack, which it allocates, and uses the PPI. X64 should be able to reuse the same code once the above changes are implemented.