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 <jeffrey.l.h...@gmail.com>
>> 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 <leif.lindh...@linaro.org>
>
> 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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
