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 for Android: free password hash cracker in your pocket

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

Message-ID: <aYn6j_JLBENcY96V@redhat.com>
Date: Mon, 9 Feb 2026 12:17:35 -0300
From: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev, Ard Biesheuvel <ardb@...nel.org>,
	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

On Thu, Feb 05, 2026 at 12:55:57PM +0100, 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. 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.

I ran tests on two aarch64 boxes and two x86_64 boxes. I ran timerlat on a
set of isolated CPUs (10-30) and serviced the EFI Runtime requests on CPU4.
During the tests I ran operations such as df, efibootmgr, read individual
EFIvars and performed read/write ops to the boxes using efi-rtc. All that,
at regular intervals during the test duration.

I had previously checked the interference/latency generated by these
operations on each box, so I knew what to look for in terms of expected
latency spikes.

On the aarch64 boxes the impact of the EFI-related requests was confined to
CPU4, as expected, and no apparent noise was recorded on the isolated CPUs.

In one of the x86_64 boxes the noise also seemed to be contained to CPU4.
The other box gave me the impression that SMIs were being triggered by the
EFI runtime requests and that was affecting all the CPUs. I will explore
a bit more both x86_64 cases, but I am more than satisfied with the results
of the proposed patches.

Sebastian, as for the TEE feature you mentioned, is there specific test I
should run? Or is there any test you would like me to run in the context of
this change?

In any case,

Tested-by: Luis Claudio R. Goncalves <lgoncalv@...hat.com>

 
> 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
> 
---end quoted text---