From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::22c; helo=mail-it0-x22c.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 88C7E21ED1C53 for ; Wed, 14 Mar 2018 12:33:07 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id k135-v6so6078435ite.2 for ; Wed, 14 Mar 2018 12:39:30 -0700 (PDT) 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:content-transfer-encoding; bh=RNeEQIks+YXXVIv9SoEOlKUIW5Gwd//0X0Z/rpkaJsw=; b=CIsJwQ6/rNhmHAID+cga+CHrVF4i4hus1f8Ap6krdzBaN79GV/vohdCGMimIozPu5h RK0ayu9pZ6H8ymIE9o1ikOBmWJXlkOURDS6Ss20EiIFa4aRq4ew9DPWjEEYB28iETQVC vuw89j1wMHHfdSu4AHQuFD/r58jUdmwAyp4Kw= 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:content-transfer-encoding; bh=RNeEQIks+YXXVIv9SoEOlKUIW5Gwd//0X0Z/rpkaJsw=; b=qOyxJblx3vgoik5PTg4ruW/FnT5ANuWGuhxw6h3sdlzI1h9RlTecBX57qTinMxFX12 4KTK9A4/m9Au3E7H7GW3lCk0w9UTsZ3CVPvh4LIUPRIrtaBNfLTEz+6vMGDJrTvirkmD CaH3AbCvCFmQ87MrVy5H5iuVgiWHJ6LHYw0b8CH9OBry7AdzG4VE7YVKaAwqy+TLNh9q dAwfoh4/KMFlAlvuhep4nSvM3vZbWLGPp56uGpFp2tlI2w9/lmxErsIWoRfj54L3iYb6 OnVoaWdhgjE9z7DD7zlQ2pNOGiRulHllpMBY4HnSN+HkYrtVV44KnMMZESL2kaX1SRAH gkaA== X-Gm-Message-State: AElRT7Hm8wM9SPiqhlXyEfsWEXqxPDTJn5YVbqIHJjR+b2rGDxLZ7UPa RfjEeFOZyQXED0YIY7X/R1Nr6QcwXakcUaCxqGI32A== X-Google-Smtp-Source: AG47ELu9C4j/pYPLA6Qpbjmz7s04GxNjIiNPCd6B2iue0g4b1iH/ChRhZO9w75GRJ15D8MpyAlqtd83sCDfZxTOIZ9U= X-Received: by 10.36.90.5 with SMTP id v5mr3376266ita.138.1521056369625; Wed, 14 Mar 2018 12:39:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 14 Mar 2018 12:39:29 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Wed, 14 Mar 2018 19:39:29 +0000 Message-ID: To: Evan Lloyd Cc: "edk2-devel@lists.01.org" , "Matteo.Carlini@arm.com@arm.com" <"Matteo.Carlini@arm.com"@arm.com>, "leif.lindholm@linaro.org@arm.com" <"leif.lindholm@linaro.org"@arm.com>, "nd@arm.com@arm.com" <"nd@arm.com"@arm.com>, Girish Pathak , Sami Mujawar , Dong Wei , Mitch Ishihara Subject: Re: AARCH64:Use of EFI_MEMORY_XP X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 19:33:08 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 14 March 2018 at 19:34, Evan Lloyd wrote: > Hi Ard. > We still have a minor problem in that the spec disqualifies EFI_MEMORY_XP= for AARCH64. > Do you have any thoughts on this? > How should we proceed here? I assume the specification statement was a c= onsidered decision. > Do we need to get it changed, or is EFI_MEMORY_XP unnecessary? > No, that is a spec bug EFI_MEMORY_RO and EFI_MEMORY_XP are essential for things like the memory attributes table, which prevents UEFI memory regions from being an exploit walhalla consisting only of memory regions that are writable and executable at the same time, which would defeat all the hard work OS engineers are doing to tighten memory permissions in privileged execution contexts. In this particular case, having a read-write-execute framebuffer could be a security hazard as well, so I'd prefer to strip the executable permissions here. >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Evan Lloyd >> Sent: 08 January 2018 18:51 >> To: Ard Biesheuvel >> Cc: "Matteo.Carlini@arm.com"@arm.com; >> "leif.lindholm@linaro.org"@arm.com; "nd@arm.com"@arm.com; edk2- >> devel@lists.01.org; Arvind Chauhan ; >> "ard.biesheuvel@linaro.org"@arm.com; Thomas Abraham >> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: >> New DP500/DP550/DP650 platform library. >> >> >> >> > -----Original Message----- >> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> > Sent: 23 December 2017 16:07 >> > To: Evan Lloyd >> > Cc: edk2-devel@lists.01.org; Arvind Chauhan >> ; >> > Daniil Egranov ; Thomas Abraham >> > ; "ard.biesheuvel@linaro.org"@arm.com; >> > "leif.lindholm@linaro.org"@arm.com; >> > "Matteo.Carlini@arm.com"@arm.com; "nd@arm.com"@arm.com >> > Subject: Re: [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: New >> > DP500/DP550/DP650 platform library. >> > > ... >> > > + // Mark the VRAM as write-combining. The VRAM is inside the DRAM, >> > > + which is // cacheable, for ARM/AArch64 EFI_MEMORY_WC memory >> is >> > actually uncached. >> > > + Status =3D gDS->SetMemorySpaceAttributes ( >> > > + *VramBaseAddress, >> > > + *VramSize, >> > > + EFI_MEMORY_WC >> > >> > Please add EFI_MEMORY_XP here >> > >> >> [[Evan Lloyd]] We can do that, happily. However, in looking at this we >> found that the UEFI spec has in "2.3.6 AArch64 Platforms", section "2.3.= 6.1 >> Memory types": >> EFI_MEMORY_XP, ... = Not used >> or defined >> >> Does that suggest we need a minor spec update? >> >> > > + ); > ... > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you.