From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.5433.1675879105314292445 for ; Wed, 08 Feb 2023 09:58:25 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PEm7vzCM; spf=pass (domain: kernel.org, ip: 145.40.68.75, 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 ams.source.kernel.org (Postfix) with ESMTPS id 1A8B8B81CDC; Wed, 8 Feb 2023 17:58:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 636F7C433D2; Wed, 8 Feb 2023 17:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675879101; bh=pPPmfQSD3fCglsdHjT1ujOc+riUwAixmim7y6LqmS+I=; h=From:To:Cc:Subject:Date:From; b=PEm7vzCMHQ7bKs5SaVRhI+4W1l+yYPtvcAHQn6KFkPYa7NdCnxxkZ4N7B8lwNJEaN N6FERgWiO/Hlv7xbL+XvmaFs/o1ZMZ7aI5sQmzTfu0BAU6Gpb26ypHNexe+LlTmK++ BWY9oloxZyQVyXKgjeC617WXaItdPPuZiDPc4IYk2mhCg+Ua07R7WAmcu5hASNxho5 bEaLFarG5hq9oYJdz9++joHNrSiaY9c/woWXfoTry2fMLxPtYCjgFufJoKRhAMQQfB UckMEhtgX+SzthiroE6unnYmlwJNnrkE/W/AuZEAWSspEyPJYiPIABse7YBEeRcmHZ dhdvuTu9GIkIg== 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 , =?UTF-8?q?Marvin=20H=C3=A4user?= Subject: [PATCH 0/3] Apply NX protections more strictly Date: Wed, 8 Feb 2023 18:58:09 +0100 Message-Id: <20230208175812.700129-1-ardb@kernel.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This fixes an issue reported by Marvin, where NX memory protections are=0D applied in a rather unreliable manner, resulting in the possibility that=0D memory mappings may exist that are using different attributes than=0D intended.=0D =0D The reason for this approach was that applying memory protections=0D eagerly (i.e., after every alloc/free even if the memory attributes are=0D not expected to change as a result) may result in unbounded recursion in=0D the page table code, due to the fact that the page tables it allocates=0D need to be remapped with the correct attributes as well.=0D =0D This has not been reported as being an issue on x86, but on ARM, this=0D needs a couple of fixes so that converting between EfiConventionalMemory=0D and EfiBootServicesData will never trigger a block entry split. With=0D that fixed, we can just remove the shortcut from DXE core and always=0D call SetMemoryAttributes.=0D =0D Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3316=0D =0D Cc: Michael Kinney =0D Cc: Liming Gao =0D Cc: Jiewen Yao =0D Cc: Michael Kubacki =0D Cc: Sean Brogan =0D Cc: Rebecca Cran =0D Cc: Leif Lindholm =0D Cc: Sami Mujawar =0D Cc: Taylor Beebe =0D Cc: Marvin H=C3=A4user =0D =0D Ard Biesheuvel (3):=0D ArmPkg/ArmMmuLib: Avoid splitting block entries if possible=0D ArmPkg/CpuDxe: Perform preliminary NX remap of free memory=0D MdeModulePkg/DxeCore: Unconditionally set memory protections=0D =0D ArmPkg/Drivers/CpuDxe/CpuDxe.c | 77 ++++++++++++++++++++= =0D ArmPkg/Drivers/CpuDxe/CpuDxe.inf | 2 +=0D ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 9 +++=0D MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 29 --------=0D 4 files changed, 88 insertions(+), 29 deletions(-)=0D =0D -- =0D 2.39.1=0D =0D