From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 22C831A1E06 for ; Fri, 2 Sep 2016 13:45:28 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id w207so4283229wmw.0 for ; Fri, 02 Sep 2016 13:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v91nut0vbt1/hMeI/5DCwdXxFt37bj1c31mC86C/zaQ=; b=l55mKh2bZgT1pux/5nmdW5Aj0+guwzBte7ZApOiPrGmHe1+65ExMwm0DxikWMC8IfA q9H5xPDAhp4Xm2L1T+Ms95mlhOTCbbKIasAPmGxGTF9J9Uwt51+Y1JAuojyNyWz61FXN L3hYhJXJchCHXks4Q3qfX13YCNVwzWzrrlA6aRktftIDD9fYDIczH3gtWOXz4/XyhlXz XfS2FBpAJ6DJpccaUXYuRcVGWNHF43htobHezJ93jwsIuJw8s6pVwC+ZSQ3gpGqVFA2S egtaz4wnwlnKswnUhQvStFpz4LdEIpPenGNIs5NW/cWqGpgONvVYbwsYuq1t5npFm+mK fkzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v91nut0vbt1/hMeI/5DCwdXxFt37bj1c31mC86C/zaQ=; b=Hv01uz3A4K3pMAYLxsiCG/MY9T1rR/Txvq4PA/DD+Z5Rs26YY1/CyJvLqrVYGODr3i ABKh4Rn0n36rvE6tP73AZJRn1kt4RI6zR9sc9a7ZvS7r+hDe1p76+HXdKIe6AYwnx0Fp 4VTrOpSHTwcd1YdyancSShZkrreLlk1ngMGHzPulG09mGKJHyBjE6TVWxrt3sjP3dSrD 6xN3bDY09tRfykU8S0XFUypfkZ++t/OluwNMwTkfCwql+J4nPneU3XjVkMXCmkOb4RjR vpCz/Gn7X7vKgtyq+c81PsPQCylNl9kcR+tesGvq/vSI3I4IrgCNhoU2podjaIr9smfw pvZQ== X-Gm-Message-State: AE9vXwMzZgEbqBCct0a8FXd9M7tGSqxbkiB1l79we6nkwWD8Ls8/Kq9Y469Mww/ayH9X/0OnqaCTt99PTNwmng== X-Received: by 10.195.18.68 with SMTP id gk4mr8512818wjd.192.1472849126447; Fri, 02 Sep 2016 13:45:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.0.204 with HTTP; Fri, 2 Sep 2016 13:45:26 -0700 (PDT) In-Reply-To: References: From: Michael Zimmermann Date: Fri, 2 Sep 2016 22:45:26 +0200 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Ard Biesheuvel X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:45:28 -0000 Content-Type: text/plain; charset=UTF-8 If I understand this correctly this is just some MMU feature, right? I'm talking about a pure ARM(with atag's) linux kernel which is not UEFI aware. Also the LinuxLoader disables almost everything(MMU, caches, it calls exitbootservices etc). I really can't explain technically what UEFI could have done to accomplish this protection with the MMU being disabled. Thanks Michael On Fri, Sep 2, 2016 at 10:30 PM, Laszlo Ersek wrote: > 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 >