Hi Alex, On 21 June 2018 at 03:44, Alexander Graf <ag...@suse.de> wrote: > On 06/21/2018 04:02 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 18 June 2018 at 09:23, Alexander Graf <ag...@suse.de> wrote: >>> >>> With efi_loader, we may want to execute payloads from RAM. By default, >>> permissions on the RAM region don't allow us to execute from there >>> though. >>> >>> So whenever we get into the efi_loader case, let's mark RAM as >>> executable. >>> That way we still protect normal cases, but allow for efi binaries to >>> directly get executed from within RAM. >>> >>> For this, we hook into the already existing allow_unaligned() call which >>> also transitions the system over into semantics required by the UEFI >>> specification. >>> >>> Signed-off-by: Alexander Graf <ag...@suse.de> >>> --- >>> arch/sandbox/cpu/cpu.c | 14 ++++++++++++++ >>> arch/sandbox/cpu/os.c | 14 ++++++++++++++ >>> include/os.h | 19 +++++++++++++++++++ >>> 3 files changed, 47 insertions(+) >>> >> What is this patch actually for? Does it make something work that did >> not before? Where is it called? > > > At least on aarch64 executing from the RAM region fails on the first > instruction you call inside it, because it's not mapped with PROT_EXEC. I > think not mapping it with PROT_EXEC is a good thing in the normal sandbox > use case, but for EFI we need to run from RAM ;). > > So yes, this patch makes that work. It's called from allow_unaligned() which > gets called from the bootefi command function.
OK I see. This is so that sandbox running on an ARM platform can actually load and run an EFI application, right? Can you please make this code and commit message ARM-specific? Also, just call your code on start-up in cpu.c. We don't need to connect to an allow_unaligned() thing, which is a misnomer in this case. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
