grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] arm64/linux/loader: Use EFI CODE allocations for the linux ker


From: Alexander Graf
Subject: Re: [RFC] arm64/linux/loader: Use EFI CODE allocations for the linux kernel
Date: Mon, 8 Apr 2019 12:19:05 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 05.04.19 06:06, Leif Lindholm wrote:
> On Thu, Apr 04, 2019 at 06:57:29PM +0200, Daniel Kiper wrote:
>> On Thu, Apr 04, 2019 at 07:54:55AM -0700, Jeffrey Hugo wrote:
>>> Some UEFI implementations for ARM64 devices apply strict permissions on
>>> the different allocation types.  In these implementations, DATA
>>> allocations have XN (execute never) permissions, preventing code execution
>>> from those pages.
>>>
>>> On these implementations, the Linux kernel is loaded to DATA pages, which
>>> causes a permission fault when GRUB attempts to kick off the kernel.  This
>>> results in a device crash.
>>>
>>> Fix this by allocating CODE pages for the Linux kernel.
>>>
>>> Signed-off-by: Jeffrey Hugo <address@hidden>
>> Make sense for me but I would like to hear Leif's opinion too. I treat
>> this a fix and if he is OK with it I am happy to take it into release.
> This complements f826330683675f0deb55b58fd229afd7d65fb053
> ("efi: change heap allocation type to GRUB_EFI_LOADER_CODE"), so I'm
> all for it.
>
> Reviewed-by: Leif Lindholm <address@hidden>
>
> This does bring to mind the clunkiness of the above. Marking
> *everything* executable bypasses the improved security provided by the
> firmware. Should I register a bug on Savannah to address this?
> (blatantly not for the upcoming release)


I quite frankly don't understand why we need to mark the PE binary as
CODE in the first place. I thought the whole point of invoking the UEFI
loader protocol was to ensure that the placement of sections from that
binary into CODE/DATA happens properly?

Or are we not calling LoadImage?


Alex





reply via email to

[Prev in Thread] Current Thread [Next in Thread]