From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 9BC1D82171 for ; Thu, 23 Feb 2017 11:32:38 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id 203so11984627ith.0 for ; Thu, 23 Feb 2017 11:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ti13yXzip4JsDKunUHyvLSuaK0Lxr2ciSlRmywCsdac=; b=A4X79yzM5Ndz72BRafIhdNPV6/TV0eB6jzz8SXZZTDwICXJMcc2OFD4uBYojB2V8VT cHgntmkaKQyJRRZ/nMKhbXH0VghJUkT68iPQn3jl9jsLEbVv9e35e4mCbYMpo6EqMJcT JB2CtIVll5we7tpF6CHCCS+Dn02S49/7eijx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ti13yXzip4JsDKunUHyvLSuaK0Lxr2ciSlRmywCsdac=; b=UEtXjyNFNjW3qM23RTSGw4hxeIIvpC3DfQgOdezg2zlHcpvyWDw2N/ge1Yl68ojQpW NgQx8sb0hToBhgmlABCrLFWMKGujThW3/GVWP4YUrB8d6yDCOEaPYzq1BIn8MLu/jYvD W/ePhe9AKRsiHsOlGIsIFwN8UdbmSHNPZREZ3Hc7pHnU0uzEdHHBaqrQQfVOX+KefQMT IsltcXfo/WVF5GzXcqJUJlyVSvDxBIsFXh5r1nFsISXpA6Tdt0d0zoU2fpEABq2Lo5rF 3eNZ+ZiNS8AuRl7mQzYnA7xrB2LhmgKHdm59cUHFUa+qRQ4G4ad0m/7M2jBCEdyl3YvH ZvAw== X-Gm-Message-State: AMke39mFx7EN6+NNOMB0xEWgvPUHzBy23F2QGkWdDOGuyG9CHqzLse9rILBk/y337Dg7A8er/4ZFMu0jgFrLBzEz X-Received: by 10.107.168.25 with SMTP id r25mr11377533ioe.45.1487878356184; Thu, 23 Feb 2017 11:32:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.198.134 with HTTP; Thu, 23 Feb 2017 11:32:35 -0800 (PST) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8F43D0@shsmsx102.ccr.corp.intel.com> References: <1487787898-5222-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8F4220@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8F43D0@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 23 Feb 2017 19:32:35 +0000 Message-ID: To: "Yao, Jiewen" Cc: "edk2-devel@lists.01.org" , "afish@apple.com" , "leif.lindholm@linaro.org" , "Kinney, Michael D" , "Gao, Liming" , "lersek@redhat.com" , "Tian, Feng" , "Zeng, Star" Subject: Re: [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: , X-List-Received-Date: Thu, 23 Feb 2017 19:32:38 -0000 Content-Type: text/plain; charset=UTF-8 On 23 February 2017 at 11:45, Yao, Jiewen wrote: > Sounds great. > > I look forward to your V2. > Hello Jiewen, What I am currently struggling with is the fact that we don't use the GCD RO/XP permissions at all. This means that RefreshGcdMemoryAttributes () (or SyncCacheConfig() on ARM) will remove non-exec attributes if we add them in the CPU arch protocol installation notifier callback. So there are two approaches imo: - introduce a way to call into the DXE core to mark all non-code regions non-exec after RefreshGcdMemoryAttributes () has been called, or - add the RO/XP attributes to the GCD memory space map, and enable them in the attributes. Option #2 will require a change to CoreAddRange to prevent those RO/XP attributes to leak into the UEFI memory map, because that results in all regions have to RO/XP attributes set by default, which is obviously not what we want. Any thoughts? Thanks, Ard.