On 26.01.19 10:31, Heinrich Schuchardt wrote:
On 1/25/19 10:43 PM, Ard Biesheuvel wrote:
On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/23/19 6:33 PM, Alexander Graf wrote:
While discussing something compeltely different, Ard pointed out that it might be legal to omit calling SetVirtualAddressMap altogether.
While that sounds great, we currently rely on that call to remove all function pointers to code that we do not support outside of boot services.
So let's patch out those bits already on the call to ExitBootServices, so that we can successfully run even when an OS chooses to omit any call to SetVirtualAddressMap.
Such an operating system would not be allowed to use any virtual addresses at any time because runtime drivers would not be informed about the mapping.
No. The OS would be permitted to invoke the runtime services at their original offset.
For arm64, this is trivially achievable, since we already use userland mappings for the runtime services. On 32-bit architectures, it is more complicated, since the boot time mapping of peripherals and/or memory may conflict with the kernel's layout of the address space (e.g., if your NOR flash lives above 0xc0000000, you *have* to remap it for the runtime services to be able to use it).
Does such an operating system exist? Or is this only a hypothetical case?
Reported-by: Ard Biesheuvel ard.biesheuvel@linaro.org Signed-off-by: Alexander Graf agraf@suse.de
I am missing a description of the side effects of the change, e.g.
Our EFI unit tests call the Reset() service.
So Python tests will fail on systems that do not implement Reset() in a runtime compatible manner.
All runtime services (except SetVirtualAddresMap() and ConvertPointer(), obviously) may be used at runtime with or without installing a virtual address mapping.
With this patch in place Travis CI testing fails:
After 'bootefi selftest' this output is not ejected: m = u_boot_console.p.expect(['resetting', 'U-Boot'])
And after the reset U-Boot crashes (observed for qemu-arm64_defconfig).
I just tried this out on the x86_64 variant. There reset does not occur, because at the point in time when we trigger the reset, ExitBootServices() has already been called. I would call that intentional - we patch the reset function away now because x86 doesn't provide an explicit efi enabled reset function.
The arm breakage is related to a missing icache flush. I'll fix that one up.
Thanks,
Alex