On 06/21/2018 09:45 PM, Simon Glass wrote:
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,
Not, it's not ARM specific. You may hit this on any system that actually
checks for PROT_EXEC.
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.
In that case we can just tell mmap() to map RAM with PROC_EXEC.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
