From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A701780452 for ; Mon, 20 Mar 2017 04:38:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0E5A67E9DD; Mon, 20 Mar 2017 11:38:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0E5A67E9DD Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0E5A67E9DD Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-55.phx2.redhat.com [10.3.116.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3A850173DA; Mon, 20 Mar 2017 11:38:49 +0000 (UTC) To: Ard Biesheuvel , Michael Zimmermann References: Cc: edk2-devel-01 From: Laszlo Ersek Message-ID: <72d13754-5c7d-9734-33a8-bd2dab32b2bb@redhat.com> Date: Mon, 20 Mar 2017 12:38:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 20 Mar 2017 11:38:50 +0000 (UTC) Subject: Re: SetMemorySpaceAttributes with EFI_MEMORY_XP X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 11:38:49 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/20/17 12:20, Ard Biesheuvel wrote: > On 20 March 2017 at 11:16, Michael Zimmermann wrote: >> Ard, why is SetMSetMemorySpaceAttributes being called in first place? >> (ignoring the recent NX patch) >> Looking at the initial GCD, it looks like unused memory usually >> doesn't have any attributes set anyway. >> > > Originally, we added the new memory with > EFI_MEMORY_WB|EFI_MEMORY_WT|EFI_MEMORY_WC|EFI_MEMORY_UC capabilities, > and selected the EFI_MEMORY_WB attribute with the call to > gDS->SetMemorySpaceAttributes. Later, we removed all capabilities > expect EFI_MEMORY_WB, since the other ones cannot be supported under > virtualization with KVM. > > Whether that makes the SetMemorySpaceAttributes redundant is not > entirely clear to me, but it does appear the adding the memory does > the right thing wrt non-exec permissions if the policy is enabled. So > perhaps we can simply drop this call? Won't that turn off caching for the memory just added? Thanks Laszlo > > >> On Mon, Mar 20, 2017 at 12:04 PM, Ard Biesheuvel >> wrote: >>> On 20 March 2017 at 10:32, Michael Zimmermann wrote: >>>> Hi, >>>> >>>> I didn't test ArmVirtQemuKernel but I'm trying to use some of the code >>>> for another platform. >>>> So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy >>>> being enabled? >>>> https://github.com/tianocore/edk2/blob/76874be3d411bf8daac051718e20932e0bf97d70/ArmVirtPkg/HighMemDxe/HighMemDxe.c#L95 >>>> Status = gDS->SetMemorySpaceAttributes (CurBase, CurSize, Attributes); >>>> >>>> Neither the memory that was added by this Dxe nor the one added >>>> automatically by GCD has the EFI_MEMORY_XP capability which causes >>>> SetMemorySpaceAttributes to return EFI_UNSUPPORTED. >>>> >>> >>> That is a very good point. I have been caught by this more than once >>> already (and I did test this, but not as thoroughly as I should have, >>> apparently) >>> >>> This is caused by the unfortunate situation in EDK2 that GCD >>> permission attributes are ambiguous: it does not distinguish between >>> 'the memory controller allows this range to be configured as >>> non-executable' and 'the nature of the contents of this memory region >>> allows it to be mapped without executable attributes', and therefore, >>> RO/XP are never used in the GCD memory space map. >>> >>> The solution is to use the CPU_ARCH_PROTOCOL interface explicitly to >>> set the XP attribute on the memory itself (but not on the descriptors >>> in the GCD or UEFI memory maps). I will spin a patch to fix this. >>> >>> Thanks, >>> Ard.