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 7DDE21A1E06 for ; Fri, 2 Sep 2016 13:30:02 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 041933B72D; Fri, 2 Sep 2016 20:30:02 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-76.phx2.redhat.com [10.3.116.76]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82KU0tY022449; Fri, 2 Sep 2016 16:30:01 -0400 To: Michael Zimmermann , "edk2-devel@lists.01.org" , Ard Biesheuvel References: From: Laszlo Ersek Message-ID: Date: Fri, 2 Sep 2016 22:30:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 02 Sep 2016 20:30:02 +0000 (UTC) Subject: Re: post-ExitBootServices memory protection of RT_Data (ARM) 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: Fri, 02 Sep 2016 20:30:02 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/02/16 15:08, Michael Zimmermann wrote: > Hi, > > a friend of mine works with a hacked Luma WP device. he can already boot > Android by replacing UEFI with a linux bootloader. > What would be nice however is using UEFI's LinuxLoader. The problem with > that seems to be that even after ExitBootServices, booting linux from > addresses previously allocated as RT_Data seems to just not work(no UART > output etc and we don't have jtag). > > So, how can UEFI have such an influence at that point? Is there a ARM/TZ > feature for that? Can it be disabled? > I thought respecting the memory map would just be needed in case you want > to be able to call RuntimeServices and that you don't need to do that if > you don't need them. You most likely don't have execution rights for those pages. Refer to 4.6 EFI Configuration Table & Properties Table EFI_MEMORY_ATTRIBUTES_TABLE in the UEFI 2.6 spec. See also git commit range 868d614a8532..47eb798d3619 for the implementation of the feature in the DXE Core. If you build the DXE Core with the DEBUG_VERBOSE bit (0x00400000) enabled in gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel, then the DXE Core will print the table at Ready-to-Boot. In my case, on aarch64 (Mustang), I can see two different attributes in total: - 0x8000000000004000 == EFI_MEMORY_RUNTIME | EFI_MEMORY_XP (Read/Write Data) - 0x8000000000020000 == EFI_MEMORY_RUNTIME | EFI_MEMORY_RO (Write-protected Code) which maps pretty well to runtime services data / runtime services code. For example, EFI_MEMORY_XP maps to TT_PXN_MASK in "ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c". Now, what is ultimately responsible for setting these attributes (mapped to the architecture) in the MMU is another question... I vaguely recall ties to the now-deprecated properties table / EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA (see them in the same chapter in the UEFI spec). I don't think I can tell you what is the thing that ultimately decides about setting up these page attributes. Thanks Laszlo