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.25804.1678727888668004222 for ; Mon, 13 Mar 2023 10:18:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VY5StO49; 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 3263A6142D; Mon, 13 Mar 2023 17:18:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8462C4339B; Mon, 13 Mar 2023 17:18:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678727888; bh=enzU9nRwv2jnaANIFLtGqW11kaVPJtMn936NKS4zICs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VY5StO492kw93jg99VPyDWGF3SAaKttvzrbyee2d7sTG7gFzfIJ+ZWPC+cZbK/34L x+Xox/y44hE0KNS2xPaf9M3SzxrPADthrnHbE555KzuK4vXzWXi3H/9CztrgttehJT WsYben1YbDA60ezVwfVh8kJuFySgq2T6HIWqNIAkZ2wF22LTg3DixzbgIAQmRopiJ5 BEWq0FeAepXxAKFHVWhfzq87rMw9iHoeE/xxPSIGl2mizN6HwH3o0laaL6XnnwhM9R WIXQsOe277as0T6EGHD/74HSJW44MNQp54NVYlTBwgTlrBfCaPMICTIn8RJa4IjTXA FX9BZh15IPiHA== From: "Ard Biesheuvel" To: devel@edk2.groups.io Cc: Ard Biesheuvel , Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Leif Lindholm , Sami Mujawar , Taylor Beebe Subject: [PATCH v5 13/38] MdeModulePkg/DxeCore: Unconditionally set memory protections Date: Mon, 13 Mar 2023 18:16:49 +0100 Message-Id: <20230313171714.3866151-14-ardb@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230313171714.3866151-1-ardb@kernel.org> References: <20230313171714.3866151-1-ardb@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Instead of relying on a questionable heuristic that avoids calling into the SetMemoryAttributes () DXE service when the old memory type and the new one are subjected to the same NX memory protection policy, make this call unconditionally. This avoids corner cases where memory region attributes are out of sync with the policy, either due to the fact that we are in the middle of ramping up the protections, or due to explicit invocations of SetMemoryAttributes() by drivers. This requires the architecture page table code to be able to deal with this, in particular, it needs to be robust against potential recursion due to NX policies being applied to newly allocated page tables. Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c b/MdeModulePkg/C= ore/Dxe/Misc/MemoryProtection.c index b89ab046fa73..5a82eee80781 100644 --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c @@ -1246,7 +1246,6 @@ ApplyMemoryProtectionPolicy ( IN UINT64 Length=0D )=0D {=0D - UINT64 OldAttributes;=0D UINT64 NewAttributes;=0D =0D //=0D @@ -1302,16 +1301,5 @@ ApplyMemoryProtectionPolicy ( //=0D NewAttributes =3D GetPermissionAttributeForMemoryType (NewType);=0D =0D - if (OldType !=3D EfiMaxMemoryType) {=0D - OldAttributes =3D GetPermissionAttributeForMemoryType (OldType);=0D - if (OldAttributes =3D=3D NewAttributes) {=0D - // policy is the same between OldType and NewType=0D - return EFI_SUCCESS;=0D - }=0D - } else if (NewAttributes =3D=3D 0) {=0D - // newly added region of a type that does not require protection=0D - return EFI_SUCCESS;=0D - }=0D -=0D return gCpu->SetMemoryAttributes (gCpu, Memory, Length, NewAttributes);= =0D }=0D --=20 2.39.2