On Wed, Nov 02, 2022 at 10:08:28AM +0100, Ard Biesheuvel wrote: > On Fri, 28 Oct 2022 at 17:01, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > Unlike x86, which has machinery to deal with page faults that occur > > during the execution of EFI runtime services, arm64 has nothing like > > that, and a synchronous exception raised by firmware code brings down > > the whole system. > > > > With more EFI based systems appearing that were not built to run Linux > > (such as the Windows-on-ARM laptops based on Qualcomm SOCs), as well as > > the introduction of PRM (platform specific firmware routines that are > > callable just like EFI runtime services), we are more likely to run into > > issues of this sort, and it is much more likely that we can identify and > > work around such issues if they don't bring down the system entirely. > > > > Since we already use a EFI runtime services call wrapper in assembler, > > we can quite easily add some code that captures the execution state at > > the point where the call is made, allowing us to revert to this state > > and proceed execution if the call triggered a synchronous exception. > > > > Given that the kernel and the firmware don't share any data structures > > that could end up in an indeterminate state, we can happily continue > > running, as long as we mark the EFI runtime services as unavailable from > > that point on. > > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > Does anyone mind if I take this via the EFI tree for v6.1? No, feel free to take it. Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx>
