linux-kernel - Re: [PATCH] workqueue: rust: add creation of workqueues

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aAAKwTj9egoFdq6G@slm.duckdns.org>
Date: Wed, 16 Apr 2025 09:53:37 -1000
From: Tejun Heo <tj@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Tamir Duberstein <tamird@...il.com>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: rust: add creation of workqueues

Hello,

On Wed, Apr 16, 2025 at 12:17:48PM +0000, Alice Ryhl wrote:
...
> It looks like panthor handles this by only having a single delayed work
> item on each queue and using cancel_delayed_work_sync before calling
> destroy_workqueue.

That sounds a bit too restrictive.

> Tejun, what do you suggest? The goal of the Rust API is to make it
> impossible to accidentally trigger a UAF, so we need to design the API
> to prevent this mistake.

This is a hole in the C API, which isn't great but also not the end of the
world in C. I think it'd be best to solve this from C side rather than
working around it from rust side. e.g.:

- Have per-cpu list_head per workqueue (or system-wide).

- When queueing a delayed_work on timer, add the work item to the cpu's
  per-cpu list. This shouldn't need adding more fields to delayed_work given
  that the work part isn't being used yet. Also need to record the cpu.

- When timer expires, unlink from the per-cpu list and then do the normal
  queueing. This wil happen on the same cpu in most cases.

- Flush the lists from drain/destroy_workqueue(). If using system-wide
  per-cpu lists, we'd have to scan the lists and match the target wq.

This should be pretty cheap and we can probably enable this for everyone,
but if the overhead is noticeable, this can be an optional behavior
depending on a workqueue flag.

Thanks.

-- 
tejun