[PATCH v2 1/2] landlock: Multithreading support for landlock_restrict_self()

[Jann Horn]

On Mon, Oct 20, 2025 at 10:12 PM Mickaël Salaün <mic at digikod.net> wrote:
> On Wed, Oct 01, 2025 at 01:18:06PM +0200, Günther Noack wrote:
> > +
> > +             /*
> > +              * Decrement num_preparing for current, to undo that we
> > +              * initialized it to 1 at the beginning of the inner loop.
> > +              */
> > +             if (atomic_dec_return(&shared_ctx.num_preparing) > 0)
> > +                     wait_for_completion(&shared_ctx.all_prepared);
> > +     } while (found_more_threads &&
> > +              !atomic_read(&shared_ctx.preparation_error));
>
> Is it safe to prevent inconsistencies wrt execve?  seccomp uses
> cred_guard_mutex (new code should probably use exec_update_lock), why
> should Landlock not do the same?

We don't have to worry about interactions with execve because, unlike
seccomp, we don't directly change properties of another running
thread; we ask other threads to change their credentials _themselves_.
>From a locking context, restrict_one_thread() essentially runs in the
same kind of context as a syscall, and doesn't need any more locking
than the existing landlock_restrict_self().

> Why shouldn't we lock sighand as well?

seccomp uses siglock for the following reasons:

1. to protect against concurrent access to one thread's seccomp filter
information from multiple threads; we don't do anything like that
2. to protect the for_each_thread() loop; we use RCU for that (we
could also use siglock but there's no reason to do that, and RCU is
more lightweight than the siglock which requires disabling interrupts)
3. to ensure that threads' seccomp states don't change between its two
loops over other threads (seccomp_can_sync_threads() and
seccomp_sync_threads()); we don't do anything like that