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 <[email protected]> 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 <[email protected]> >>>> Signed-off-by: Alexander Graf <[email protected]> >>> >>> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
