linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Message-Id: <4c6a5533-6fcd-4237-bb35-0ca74029c7db@app.fastmail.com>
Date: Mon, 09 Feb 2026 18:10:52 +0100
From: "Ard Biesheuvel" <ardb@...nel.org>
To: "Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
 linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-rt-devel@...ts.linux.dev
Cc: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
 "John Ogness" <john.ogness@...utronix.de>,
 "Lai Jiangshan" <jiangshanlai@...il.com>, "Tejun Heo" <tj@...nel.org>
Subject: Re: [PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs

Hello Sebastian,

On Thu, 5 Feb 2026, at 12:55, Sebastian Andrzej Siewior wrote:
> 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.

This is no longer true on arm64 since

commit a5baf582f4c026c25a206ac121bceade926aec74
Author: Ard Biesheuvel <ardb@...nel.org>
Date:   Wed Oct 15 22:56:42 2025 +0200

    arm64/efi: Call EFI runtime services without disabling preemption

except for some corner cases (reboot, pstore crash dump).

> 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?
>

That stuff is beyond obsolete, so I don't think it is relevant for RT.

> - 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(-)
>

Acked-by: Ard Biesheuvel <ardb@...nel.org>