From patchwork Wed Feb 22 18:24:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 94358 Delivered-To: patch@linaro.org Received: by 10.140.20.99 with SMTP id 90csp1041779qgi; Wed, 22 Feb 2017 10:25:08 -0800 (PST) X-Received: by 10.84.164.106 with SMTP id m39mr27007615plg.9.1487787908441; Wed, 22 Feb 2017 10:25:08 -0800 (PST) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id g10si1851488pge.420.2017.02.22.10.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 10:25:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id BDBB882005; Wed, 22 Feb 2017 10:25:07 -0800 (PST) X-Original-To: edk2-devel@lists.01.org Delivered-To: edk2-devel@lists.01.org Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 333FD81F3A for ; Wed, 22 Feb 2017 10:25:07 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id z61so7959820wrc.1 for ; Wed, 22 Feb 2017 10:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=naCX7mWrTCUYM5fkVWii2i9oyzlhKlbejwLF0o/UIaQ=; b=iclJK6DCrQlHT6cTSruYK43XRLOlNoD+c6gHNoef3r598bAB1VGt+EJIlBAod/vnph QGjBzgsz9BaL3VLJad+yGmg3vs/zlymlkgRw0R4XtXeGVeMQPlzW0uWHgQPnuhSsf3OG 326KNlfzB0o1aFvxOLn8UA3X0B84s//1i9SH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=naCX7mWrTCUYM5fkVWii2i9oyzlhKlbejwLF0o/UIaQ=; b=rGUazqmphX/qcpkHDwEUIgy06hkWOPWzkrdn2AXehpwXPlO+P8cx0pakspjkEsz30P kSLDPfBkbF0/fPeiu1n0HccY55GK63NI1wzcgp7cAsey91XyxAsxgHmaky+soBqwF0fj WmoDa3+cysEJyv2NkfeX726Yn30syFxqF6zGyUnUyxPV3u0prpd/D6K2igwHZpCoTgmu MW2GouAb8jveRfetuG3zUdtOlo2SCLqWigMKA81P5/37ImSvJZS+xnXmo5duShJ+Vrk+ OnxDS6uNhfAYYnONdYH6Z01Gfobna0KkRDJoSQfZXe7WPsWjDr8/4s0I7H5F1hA03XdQ 9FGA== X-Gm-Message-State: AMke39kw36983927Lkcg+0P6eq6ZC9gXKrEZT5wESffWDlxPrpYv+4FrJ7Mgq1Uz3qP7aild X-Received: by 10.223.166.137 with SMTP id t9mr25205955wrc.15.1487787905388; Wed, 22 Feb 2017 10:25:05 -0800 (PST) Received: from localhost.localdomain ([196.80.204.181]) by smtp.gmail.com with ESMTPSA id e73sm3504667wmi.32.2017.02.22.10.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 10:25:04 -0800 (PST) From: Ard Biesheuvel To: edk2-devel@lists.01.org, afish@apple.com, leif.lindholm@linaro.org, michael.d.kinney@intel.com, liming.gao@intel.com, jiewen.yao@intel.com Date: Wed, 22 Feb 2017 18:24:54 +0000 Message-Id: <1487787898-5222-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Subject: [edk2] [RFC PATCH 0/4] RFC: increased memory protection X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: feng.tian@intel.com, lersek@redhat.com, star.zeng@intel.com, Ard Biesheuvel MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" Hello all, This is a proof of concept implementation that removes all executable permissions from writable memory regions, which greatly enhances security. It is based on Jiewen's recent work, which is a step in the right direction, but still leaves most of memory exploitable due to the default R+W+X permissions. The idea is that the implementation of the CPU arch protocol goes over the memory map and removes exec permissions from all regions that are not already marked as 'code. This requires some preparatory work to ensure that the DxeCore itself is covered by a BootServicesCode region, not a BootServicesData region. Exec permissions are re-granted selectively, when the PE/COFF loader allocates the space for it. Combined with Jiewen's code/data split, this removes all RWX mapped regions. There is a caveat, though (and there are likely more of that kind): the EBC driver will need some work to ensure the thunk buffers have the noexec restriction lifted. This could be done in the EBC driver, but perhaps it is better to either a) modify the DXE core so it always removes noexec restrictions when allocating code pages, or b) add AllocateExecPages/AllocateExecPool() functions to the MemoryAllocationLib API Comments please! Ard Biesheuvel (4): MdeModulePkg/DxeCore: allow BootServicesData->BootServicesCode conversion MdeModulePkg/DxeCore: convert the DxeCore memory region to BootServicesCode MdeModulePkg/DxeCore: lift non-exec permissions on loaded images ArmPkg/CpuDxe: remap all data regions non-executable ArmPkg/Drivers/CpuDxe/CpuDxe.c | 76 ++++++++++++++++++++ MdeModulePkg/Core/Dxe/DxeMain.h | 8 +++ MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 2 + MdeModulePkg/Core/Dxe/Image/Image.c | 8 +++ MdeModulePkg/Core/Dxe/Mem/Page.c | 18 ++++- 5 files changed, 111 insertions(+), 1 deletion(-) -- 2.7.4 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel