2019-06-04 08:11:33 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2018-03-08 08:00:13 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2018 Linaro Ltd <ard.biesheuvel@linaro.org>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/linkage.h>
|
2023-01-09 11:41:46 +00:00
|
|
|
#include <asm/assembler.h>
|
2018-03-08 08:00:13 +00:00
|
|
|
|
2020-05-01 11:54:29 +00:00
|
|
|
SYM_FUNC_START(__efi_rt_asm_wrapper)
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
stp x29, x30, [sp, #-112]!
|
2018-03-08 08:00:13 +00:00
|
|
|
mov x29, sp
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Register x18 is designated as the 'platform' register by the AAPCS,
|
|
|
|
|
* which means firmware running at the same exception level as the OS
|
|
|
|
|
* (such as UEFI) should never touch it.
|
|
|
|
|
*/
|
|
|
|
|
stp x1, x18, [sp, #16]
|
|
|
|
|
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
/*
|
|
|
|
|
* Preserve all callee saved registers and preserve the stack pointer
|
|
|
|
|
* value at the base of the EFI runtime stack so we can recover from
|
|
|
|
|
* synchronous exceptions occurring while executing the firmware
|
|
|
|
|
* routines.
|
|
|
|
|
*/
|
|
|
|
|
stp x19, x20, [sp, #32]
|
|
|
|
|
stp x21, x22, [sp, #48]
|
|
|
|
|
stp x23, x24, [sp, #64]
|
|
|
|
|
stp x25, x26, [sp, #80]
|
|
|
|
|
stp x27, x28, [sp, #96]
|
|
|
|
|
|
2022-12-05 10:31:25 +00:00
|
|
|
ldr_l x16, efi_rt_stack_top
|
|
|
|
|
mov sp, x16
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
stp x18, x29, [sp, #-16]!
|
2022-12-05 10:31:25 +00:00
|
|
|
|
2018-03-08 08:00:13 +00:00
|
|
|
/*
|
|
|
|
|
* We are lucky enough that no EFI runtime services take more than
|
|
|
|
|
* 5 arguments, so all are passed in registers rather than via the
|
|
|
|
|
* stack.
|
|
|
|
|
*/
|
|
|
|
|
mov x8, x0
|
|
|
|
|
mov x0, x2
|
|
|
|
|
mov x1, x3
|
|
|
|
|
mov x2, x4
|
|
|
|
|
mov x3, x5
|
|
|
|
|
mov x4, x6
|
|
|
|
|
blr x8
|
|
|
|
|
|
2022-10-28 14:39:14 +00:00
|
|
|
mov x16, sp
|
2022-12-05 10:31:25 +00:00
|
|
|
mov sp, x29
|
2022-10-28 14:39:14 +00:00
|
|
|
str xzr, [x16, #8] // clear recorded task SP value
|
|
|
|
|
|
2018-03-08 08:00:13 +00:00
|
|
|
ldp x1, x2, [sp, #16]
|
|
|
|
|
cmp x2, x18
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
ldp x29, x30, [sp], #112
|
2018-03-08 08:00:13 +00:00
|
|
|
b.ne 0f
|
|
|
|
|
ret
|
2020-04-27 16:00:13 +00:00
|
|
|
0:
|
|
|
|
|
/*
|
|
|
|
|
* With CONFIG_SHADOW_CALL_STACK, the kernel uses x18 to store a
|
|
|
|
|
* shadow stack pointer, which we need to restore before returning to
|
|
|
|
|
* potentially instrumented code. This is safe because the wrapper is
|
|
|
|
|
* called with preemption disabled and a separate shadow stack is used
|
|
|
|
|
* for interrupts.
|
|
|
|
|
*/
|
2022-12-05 10:31:25 +00:00
|
|
|
#ifdef CONFIG_SHADOW_CALL_STACK
|
|
|
|
|
ldr_l x18, efi_rt_stack_top
|
|
|
|
|
ldr x18, [x18, #-16]
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-04-27 16:00:13 +00:00
|
|
|
b efi_handle_corrupted_x18 // tail call
|
2020-05-01 11:54:29 +00:00
|
|
|
SYM_FUNC_END(__efi_rt_asm_wrapper)
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
|
|
|
|
|
SYM_CODE_START(__efi_rt_asm_recover)
|
|
|
|
|
mov sp, x30
|
|
|
|
|
|
2022-10-28 14:39:14 +00:00
|
|
|
ldr_l x16, efi_rt_stack_top // clear recorded task SP value
|
|
|
|
|
str xzr, [x16, #-8]
|
|
|
|
|
|
arm64: efi: Recover from synchronous exceptions occurring in firmware
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@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-10-28 14:39:14 +00:00
|
|
|
ldp x19, x20, [sp, #32]
|
|
|
|
|
ldp x21, x22, [sp, #48]
|
|
|
|
|
ldp x23, x24, [sp, #64]
|
|
|
|
|
ldp x25, x26, [sp, #80]
|
|
|
|
|
ldp x27, x28, [sp, #96]
|
|
|
|
|
ldp x29, x30, [sp], #112
|
|
|
|
|
ret
|
|
|
|
|
SYM_CODE_END(__efi_rt_asm_recover)
|