On 06/21/2018 09:45 PM, Simon Glass wrote:
Hi Alex,
On 21 June 2018 at 03:44, Alexander Graf agraf@suse.de wrote:
On 06/21/2018 04:02 AM, Simon Glass wrote:
Hi Alex,
On 18 June 2018 at 09:23, Alexander Graf agraf@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 agraf@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