2014-06-26 18:09:05 +08:00
|
|
|
/*
|
|
|
|
|
* runtime-wrappers.c - Runtime Services function call wrappers
|
|
|
|
|
*
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
* Implementation summary:
|
|
|
|
|
* -----------------------
|
|
|
|
|
* 1. When user/kernel thread requests to execute efi_runtime_service(),
|
|
|
|
|
* enqueue work to efi_rts_wq.
|
|
|
|
|
* 2. Caller thread waits for completion until the work is finished
|
|
|
|
|
* because it's dependent on the return status and execution of
|
|
|
|
|
* efi_runtime_service().
|
|
|
|
|
* For instance, get_variable() and get_next_variable().
|
|
|
|
|
*
|
2014-06-26 18:09:05 +08:00
|
|
|
* Copyright (C) 2014 Linaro Ltd. <ard.biesheuvel@linaro.org>
|
|
|
|
|
*
|
|
|
|
|
* Split off from arch/x86/platform/efi/efi.c
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 1999 VA Linux Systems
|
|
|
|
|
* Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
|
|
|
|
|
* Copyright (C) 1999-2002 Hewlett-Packard Co.
|
|
|
|
|
* Copyright (C) 2005-2008 Intel Co.
|
|
|
|
|
* Copyright (C) 2013 SuSE Labs
|
|
|
|
|
*
|
|
|
|
|
* This file is released under the GPLv2.
|
|
|
|
|
*/
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
#define pr_fmt(fmt) "efi: " fmt
|
|
|
|
|
|
2014-08-05 00:16:00 +08:00
|
|
|
#include <linux/bug.h>
|
2014-06-26 18:09:05 +08:00
|
|
|
#include <linux/efi.h>
|
efi/runtime-wrappers: Detect firmware IRQ flag corruption
The UEFI spec allows runtime services to be called with interrupts
masked or unmasked, and if a runtime service function needs to mask
interrupts, it must restore the mask to its original state before
returning (i.e. from the PoV of the OS, this does not change across a
call). Firmware should never unmask exceptions, as these may then be
taken by the OS unexpectedly.
Unfortunately, some firmware has been seen to unmask IRQs (and
potentially other maskable exceptions) across runtime services calls,
leaving IRQ flags corrupted after returning from a runtime services
function call. This may be detected by the IRQ tracing code, but often
goes unnoticed, leaving a potentially disastrous bug hidden.
This patch detects when the IRQ flags are corrupted by an EFI runtime
services call, logging the call and specific corruption to the console.
While restoring the expected value of the flags is insufficient to avoid
problems, we do so to avoid redundant warnings from elsewhere (e.g. IRQ
tracing).
The set of bits in flags which we want to check is architecture-specific
(e.g. we want to check FIQ on arm64, but not the zero flag on x86), so
each arch must provide ARCH_EFI_IRQ_FLAGS_MASK to describe those. In the
absence of this mask, the check is a no-op, and we redundantly save the
flags twice, but that will be short-lived as subsequent patches
will implement this and remove the scaffolding.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-37-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:07:08 +08:00
|
|
|
#include <linux/irqflags.h>
|
2014-08-05 00:16:00 +08:00
|
|
|
#include <linux/mutex.h>
|
2016-07-16 03:36:31 +08:00
|
|
|
#include <linux/semaphore.h>
|
efi/runtime-wrappers: Detect firmware IRQ flag corruption
The UEFI spec allows runtime services to be called with interrupts
masked or unmasked, and if a runtime service function needs to mask
interrupts, it must restore the mask to its original state before
returning (i.e. from the PoV of the OS, this does not change across a
call). Firmware should never unmask exceptions, as these may then be
taken by the OS unexpectedly.
Unfortunately, some firmware has been seen to unmask IRQs (and
potentially other maskable exceptions) across runtime services calls,
leaving IRQ flags corrupted after returning from a runtime services
function call. This may be detected by the IRQ tracing code, but often
goes unnoticed, leaving a potentially disastrous bug hidden.
This patch detects when the IRQ flags are corrupted by an EFI runtime
services call, logging the call and specific corruption to the console.
While restoring the expected value of the flags is insufficient to avoid
problems, we do so to avoid redundant warnings from elsewhere (e.g. IRQ
tracing).
The set of bits in flags which we want to check is architecture-specific
(e.g. we want to check FIQ on arm64, but not the zero flag on x86), so
each arch must provide ARCH_EFI_IRQ_FLAGS_MASK to describe those. In the
absence of this mask, the check is a no-op, and we redundantly save the
flags twice, but that will be short-lived as subsequent patches
will implement this and remove the scaffolding.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-37-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:07:08 +08:00
|
|
|
#include <linux/stringify.h>
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
#include <linux/workqueue.h>
|
|
|
|
|
#include <linux/completion.h>
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
#include <asm/efi.h>
|
|
|
|
|
|
2016-06-25 15:20:27 +08:00
|
|
|
/*
|
|
|
|
|
* Wrap around the new efi_call_virt_generic() macros so that the
|
|
|
|
|
* code doesn't get too cluttered:
|
|
|
|
|
*/
|
|
|
|
|
#define efi_call_virt(f, args...) \
|
|
|
|
|
efi_call_virt_pointer(efi.systab->runtime, f, args)
|
|
|
|
|
#define __efi_call_virt(f, args...) \
|
|
|
|
|
__efi_call_virt_pointer(efi.systab->runtime, f, args)
|
|
|
|
|
|
2018-09-12 03:15:21 +08:00
|
|
|
struct efi_runtime_work efi_rts_work;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* efi_queue_work: Queue efi_runtime_service() and wait until it's done
|
|
|
|
|
* @rts: efi_runtime_service() function identifier
|
|
|
|
|
* @rts_arg<1-5>: efi_runtime_service() function arguments
|
|
|
|
|
*
|
|
|
|
|
* Accesses to efi_runtime_services() are serialized by a binary
|
|
|
|
|
* semaphore (efi_runtime_lock) and caller waits until the work is
|
|
|
|
|
* finished, hence _only_ one work is queued at a time and the caller
|
|
|
|
|
* thread waits for completion.
|
|
|
|
|
*/
|
|
|
|
|
#define efi_queue_work(_rts, _arg1, _arg2, _arg3, _arg4, _arg5) \
|
|
|
|
|
({ \
|
|
|
|
|
efi_rts_work.status = EFI_ABORTED; \
|
|
|
|
|
\
|
2018-09-12 03:15:22 +08:00
|
|
|
if (!efi_enabled(EFI_RUNTIME_SERVICES)) { \
|
|
|
|
|
pr_warn_once("EFI Runtime Services are disabled!\n"); \
|
|
|
|
|
goto exit; \
|
|
|
|
|
} \
|
|
|
|
|
\
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
init_completion(&efi_rts_work.efi_rts_comp); \
|
2018-11-15 01:55:40 +08:00
|
|
|
INIT_WORK(&efi_rts_work.work, efi_call_rts); \
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
efi_rts_work.arg1 = _arg1; \
|
|
|
|
|
efi_rts_work.arg2 = _arg2; \
|
|
|
|
|
efi_rts_work.arg3 = _arg3; \
|
|
|
|
|
efi_rts_work.arg4 = _arg4; \
|
|
|
|
|
efi_rts_work.arg5 = _arg5; \
|
|
|
|
|
efi_rts_work.efi_rts_id = _rts; \
|
|
|
|
|
\
|
|
|
|
|
/* \
|
|
|
|
|
* queue_work() returns 0 if work was already on queue, \
|
|
|
|
|
* _ideally_ this should never happen. \
|
|
|
|
|
*/ \
|
|
|
|
|
if (queue_work(efi_rts_wq, &efi_rts_work.work)) \
|
|
|
|
|
wait_for_completion(&efi_rts_work.efi_rts_comp); \
|
|
|
|
|
else \
|
|
|
|
|
pr_err("Failed to queue work to efi_rts_wq.\n"); \
|
|
|
|
|
\
|
2018-09-12 03:15:22 +08:00
|
|
|
exit: \
|
|
|
|
|
efi_rts_work.efi_rts_id = NONE; \
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
efi_rts_work.status; \
|
|
|
|
|
})
|
|
|
|
|
|
2016-06-25 15:20:27 +08:00
|
|
|
void efi_call_virt_check_flags(unsigned long flags, const char *call)
|
efi/runtime-wrappers: Detect firmware IRQ flag corruption
The UEFI spec allows runtime services to be called with interrupts
masked or unmasked, and if a runtime service function needs to mask
interrupts, it must restore the mask to its original state before
returning (i.e. from the PoV of the OS, this does not change across a
call). Firmware should never unmask exceptions, as these may then be
taken by the OS unexpectedly.
Unfortunately, some firmware has been seen to unmask IRQs (and
potentially other maskable exceptions) across runtime services calls,
leaving IRQ flags corrupted after returning from a runtime services
function call. This may be detected by the IRQ tracing code, but often
goes unnoticed, leaving a potentially disastrous bug hidden.
This patch detects when the IRQ flags are corrupted by an EFI runtime
services call, logging the call and specific corruption to the console.
While restoring the expected value of the flags is insufficient to avoid
problems, we do so to avoid redundant warnings from elsewhere (e.g. IRQ
tracing).
The set of bits in flags which we want to check is architecture-specific
(e.g. we want to check FIQ on arm64, but not the zero flag on x86), so
each arch must provide ARCH_EFI_IRQ_FLAGS_MASK to describe those. In the
absence of this mask, the check is a no-op, and we redundantly save the
flags twice, but that will be short-lived as subsequent patches
will implement this and remove the scaffolding.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-37-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-26 04:07:08 +08:00
|
|
|
{
|
|
|
|
|
unsigned long cur_flags, mismatch;
|
|
|
|
|
|
|
|
|
|
local_save_flags(cur_flags);
|
|
|
|
|
|
|
|
|
|
mismatch = flags ^ cur_flags;
|
|
|
|
|
if (!WARN_ON_ONCE(mismatch & ARCH_EFI_IRQ_FLAGS_MASK))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_NOW_UNRELIABLE);
|
|
|
|
|
pr_err_ratelimited(FW_BUG "IRQ flags corrupted (0x%08lx=>0x%08lx) by EFI %s\n",
|
|
|
|
|
flags, cur_flags, call);
|
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-05 00:16:00 +08:00
|
|
|
/*
|
|
|
|
|
* According to section 7.1 of the UEFI spec, Runtime Services are not fully
|
|
|
|
|
* reentrant, and there are particular combinations of calls that need to be
|
|
|
|
|
* serialized. (source: UEFI Specification v2.4A)
|
|
|
|
|
*
|
|
|
|
|
* Table 31. Rules for Reentry Into Runtime Services
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | If previous call is busy in | Forbidden to call |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | Any | SetVirtualAddressMap() |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | ConvertPointer() | ConvertPointer() |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | SetVariable() | ResetSystem() |
|
|
|
|
|
* | UpdateCapsule() | |
|
|
|
|
|
* | SetTime() | |
|
|
|
|
|
* | SetWakeupTime() | |
|
|
|
|
|
* | GetNextHighMonotonicCount() | |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | GetVariable() | GetVariable() |
|
|
|
|
|
* | GetNextVariableName() | GetNextVariableName() |
|
|
|
|
|
* | SetVariable() | SetVariable() |
|
|
|
|
|
* | QueryVariableInfo() | QueryVariableInfo() |
|
|
|
|
|
* | UpdateCapsule() | UpdateCapsule() |
|
|
|
|
|
* | QueryCapsuleCapabilities() | QueryCapsuleCapabilities() |
|
|
|
|
|
* | GetNextHighMonotonicCount() | GetNextHighMonotonicCount() |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
* | GetTime() | GetTime() |
|
|
|
|
|
* | SetTime() | SetTime() |
|
|
|
|
|
* | GetWakeupTime() | GetWakeupTime() |
|
|
|
|
|
* | SetWakeupTime() | SetWakeupTime() |
|
|
|
|
|
* +------------------------------------+-------------------------------+
|
|
|
|
|
*
|
|
|
|
|
* Due to the fact that the EFI pstore may write to the variable store in
|
2016-07-16 03:36:31 +08:00
|
|
|
* interrupt context, we need to use a lock for at least the groups that
|
2014-08-05 00:16:00 +08:00
|
|
|
* contain SetVariable() and QueryVariableInfo(). That leaves little else, as
|
|
|
|
|
* none of the remaining functions are actually ever called at runtime.
|
2016-07-16 03:36:31 +08:00
|
|
|
* So let's just use a single lock to serialize all Runtime Services calls.
|
2014-08-05 00:16:00 +08:00
|
|
|
*/
|
2016-07-16 03:36:31 +08:00
|
|
|
static DEFINE_SEMAPHORE(efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
/*
|
|
|
|
|
* Calls the appropriate efi_runtime_service() with the appropriate
|
|
|
|
|
* arguments.
|
|
|
|
|
*
|
|
|
|
|
* Semantics followed by efi_call_rts() to understand efi_runtime_work:
|
|
|
|
|
* 1. If argument was a pointer, recast it from void pointer to original
|
|
|
|
|
* pointer type.
|
|
|
|
|
* 2. If argument was a value, recast it from void pointer to original
|
|
|
|
|
* pointer type and dereference it.
|
|
|
|
|
*/
|
|
|
|
|
static void efi_call_rts(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
void *arg1, *arg2, *arg3, *arg4, *arg5;
|
|
|
|
|
efi_status_t status = EFI_NOT_FOUND;
|
|
|
|
|
|
2018-09-12 03:15:21 +08:00
|
|
|
arg1 = efi_rts_work.arg1;
|
|
|
|
|
arg2 = efi_rts_work.arg2;
|
|
|
|
|
arg3 = efi_rts_work.arg3;
|
|
|
|
|
arg4 = efi_rts_work.arg4;
|
|
|
|
|
arg5 = efi_rts_work.arg5;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
|
2018-09-12 03:15:21 +08:00
|
|
|
switch (efi_rts_work.efi_rts_id) {
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
case GET_TIME:
|
|
|
|
|
status = efi_call_virt(get_time, (efi_time_t *)arg1,
|
|
|
|
|
(efi_time_cap_t *)arg2);
|
|
|
|
|
break;
|
|
|
|
|
case SET_TIME:
|
|
|
|
|
status = efi_call_virt(set_time, (efi_time_t *)arg1);
|
|
|
|
|
break;
|
|
|
|
|
case GET_WAKEUP_TIME:
|
|
|
|
|
status = efi_call_virt(get_wakeup_time, (efi_bool_t *)arg1,
|
|
|
|
|
(efi_bool_t *)arg2, (efi_time_t *)arg3);
|
|
|
|
|
break;
|
|
|
|
|
case SET_WAKEUP_TIME:
|
|
|
|
|
status = efi_call_virt(set_wakeup_time, *(efi_bool_t *)arg1,
|
|
|
|
|
(efi_time_t *)arg2);
|
|
|
|
|
break;
|
|
|
|
|
case GET_VARIABLE:
|
|
|
|
|
status = efi_call_virt(get_variable, (efi_char16_t *)arg1,
|
|
|
|
|
(efi_guid_t *)arg2, (u32 *)arg3,
|
|
|
|
|
(unsigned long *)arg4, (void *)arg5);
|
|
|
|
|
break;
|
|
|
|
|
case GET_NEXT_VARIABLE:
|
|
|
|
|
status = efi_call_virt(get_next_variable, (unsigned long *)arg1,
|
|
|
|
|
(efi_char16_t *)arg2,
|
|
|
|
|
(efi_guid_t *)arg3);
|
|
|
|
|
break;
|
|
|
|
|
case SET_VARIABLE:
|
|
|
|
|
status = efi_call_virt(set_variable, (efi_char16_t *)arg1,
|
|
|
|
|
(efi_guid_t *)arg2, *(u32 *)arg3,
|
|
|
|
|
*(unsigned long *)arg4, (void *)arg5);
|
|
|
|
|
break;
|
|
|
|
|
case QUERY_VARIABLE_INFO:
|
|
|
|
|
status = efi_call_virt(query_variable_info, *(u32 *)arg1,
|
|
|
|
|
(u64 *)arg2, (u64 *)arg3, (u64 *)arg4);
|
|
|
|
|
break;
|
|
|
|
|
case GET_NEXT_HIGH_MONO_COUNT:
|
|
|
|
|
status = efi_call_virt(get_next_high_mono_count, (u32 *)arg1);
|
|
|
|
|
break;
|
|
|
|
|
case UPDATE_CAPSULE:
|
|
|
|
|
status = efi_call_virt(update_capsule,
|
|
|
|
|
(efi_capsule_header_t **)arg1,
|
|
|
|
|
*(unsigned long *)arg2,
|
|
|
|
|
*(unsigned long *)arg3);
|
|
|
|
|
break;
|
|
|
|
|
case QUERY_CAPSULE_CAPS:
|
|
|
|
|
status = efi_call_virt(query_capsule_caps,
|
|
|
|
|
(efi_capsule_header_t **)arg1,
|
|
|
|
|
*(unsigned long *)arg2, (u64 *)arg3,
|
|
|
|
|
(int *)arg4);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/*
|
|
|
|
|
* Ideally, we should never reach here because a caller of this
|
|
|
|
|
* function should have put the right efi_runtime_service()
|
|
|
|
|
* function identifier into efi_rts_work->efi_rts_id
|
|
|
|
|
*/
|
|
|
|
|
pr_err("Requested executing invalid EFI Runtime Service.\n");
|
|
|
|
|
}
|
2018-09-12 03:15:21 +08:00
|
|
|
efi_rts_work.status = status;
|
|
|
|
|
complete(&efi_rts_work.efi_rts_comp);
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
}
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(GET_TIME, tm, tc, NULL, NULL, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-06-26 18:09:05 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_set_time(efi_time_t *tm)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(SET_TIME, tm, NULL, NULL, NULL, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-06-26 18:09:05 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_get_wakeup_time(efi_bool_t *enabled,
|
|
|
|
|
efi_bool_t *pending,
|
|
|
|
|
efi_time_t *tm)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(GET_WAKEUP_TIME, enabled, pending, tm, NULL,
|
|
|
|
|
NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-06-26 18:09:05 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(SET_WAKEUP_TIME, &enabled, tm, NULL, NULL,
|
|
|
|
|
NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-06-26 18:09:05 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_get_variable(efi_char16_t *name,
|
|
|
|
|
efi_guid_t *vendor,
|
|
|
|
|
u32 *attr,
|
|
|
|
|
unsigned long *data_size,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(GET_VARIABLE, name, vendor, attr, data_size,
|
|
|
|
|
data);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
|
|
|
|
|
efi_char16_t *name,
|
|
|
|
|
efi_guid_t *vendor)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(GET_NEXT_VARIABLE, name_size, name, vendor,
|
|
|
|
|
NULL, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_set_variable(efi_char16_t *name,
|
|
|
|
|
efi_guid_t *vendor,
|
|
|
|
|
u32 attr,
|
|
|
|
|
unsigned long data_size,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(SET_VARIABLE, name, vendor, &attr, &data_size,
|
|
|
|
|
data);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
2014-10-01 04:58:52 +08:00
|
|
|
static efi_status_t
|
|
|
|
|
virt_efi_set_variable_nonblocking(efi_char16_t *name, efi_guid_t *vendor,
|
|
|
|
|
u32 attr, unsigned long data_size,
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_trylock(&efi_runtime_lock))
|
2014-10-01 04:58:52 +08:00
|
|
|
return EFI_NOT_READY;
|
|
|
|
|
|
|
|
|
|
status = efi_call_virt(set_variable, name, vendor, attr, data_size,
|
|
|
|
|
data);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-10-01 04:58:52 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
static efi_status_t virt_efi_query_variable_info(u32 attr,
|
|
|
|
|
u64 *storage_space,
|
|
|
|
|
u64 *remaining_space,
|
|
|
|
|
u64 *max_variable_size)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
|
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(QUERY_VARIABLE_INFO, &attr, storage_space,
|
|
|
|
|
remaining_space, max_variable_size, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
2016-02-02 06:06:57 +08:00
|
|
|
static efi_status_t
|
|
|
|
|
virt_efi_query_variable_info_nonblocking(u32 attr,
|
|
|
|
|
u64 *storage_space,
|
|
|
|
|
u64 *remaining_space,
|
|
|
|
|
u64 *max_variable_size)
|
|
|
|
|
{
|
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
|
|
if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
|
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_trylock(&efi_runtime_lock))
|
2016-02-02 06:06:57 +08:00
|
|
|
return EFI_NOT_READY;
|
|
|
|
|
|
|
|
|
|
status = efi_call_virt(query_variable_info, attr, storage_space,
|
|
|
|
|
remaining_space, max_variable_size);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2016-02-02 06:06:57 +08:00
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
static efi_status_t virt_efi_get_next_high_mono_count(u32 *count)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(GET_NEXT_HIGH_MONO_COUNT, count, NULL, NULL,
|
|
|
|
|
NULL, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void virt_efi_reset_system(int reset_type,
|
|
|
|
|
efi_status_t status,
|
|
|
|
|
unsigned long data_size,
|
|
|
|
|
efi_char16_t *data)
|
|
|
|
|
{
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock)) {
|
|
|
|
|
pr_warn("failed to invoke the reset_system() runtime service:\n"
|
|
|
|
|
"could not get exclusive access to the firmware\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2018-09-12 03:15:22 +08:00
|
|
|
efi_rts_work.efi_rts_id = RESET_SYSTEM;
|
2014-06-26 18:09:05 +08:00
|
|
|
__efi_call_virt(reset_system, reset_type, status, data_size, data);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_update_capsule(efi_capsule_header_t **capsules,
|
|
|
|
|
unsigned long count,
|
|
|
|
|
unsigned long sg_list)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
|
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(UPDATE_CAPSULE, capsules, &count, &sg_list,
|
|
|
|
|
NULL, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules,
|
|
|
|
|
unsigned long count,
|
|
|
|
|
u64 *max_size,
|
|
|
|
|
int *reset_type)
|
|
|
|
|
{
|
2014-08-05 00:16:00 +08:00
|
|
|
efi_status_t status;
|
|
|
|
|
|
2014-06-26 18:09:05 +08:00
|
|
|
if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
|
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
|
2016-07-16 03:36:31 +08:00
|
|
|
if (down_interruptible(&efi_runtime_lock))
|
|
|
|
|
return EFI_ABORTED;
|
efi: Use a work queue to invoke EFI Runtime Services
Presently, when a user process requests the kernel to execute any
UEFI runtime service, the kernel temporarily switches to a separate
set of page tables that describe the virtual mapping of the UEFI
runtime services regions in memory. Since UEFI runtime services are
typically invoked with interrupts enabled, any code that may be called
during this time, will have an incorrect view of the process's address
space. Although it is unusual for code running in interrupt context to
make assumptions about the process context it runs in, there are cases
(such as the perf subsystem taking samples) where this causes problems.
So let's set up a work queue for calling UEFI runtime services, so that
the actual calls are made when the work queue items are dispatched by a
work queue worker running in a separate kernel thread. Such threads are
not expected to have userland mappings in the first place, and so the
additional mappings created for the UEFI runtime services can never
clash with any.
The ResetSystem() runtime service is not covered by the work queue
handling, since it is not expected to return, and may be called at a
time when the kernel is torn down to the point where we cannot expect
work queues to still be operational.
The non-blocking variants of SetVariable() and QueryVariableInfo()
are also excluded: these are intended to be used from atomic context,
which obviously rules out waiting for a completion to be signalled by
another thread. Note that these variants are currently only used for
UEFI runtime services calls that occur very early in the boot, and
for ones that occur in critical conditions, e.g., to flush kernel logs
to UEFI variables via efi-pstore.
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
[ardb: exclude ResetSystem() from the workqueue treatment
merge from 2 separate patches and rewrite commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:35 +08:00
|
|
|
status = efi_queue_work(QUERY_CAPSULE_CAPS, capsules, &count,
|
|
|
|
|
max_size, reset_type, NULL);
|
2016-07-16 03:36:31 +08:00
|
|
|
up(&efi_runtime_lock);
|
2014-08-05 00:16:00 +08:00
|
|
|
return status;
|
2014-06-26 18:09:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void efi_native_runtime_setup(void)
|
|
|
|
|
{
|
|
|
|
|
efi.get_time = virt_efi_get_time;
|
|
|
|
|
efi.set_time = virt_efi_set_time;
|
|
|
|
|
efi.get_wakeup_time = virt_efi_get_wakeup_time;
|
|
|
|
|
efi.set_wakeup_time = virt_efi_set_wakeup_time;
|
|
|
|
|
efi.get_variable = virt_efi_get_variable;
|
|
|
|
|
efi.get_next_variable = virt_efi_get_next_variable;
|
|
|
|
|
efi.set_variable = virt_efi_set_variable;
|
2014-10-01 04:58:52 +08:00
|
|
|
efi.set_variable_nonblocking = virt_efi_set_variable_nonblocking;
|
2014-06-26 18:09:05 +08:00
|
|
|
efi.get_next_high_mono_count = virt_efi_get_next_high_mono_count;
|
|
|
|
|
efi.reset_system = virt_efi_reset_system;
|
|
|
|
|
efi.query_variable_info = virt_efi_query_variable_info;
|
2016-02-02 06:06:57 +08:00
|
|
|
efi.query_variable_info_nonblocking = virt_efi_query_variable_info_nonblocking;
|
2014-06-26 18:09:05 +08:00
|
|
|
efi.update_capsule = virt_efi_update_capsule;
|
|
|
|
|
efi.query_capsule_caps = virt_efi_query_capsule_caps;
|
|
|
|
|
}
|
