linux-kernel - [PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260205115559.1625236-1-bigeasy@linutronix.de>
Date: Thu,  5 Feb 2026 12:55:57 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev
Cc: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	John Ogness <john.ogness@...utronix.de>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Tejun Heo <tj@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: [PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs

EFI runtime services are disabled on PREEMPT_RT by default which can be
overwritten on the boot command line. For native EFI, an invocation
requires to disable preemption while a call is made into EFI. The time
spent in EFI is not deterministic and depends on SW and HW of the
system.
While accessing the efi-rtc device can be avoided by using a native
driver, accessing the "variables" is important and there is no second
path.

The "runtime-wrappers" is wrapping access to the EFI callback via a
workqueue. On a SMP system one CPU could be declared as housekeeping/
not-realtime-capable and force all EFI invocation to be performed on
this CPU. This could be achieved by setting workqueue.unbound_cpus or
	/sys/devices/virtual/workqueue/cpumask

at runtime. This however will affect all workqueues and might not be
desired. With an explicit setting such as
	/sys/devices/virtual/workqueue/efi_runtime/cpumask

it looks like an official way to limit the CPUs involved here.

With this in place I was wondering if EFI_DISABLE_RUNTIME could be
lifted at runtime on SMP systems. But given the unbound_cpus option
and the auto-config based on NOHZ-full it might not be wise to add yet
another smart option here. Also it needs to be a subset of root cpumask
or it won't be effective.

There are two EFI invocations which are not covered by this
- mixed EFI
  Used on x86 with 64bit kernel but 32bit EFI. Would it work to use here
  the same workqueue mechanism?

- TEE / ARM secure monitor
  If I understand this right then TEE invokes the secure monitor which
  is preemptible. So an interrupt will interrupt and enter "normal"
  world immediately and could wake a user task. The following context
  switch will not happen because the return from interrupt path goes
  back to the secure monitor/ TEE.
  If so, or if TEE may disable interrupts from normal world, would it
  make sense to use a wrapper here, too?

Any comments or things I have missed?

Sebastian

Sebastian Andrzej Siewior (2):
  workqueue: Allow to expose ordered workqueues via sysfs
  efi: Allow to expose the workqueue via sysfs

 drivers/firmware/efi/efi.c |  2 +-
 kernel/workqueue.c         | 14 +++++++-------
 2 files changed, 8 insertions(+), 8 deletions(-)

-- 
2.51.0