Re: [PATCH v3 0/2] efi: Follow-up fixes for EFI runtime stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 9 Jan 2023 at 11:38, Lee Jones <lee@xxxxxxxxxx> wrote:
>
> On Fri, 06 Jan 2023, Ard Biesheuvel wrote:
>
> > Commit ff7a167961d1b ("arm64: efi: Execute runtime services from a
> > dedicated stack") introduced a dedicated stack for EFI runtime services,
> > in an attempt to make the execution of EFI runtime services more robust,
> > given that they execute at the same privilege level as the kernel.
> >
> > However, this stack needs to be declared to the stacktrace machinery,
> > which is careful not to walk the stack when it leads into memory regions
> > that are not known to be allocated for stack use.
> >
> > Also, given that the ACPI code may invoke the low-level EFI runtime call
> > wrapper without using the dedicated kernel thread and workqueue, we
> > should take this into account when trying to gracefully handle
> > synchronous exceptions.
> >
> > Changes since v2:
> > - clear efi_rt_stack_top[-1] from asm code, and use READ_ONCE() to read
> >   its value when not holding the spinlock, to ensure that all accesses
> >   are safe under concurrency;
> > - add Mark's ack to patch #2
> >
> > Cc: Mark Rutland <mark.rutland@xxxxxxx>
> > Cc: Lee Jones <lee@xxxxxxxxxx>
> >
> > Ard Biesheuvel (2):
> >   arm64: efi: Avoid workqueue to check whether EFI runtime is live
> >   arm64: efi: Account for the EFI runtime stack in stack unwinder
>
> Should either / both of these be routed to Stable?
>
> If so, we should probably Cc: them.
>

I'll forward them to -stable by hand once all the bits and pieces land
in Linus's tree.

Feel free to remind in a week or so, though.

Thanks,
Ard.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux