* Re: [RFC PATCH 2/2] landlock: transpose the layer masks data structure
From: Mickaël Salaün @ 2026-01-09 16:18 UTC (permalink / raw)
To: Günther Noack
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze
In-Reply-To: <20251230103917.10549-7-gnoack3000@gmail.com>
This looks good overall but I need to spend more time reviewing it.
Because this changes may impact other ongoing patch series, I think I'll
take this patch first to ease potential future fix backports.
On Tue, Dec 30, 2025 at 11:39:21AM +0100, Günther Noack wrote:
> The layer masks data structure tracks the requested but unfulfilled
> access rights during an operations security check. It stores one bit
> for each combination of access right and layer index. If the bit is
> set, that access right is not granted (yet) in the given layer and we
> have to traverse the path further upwards to grant it.
>
> Previously, the layer masks were stored as arrays mapping from access
> right indices to layer_mask_t. The layer_mask_t value then indicates
> all layers in which the given access right is still (tentatively)
> denied.
>
> This patch introduces struct layer_access_masks instead: This struct
> contains an array with the access_mask_t of each (tentatively) denied
> access right in that layer.
>
> The hypothesis of this patch is that this simplifies the code enough
> so that the resulting code will run faster:
>
> * We can use bitwise operations in multiple places where we previously
> looped over bits individually with macros. (Should require less
> branch speculation)
>
> * Code is ~160 lines smaller.
What about the KUnit test lines?
>
> Other noteworthy changes:
>
> * Clarify deny_mask_t and the code assembling it.
> * Document what that value looks like
> * Make writing and reading functions specific to file system rules.
> (It only worked for FS rules before as well, but going all the way
> simplifies the code logic more.)
> * In no_more_access(), call a new helper function may_refer(), which
> only solves the asymmetric case. Previously, the code interleaved
> the checks for the two symmetric cases in RENAME_EXCHANGE. It feels
> that the code is clearer when renames without RENAME_EXCHANGE are
> more obviously the normal case.
It would be interesting to check the stackframe diff. You can use
scripts/stackdelta for that, see
https://git.kernel.org/mic/c/602acfb541195eb35584d7a3fc7d1db676f059bd
>
> Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> ---
> security/landlock/access.h | 10 +-
> security/landlock/audit.c | 155 ++++++----------
> security/landlock/audit.h | 3 +-
> security/landlock/domain.c | 120 +++----------
> security/landlock/domain.h | 6 +-
> security/landlock/fs.c | 350 ++++++++++++++++--------------------
> security/landlock/net.c | 10 +-
> security/landlock/ruleset.c | 78 +++-----
> security/landlock/ruleset.h | 18 +-
> 9 files changed, 290 insertions(+), 460 deletions(-)
> diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
> index dfcdc19ea2683..d20e28d38e9c9 100644
> --- a/security/landlock/ruleset.c
> +++ b/security/landlock/ruleset.c
> @@ -622,49 +622,24 @@ landlock_find_rule(const struct landlock_ruleset *const ruleset,
> * request are empty).
> */
> bool landlock_unmask_layers(const struct landlock_rule *const rule,
> - const access_mask_t access_request,
> - layer_mask_t (*const layer_masks)[],
> - const size_t masks_array_size)
> + struct layer_access_masks *masks)
> {
> - size_t layer_level;
> -
> - if (!access_request || !layer_masks)
> + if (!masks)
> return true;
> if (!rule)
> return false;
>
> - /*
> - * An access is granted if, for each policy layer, at least one rule
> - * encountered on the pathwalk grants the requested access,
> - * regardless of its position in the layer stack. We must then check
> - * the remaining layers for each inode, from the first added layer to
> - * the last one. When there is multiple requested accesses, for each
> - * policy layer, the full set of requested accesses may not be granted
> - * by only one rule, but by the union (binary OR) of multiple rules.
> - * E.g. /a/b <execute> + /a <read> => /a/b <execute + read>
> - */
Why removing this comment?
> - for (layer_level = 0; layer_level < rule->num_layers; layer_level++) {
> - const struct landlock_layer *const layer =
> - &rule->layers[layer_level];
> - const layer_mask_t layer_bit = BIT_ULL(layer->level - 1);
> - const unsigned long access_req = access_request;
> - unsigned long access_bit;
> - bool is_empty;
> + for (int i = 0; i < rule->num_layers; i++) {
> + const struct landlock_layer *l = &rule->layers[i];
>
> - /*
> - * Records in @layer_masks which layer grants access to each requested
> - * access: bit cleared if the related layer grants access.
> - */
> - is_empty = true;
> - for_each_set_bit(access_bit, &access_req, masks_array_size) {
> - if (layer->access & BIT_ULL(access_bit))
> - (*layer_masks)[access_bit] &= ~layer_bit;
> - is_empty = is_empty && !(*layer_masks)[access_bit];
> - }
> - if (is_empty)
> - return true;
> + masks->access[l->level - 1] &= ~l->access;
> }
> - return false;
> +
> + for (int i = 0; i < LANDLOCK_MAX_NUM_LAYERS; i++) {
> + if (masks->access[i])
> + return false;
> + }
> + return true;
> }
>
> typedef access_mask_t
^ permalink raw reply
* Re: [RFC PATCH 1/2] landlock: access_mask_subset() helper
From: Mickaël Salaün @ 2026-01-09 16:06 UTC (permalink / raw)
To: Günther Noack
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze
In-Reply-To: <20251230103917.10549-5-gnoack3000@gmail.com>
On Tue, Dec 30, 2025 at 11:39:19AM +0100, Günther Noack wrote:
> This helper function checks whether an access_mask_t has a subset of the
> bits enabled than another one. This expresses the intent a bit smoother
> in the code and does not cost us anything when it gets inlined.
>
> Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> ---
> security/landlock/fs.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index fe794875ad461..b4ce03bef4b8e 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -398,6 +398,15 @@ static const struct access_masks any_fs = {
> .fs = ~0,
> };
>
> +/*
> + * Returns true iff a has a subset of the bits of b.
> + * It helps readability and gets inlined.
> + */
> +static bool access_mask_subset(access_mask_t a, access_mask_t b)
> +{
> + return (a | b) == b;
I'm curious about why this switches to a binary OR instead of the
original AND.
> +}
> +
> /*
> * Check that a destination file hierarchy has more restrictions than a source
> * file hierarchy. This is only used for link and rename actions.
> @@ -1696,7 +1705,7 @@ static int hook_file_open(struct file *const file)
> ARRAY_SIZE(layer_masks));
> #endif /* CONFIG_AUDIT */
>
> - if ((open_access_request & allowed_access) == open_access_request)
> + if (access_mask_subset(open_access_request, allowed_access))
> return 0;
>
> /* Sets access to reflect the actual request. */
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] landlock: Refactor layer masks
From: Mickaël Salaün @ 2026-01-09 15:59 UTC (permalink / raw)
To: Günther Noack
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze
In-Reply-To: <20251230.d4bf391b98c5@gnoack.org>
On Tue, Dec 30, 2025 at 11:48:21AM +0100, Günther Noack wrote:
> On Tue, Dec 30, 2025 at 11:39:17AM +0100, Günther Noack wrote:
> > Tentative results with and without this patch set show that the
> > hypothesis likely holds true. The benchmark I used exercises a "worst
> > case" scenario that attempts to be bottlenecked on the affected code:
> > constructs a large number of nested directories, with one "path
> > beneath" rule each and then tries to open the innermost directory many
> > times. The benchmark is intentionally unrealistic to amplify the
> > amount of time used for the path walk logic and forces Landlock to
> > walk the full path (eventually failing the open syscall). (I'll send
> > the benchmark program in a reply to this mail for full transparency.)
>
> Please see the benchmark program below.
Thanks for the investigation!
>
> To compile it, use:
>
> cc -o benchmark_worsecase benchmark_worsecase.c
It would be useful to clean up a bit this benchmark and add it to the
selftests' Landlock directory (see seccomp_benchmark.c).
>
> Source code:
>
> ```
> #define _GNU_SOURCE
> #include <err.h>
> #include <fcntl.h>
> #include <linux/landlock.h>
> #include <stdbool.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/prctl.h>
> #include <sys/stat.h>
> #include <sys/syscall.h>
> #include <sys/times.h>
> #include <time.h>
> #include <unistd.h>
>
> /* Flags */
> bool use_landlock = true;
> size_t num_iterations = 100000;
> size_t num_subdirs = 10000;
>
> void usage() { puts("Usage: benchmark_worstcase [-no-landlock]"); }
>
> /*
> * Build a deep directory, enforce Landlock and return the FD to the
> * deepest dir. On any failure, exit the process with an error.
> */
> int build_directory(size_t depth) {
> const char *path = "d"; /* directory name */
>
> if (use_landlock) {
> int abi = syscall(SYS_landlock_create_ruleset, NULL, 0,
> LANDLOCK_CREATE_RULESET_VERSION);
> if (abi < 7)
> err(1, "Landlock ABI too low: got %d, wanted 7+", abi);
> }
>
> int ruleset_fd = -1;
> if (use_landlock) {
> if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0)
> err(1, "prctl");
>
> struct landlock_ruleset_attr attr = {
> .handled_access_fs = 0xffff, /* All FS access rights as of 2025-12 */
> };
> ruleset_fd = syscall(SYS_landlock_create_ruleset, &attr, sizeof(attr), 0U);
> if (ruleset_fd < 0)
> err(1, "landlock_create_ruleset");
> }
>
> int current = open(".", O_PATH);
> if (current < 0)
> err(1, "open(.)");
>
> while (depth--) {
> if (use_landlock) {
> struct landlock_path_beneath_attr attr = {
> .allowed_access = LANDLOCK_ACCESS_FS_IOCTL_DEV,
> .parent_fd = current,
> };
> if (syscall(SYS_landlock_add_rule, ruleset_fd, LANDLOCK_RULE_PATH_BENEATH,
> &attr, 0) < 0)
> err(1, "landlock_add_rule");
> }
>
> if (mkdirat(current, path, 0700) < 0)
> err(1, "mkdirat(%s)", path);
>
> int previous = current;
> current = openat(current, path, O_PATH);
> if (current < 0)
> err(1, "open(%s)", path);
>
> close(previous);
> }
>
> if (use_landlock) {
> if (syscall(SYS_landlock_restrict_self, ruleset_fd, 0) < 0)
> err(1, "landlock_restrict_self");
> }
>
> close(ruleset_fd);
> return current;
> }
>
> int main(int argc, char *argv[]) {
> for (int i = 1; i < argc; i++) {
> if (!strcmp(argv[i], "-no-landlock")) {
> use_landlock = false;
> } else if (!strcmp(argv[i], "-d")) {
> i++;
> if (i < argc)
> err(1, "expected number of subdirs after -d");
> num_subdirs = atoi(argv[i]);
> } else if (!strcmp(argv[i], "-n")) {
> i++;
> if (i < argc)
> err(1, "expected number of iterations after -n");
> num_iterations = atoi(argv[i]);
> } else {
> usage();
> errx(1, "unknown argument: %s", argv[i]);
> }
> }
>
> printf("*** Benchmark ***\n");
> printf("%zu dirs, %zu iterations, %s landlock\n", num_subdirs,
> num_iterations, use_landlock ? "with" : "without");
>
> struct tms start_time;
> if (times(&start_time) == -1)
> err(1, "times");
>
> int current = build_directory(num_subdirs);
>
> for (int i = 0; i < num_iterations; i++) {
> int fd = openat(current, ".", O_DIRECTORY);
> if (fd != -1)
> errx(1, "openat succeeded, expected error");
> }
>
> struct tms end_time;
> if (times(&end_time) == -1)
> err(1, "times");
>
> printf("*** Benchmark concluded ***\n");
> printf("System: %ld clocks\n", end_time.tms_stime - start_time.tms_stime);
> printf("User : %ld clocks\n", end_time.tms_utime - start_time.tms_utime);
> printf("Clocks per second: %d\n", CLOCKS_PER_SEC);
>
> close(current);
> }
> ```
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Mickaël Salaün @ 2026-01-09 15:25 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Günther Noack, Tingmao Wang, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <a5850eb9-cee3-412d-ac20-c47e3161fdd9@gmail.com>
On Fri, Jan 09, 2026 at 06:33:10AM -0500, Demi Marie Obenour wrote:
> On 1/8/26 06:14, Mickaël Salaün wrote:
> > On Fri, Jan 02, 2026 at 01:37:14PM -0500, Demi Marie Obenour wrote:
> >> On 1/2/26 05:50, Günther Noack wrote:
> >>> On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
> >>>> On 1/2/26 05:16, Günther Noack wrote:
> >>>>> On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
> >>>>>> On 1/1/26 17:34, Tingmao Wang wrote:
> >>>>>>> On 1/1/26 22:14, Demi Marie Obenour wrote:
> >>>>>>>> [...]
> >>>>>>>> Does this leave directory traversal as the only missing Landlock
> >>>>>>>> filesystem access control? Ideally Landlock could provide the same
> >>>>>>>> isolation from the filesystem that mount namespaces do.
> >>>>>>>
> >>>>>>> I think that level of isolation would require path walk control - see:
> >>>>>>> https://github.com/landlock-lsm/linux/issues/9
> >>>>>>>
> >>>>>>> (Landlock also doesn't currently control some metadata operations - see
> >>>>>>> the warning at the end of the "Filesystem flags" section in [1])
> >>>>>>>
> >>>>>>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
> >>>>>>
> >>>>>> Could this replace all of the existing hooks?
> >>>>>
> >>>>> If you do not need to distinguish between the different operations
> >>>>> which Landlock offers access rights for, but you only want to limit
> >>>>> the visibility of directory hierarchies in the file system, then yes,
> >>>>> the path walk control described in issue 9 would be sufficient and a
> >>>>> more complete control.
> >>>>>
> >>>>> The path walk control is probably among the more difficult Landlock
> >>>>> feature requests. A simple implementation would be easy to implement
> >>>>> technically, but it also requires a new LSM hook which will have to
> >>>>> get called *during* path lookup, and we'd have to make sure that the
> >>>>> performance impact stays in check. Path lookup is after all a very
> >>>>> central facility in a OS kernel.
> >>>>
> >>>> What about instead using the inode-based hooks for directory searching?
> >>>> SELinux can already restrict that.
> >>>
> >>> Oh, thanks, good pointer! I was under the impression that this didn't
> >>> exist yet -- I assume you are referring to the
> >>> security_inode_follow_link() hook, which is already happening during
> >>> path resolution?
> >>
> >> I'm not familiar with existing LSM hooks, but I do know that SELinux
> >> enforces checks on searching and reading directories and symlinks.
> >
> > SELinux uses inode-based hooks, which is not (directly) possible for
> > Landlock because it is an unprivileged access control, which means it
> > cannot rely on extended file attributes to define a security policy.
> >
> > See https://github.com/landlock-lsm/linux/issues/9
>
> Could Landlock use a side table, with the inode's address in memory
> as the key?
A struct inode is not enough because we need to resolve a file
hierarchy, which is only possible with a struct path.
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Mickaël Salaün @ 2026-01-09 15:20 UTC (permalink / raw)
To: Günther Noack
Cc: Paul Moore, linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Kuniyuki Iwashima
In-Reply-To: <20260109.d4c29e22f15f@gnoack.org>
On Fri, Jan 09, 2026 at 03:41:33PM +0100, Günther Noack wrote:
> On Fri, Jan 09, 2026 at 11:37:12AM +0100, Mickaël Salaün wrote:
> > On Thu, Jan 01, 2026 at 02:40:57PM +0100, Günther Noack wrote:
> > > ## Motivation
> > >
> > > Currently, landlocked processes can connect() to named UNIX sockets
> > > through the BSD socket API described in unix(7), by invoking socket(2)
> > > followed by connect(2) with a suitable struct sockname_un holding the
> > > socket's filename. This can come as a surprise for users (e.g. in
> > > [1]) and it can be used to escape a sandbox when a Unix service offers
> > > command execution (some scenarios were listed by Tingmao Wang in [2]).
> > >
> > > These patches are built on Justin Suess's patch which adds the LSM
> > > hook:
> > > https://lore.kernel.org/all/20251231213314.2979118-1-utilityemal77@gmail.com/
> >
> > As Kuniyuki pointed out [1], we should handle both connect and send.
> > This would be similar to the scoped restriction from Tingmao. I guess
> > we'll need a similar hook for the send operation. Because there is no
> > need to differenciate between connected and disconnected unix socket in
> > a security policy, we should have one access right for both. Any
> > proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?
> >
> > [1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/
>
> Ah, thanks for pointing it out.
>
> The restriction as implemented in this patch set already solves this
> for all the three cases where a Unix socket file is looked up. I
> believe that it is happening in all the right times (everytime when
> the lookup has to happen).
>
> The cases where the restriction applies are the following:
>
> * unix_stream_connect - when calling connect() on a stream socket
> * unix_dgram_connect - when calling connect() on a dgram socket
> * unix_dgram_sendmsg - when calling sendmsg() on a dgram socket
> (per-message lookup only)
>
> You can find the code locations by looking for the call to
> unix_find_other() in af_unix.c. (That function invokes either
> unix_find_bsd() or the lookup for abstract Unix sockets.)
>
> In the unix_dgram_sendmsg() case, the lookup is only performed if an
> explicit sockaddr_un was provided together with the arguments to the
> sendmsg(). (And sendto(2) also uses the same code path as
> sendmsg(2).)
Great
>
> It is true that the current name for the access right is slightly
> misleading. How about LANDLOCK_ACCESS_FS_UNIX_SEND? (Like
> "transmit", but a bit closer to the naming of the sendmsg(2)
> networking API?)
We should try to keep the access right naming consistent:
LANDLOCK_ACCESS_FS_<VERB>[_NOUN]
What about USE_UNIX, or FIND_UNIX (closer to the kernel function), or
RESOLVE_UNIX? It should be clear with the name that it is not about
listening nor receiving from a process outside of the sandbox (which
should have its own access right BTW).
>
> (I guess the other alternative would be to wire the socket type
> information through to the unix_find_bsd() function and pass it
> through. Would require a small change to the af_unix.c implementation,
> but then we could tell apart LANDLOCK_ACCESS_FS_UNIX_STREAM_CONNECT
> and LANDLOCK_ACCESS_FS_UNIX_DGRAM_SEND). WDYT?
I think the hook should have the same arguments as unix_find_bsd()'s
ones. This gives the full context of the call.
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Günther Noack @ 2026-01-09 14:41 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Kuniyuki Iwashima
In-Reply-To: <20260109.she1eg0Ohl4u@digikod.net>
On Fri, Jan 09, 2026 at 11:37:12AM +0100, Mickaël Salaün wrote:
> On Thu, Jan 01, 2026 at 02:40:57PM +0100, Günther Noack wrote:
> > ## Motivation
> >
> > Currently, landlocked processes can connect() to named UNIX sockets
> > through the BSD socket API described in unix(7), by invoking socket(2)
> > followed by connect(2) with a suitable struct sockname_un holding the
> > socket's filename. This can come as a surprise for users (e.g. in
> > [1]) and it can be used to escape a sandbox when a Unix service offers
> > command execution (some scenarios were listed by Tingmao Wang in [2]).
> >
> > These patches are built on Justin Suess's patch which adds the LSM
> > hook:
> > https://lore.kernel.org/all/20251231213314.2979118-1-utilityemal77@gmail.com/
>
> As Kuniyuki pointed out [1], we should handle both connect and send.
> This would be similar to the scoped restriction from Tingmao. I guess
> we'll need a similar hook for the send operation. Because there is no
> need to differenciate between connected and disconnected unix socket in
> a security policy, we should have one access right for both. Any
> proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?
>
> [1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/
Ah, thanks for pointing it out.
The restriction as implemented in this patch set already solves this
for all the three cases where a Unix socket file is looked up. I
believe that it is happening in all the right times (everytime when
the lookup has to happen).
The cases where the restriction applies are the following:
* unix_stream_connect - when calling connect() on a stream socket
* unix_dgram_connect - when calling connect() on a dgram socket
* unix_dgram_sendmsg - when calling sendmsg() on a dgram socket
(per-message lookup only)
You can find the code locations by looking for the call to
unix_find_other() in af_unix.c. (That function invokes either
unix_find_bsd() or the lookup for abstract Unix sockets.)
In the unix_dgram_sendmsg() case, the lookup is only performed if an
explicit sockaddr_un was provided together with the arguments to the
sendmsg(). (And sendto(2) also uses the same code path as
sendmsg(2).)
It is true that the current name for the access right is slightly
misleading. How about LANDLOCK_ACCESS_FS_UNIX_SEND? (Like
"transmit", but a bit closer to the naming of the sendmsg(2)
networking API?)
(I guess the other alternative would be to wire the socket type
information through to the unix_find_bsd() function and pass it
through. Would require a small change to the af_unix.c implementation,
but then we could tell apart LANDLOCK_ACCESS_FS_UNIX_STREAM_CONNECT
and LANDLOCK_ACCESS_FS_UNIX_DGRAM_SEND). WDYT?
–Günther
^ permalink raw reply
* Re: [PATCH v5 10/36] locking/mutex: Support Clang's context analysis
From: Steven Rostedt @ 2026-01-09 13:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Marco Elver, Bart Van Assche, Peter Zijlstra, Boqun Feng,
Ingo Molnar, Will Deacon, David S. Miller, Luc Van Oostenryck,
Chris Li, Paul E. McKenney, Alexander Potapenko, Arnd Bergmann,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Tetsuo Handa, Thomas Gleixner,
Thomas Graf, Uladzislau Rezki, Waiman Long, kasan-dev,
linux-crypto, linux-doc, linux-kbuild, linux-kernel, linux-mm,
linux-security-module, linux-sparse, linux-wireless, llvm, rcu
In-Reply-To: <20260109060249.GA5259@lst.de>
On Fri, 9 Jan 2026 07:02:49 +0100
Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Jan 09, 2026 at 12:26:55AM +0100, Marco Elver wrote:
> > Probably the most idiomatic option is to just factor out construction.
> > Clearly separating complex object construction from use also helps
> > readability regardless, esp. where concurrency is involved. We could
> > document such advice somewhere.
>
> Initializing and locking a mutex (or spinlock, or other primitive) is a
> not too unusual pattern, often used when inserting an object into a
> hash table or other lookup data structure. So supporting it without
> creating pointless wrapper functions would be really useful. One thing
> that would be nice to have and probably help here is to have lock
> initializers that create the lock in a held state.
Right. If tooling can't handle a simple pattern of initializing a lock than
taking it, that's a hard show stopper of adding that tooling.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 0/6] Landlock: Implement scope control for pathname Unix sockets
From: Mickaël Salaün @ 2026-01-09 12:01 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Günther Noack, Tingmao Wang, Günther Noack, Alyssa Ross,
Jann Horn, Tahera Fahimi, Justin Suess, linux-security-module
In-Reply-To: <dc9b99b6-14a1-45b6-a23f-0b24143dac58@gmail.com>
On Wed, Dec 31, 2025 at 11:54:27AM -0500, Demi Marie Obenour wrote:
> On 12/30/25 18:16, Günther Noack wrote:
> > Hello!
> >
> > Thanks for sending this patch!
> >
> > On Tue, Dec 30, 2025 at 05:20:18PM +0000, Tingmao Wang wrote:
> >> Changes in v2:
> >> Fix grammar in doc, rebased on mic/next, and extracted common code from
> >> hook_unix_stream_connect and hook_unix_may_send into a separate
> >> function.
> >>
> >> The rest is the same as the v1 cover letter:
> >>
> >> This patch series extend the existing abstract Unix socket scoping to
> >> pathname (i.e. normal file-based) sockets as well, by adding a new scope
> >> bit LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET that works the same as
> >> LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET, except that restricts pathname Unix
> >> sockets. This means that a sandboxed process with this scope enabled will
> >> not be able to connect to Unix sockets created outside the sandbox via the
> >> filesystem.
> >>
> >> There is a future plan [1] for allowing specific sockets based on FS
> >> hierarchy, but this series is only determining access based on domain
> >> parent-child relationship. There is currently no way to allow specific
> >> (outside the Landlock domain) Unix sockets, and none of the existing
> >> Landlock filesystem controls apply to socket connect().
> >>
> >> With this series, we can now properly protect against things like the the
> >> following while only relying on Landlock:
> >>
> >> (running under tmux)
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb ~# LL_FS_RO=/ LL_FS_RW= ./sandboxer bash
> >> Executing the sandboxed command...
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
> >> cat: /tmp/hi: No such file or directory
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# tmux new-window 'echo hi > /tmp/hi'
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
> >> hi
> >>
> >> The above but with Unix socket scoping enabled (both pathname and abstract
> >> sockets) - the sandboxed shell can now no longer talk to tmux due to the
> >> socket being created from outside the Landlock sandbox:
> >>
> >> (running under tmux)
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb ~# LL_FS_RO=/ LL_FS_RW= LL_SCOPED=u:a ./sandboxer bash
> >> Executing the sandboxed command...
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
> >> cat: /tmp/hi: No such file or directory
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# tmux new-window 'echo hi > /tmp/hi'
> >> error connecting to /tmp/tmux-0/default (Operation not permitted)
> >> root@6-19-0-rc1-dev-00023-g68f0b276cbeb:/# cat /tmp/hi
> >> cat: /tmp/hi: No such file or directory
> >>
> >> Tmux is just one example. In a standard systemd session, `systemd-run
> >> --user` can also be used (--user will run the command in the user's
> >> session, without requiring any root privileges), and likely a lot more if
> >> running in a desktop environment with many popular applications. This
> >> change therefore makes it possible to create sandboxes without relying on
> >> additional mechanisms like seccomp to protect against such issues.
> >>
> >> These kind of issues was originally discussed on here (I took the idea for
> >> systemd-run from Demi):
> >> https://spectrum-os.org/lists/archives/spectrum-devel/00256266-26db-40cf-8f5b-f7c7064084c2@gmail.com/
> >
> > What is unclear to me from the examples and the description is: Why is
> > the boundary between allowed and denied connection targets drawn at
> > the border of the Landlock domain (the "scope") and why don't we solve
> > this with the file-system-based approach described in [1]?
> >
> > **Do we have existing use cases where a service is both offered and
> > connected to all from within the same Landlock domain, and where the
> > process enforcing the policy does not control the child process enough
> > so that it would be possible to allow-list it with a
> > LANDLOCK_ACCESS_FS_CONNECT_UNIX rule?**
Yes, with the sandboxer use case. It's similar to a container that
doesn't know all programs that could be run in it. We should be able to
create sandboxes that don't assume (nor restrict) internal IPCs (or any
kind of direct process I/O).
Landlock should make it possible to scope any kind of IPC. It's a
mental model which is easy to understand and that should be enforced by
default. Of course, we need some ways to add exceptions to this
deny-by-default policy, and that's why we also need the FS-based control
mechanism.
> >
> > If we do not have such a use case, it seems that the planned FS-based
> > control mechanism from [1] would do the same job? Long term, we might
> > be better off if we only have only one control -- as we have discussed
> > in [2], having two of these might mean that they interact in
> > unconventional and possibly confusing ways.
>
> I agree with this.
Both approaches are complementary/orthogonal and make sense long term
too. This might be the first time we can restrict the same operations,
but I'm pretty sure it will not be the last, and it's OK. Handled FS
access and scoped restrictions are two ways to describe a part of the
security policy. Having different ways makes the interface much simpler
than a generic one that would have to take into account all potential
future access controls.
One thing to keep in mind is that UAPI doesn't have to map 1:1 to the
kernel implementation, but the UAPI is stable and future proof, whereas
the kernel implementation can change a lot.
The ruleset's handled fields serve two purposes: define what should be
denied by default, and define which type of rules are valid
(compatibility). The ruleset's scoped field serve similar purposes but
it also implies implicit rules (i.e. communications with processes
inside the sandbox are allowed). Without the soped field, we would have
to create dedicated handled field per type (i.e. scope's bit) and
dedicated rule type for the related handled field, which would make the
interface more generic but also more complex, for something which is not
needed.
In a nutshell, in the case of the FS-based and scope-based unix socket
control, we should see one kind of restrictions (e.g. connect to unix
socket), which can accept two types of rules: (explicit) file path, or
(implicit) peer's scope. Access should be granted as long as a rule
matches, whatever its type.
This rationale should be explained in a commit message.
>
> > Apart from that, there are some other weaker hints that make me
> > slightly critical of this patch set:
> >
> > * We discussed the idea that a FS-based path_beneath rule would act
> > implicitly also as an exception for
> > LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET, in [2] - one possible way to
> > interpret this is that the gravity of the system's logic pulls us
> > back towards a FS-based control, and we would have to swim less
> > against the stream if we integrated the Unix connect() control in
> > that way?
>
> I agree with this as well. Having FS-based controls apply consistently
> to all types of inodes is what I would expect.
I'm not sure to understand, but I hope my explanation above will answer
this question.
>
> > * I am struggling to convince myself that we can tell users to
> > restrict LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET as a default, as we are
> > currently doing it with the other "scoped" and file system controls.
> > (The scoped signals are OK because killing out-of-domain processes
> > is clearly bad. The scoped abstract sockets are usually OK because
> > most processes do not need that feature.)
> >
> > But there are legitimate Unix services that are still needed by
> > unprivileged processes and which are designed to be safe to use.
> > For instance, systemd exposes a user database lookup service over
> > varlink [3], which can be accessed from arbitrary glibc programs
> > through a NSS module. Using this is incompatible with
> > LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET as long as we do not have the
> > FS-based control and the surprising implicit permission through a
> > path_beneath rule as discussed in [2].
> >
> > (Another example is the X11 socket, to which the same reasoning
> > should apply, I think, and which is also used by a large number of
> > programs.)
Yes, restricting a sandbox too much may not work for any possible use
cases. Some use cases would need the FS-based control before using the
scope-based one, and that's OK. Some use cases would not need the
FS-based control, and the scope-based one would be enough (e.g.
sandboxed archive manager).
> I think making FS-based controls on by default is the least surprising
> option for users. It's what I suspect most programs intend, and it
> would stop a lot of unexpected sandbox escapes.
Nothing in Landlock is on by default for compatibility reasons.
>
> Without FS-based controls, scoping is also necessary to prevent
> sandbox escapes. In my opinion, it's better to block access to
> unprivileged services than to allow connecting to any service.
Scoped-based control should be enforced in most cases, but FS-based
control might be a requirement/dependency. In any case, a sandbox
should not break legitimate use cases.
>
> X11 is a trivial sandbox escape by taking over the user's GUI.
> A sandboxed program accessing it indicates a misdesign.
I would say a *fully* sandboxed program for a desktop use case using X11
(instead of Wayland), which is not possible with Landlock *alone* yet.
Desktop environment is the worse case scenario for sandboxing, for a lot
of different reasons... but there are a lot of other use cases for
sandboxing.
> The NSS module
> is not needed by programs that do not do user database resolution,
> which I suspect includes almost all sandboxed programs.
>
> > I agree that the bug [1] has been asleep for a bit too long, and we
> > should probably pick this up soon. As we have not heard back from
> > Ryan after our last inquiry, IMHO I think it would be fair to take it
> > over.
>
> I definitely support this!
Yes, thanks for working on this.
>
> > Apologies for the difficult feedback - I do not mean to get in the way
> > of your enthusiasm here, but I would like to make sure that we don't
> > implement this as a stop-gap measure just because the other bug [1]
> > seemed more difficult and/or stuck in a github issue interaction.
> > Let's rather unblock that bug, if that is the case. :)
Receiving criticisms is part of the review process, which is a sign of
healthy development. I understand your concerns and it's good discuss
about them to make sure we are going in the right direction.
> >
> > As usual, I fully acknowledge that I might well be wrong and might
> > have missed some of the underlying reasons, in which case I will
> > happily be corrected and change my mind. :)
In any case, if someone doesn't understand something, it probably means
that this should be explained better somewhere. Such design artifacts
will be useful for future developments too.
> >
> > [1] https://github.com/landlock-lsm/linux/issues/36
> > [2] https://github.com/landlock-lsm/linux/issues/36#issuecomment-3699749541
> > [3] https://systemd.io/USER_GROUP_API/
> >
> > Have a good start into the new year!
> > –Günther
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Demi Marie Obenour @ 2026-01-09 11:33 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Tingmao Wang, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <20260108.uoD0aesh8Uth@digikod.net>
[-- Attachment #1.1.1: Type: text/plain, Size: 2828 bytes --]
On 1/8/26 06:14, Mickaël Salaün wrote:
> On Fri, Jan 02, 2026 at 01:37:14PM -0500, Demi Marie Obenour wrote:
>> On 1/2/26 05:50, Günther Noack wrote:
>>> On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
>>>> On 1/2/26 05:16, Günther Noack wrote:
>>>>> On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
>>>>>> On 1/1/26 17:34, Tingmao Wang wrote:
>>>>>>> On 1/1/26 22:14, Demi Marie Obenour wrote:
>>>>>>>> [...]
>>>>>>>> Does this leave directory traversal as the only missing Landlock
>>>>>>>> filesystem access control? Ideally Landlock could provide the same
>>>>>>>> isolation from the filesystem that mount namespaces do.
>>>>>>>
>>>>>>> I think that level of isolation would require path walk control - see:
>>>>>>> https://github.com/landlock-lsm/linux/issues/9
>>>>>>>
>>>>>>> (Landlock also doesn't currently control some metadata operations - see
>>>>>>> the warning at the end of the "Filesystem flags" section in [1])
>>>>>>>
>>>>>>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
>>>>>>
>>>>>> Could this replace all of the existing hooks?
>>>>>
>>>>> If you do not need to distinguish between the different operations
>>>>> which Landlock offers access rights for, but you only want to limit
>>>>> the visibility of directory hierarchies in the file system, then yes,
>>>>> the path walk control described in issue 9 would be sufficient and a
>>>>> more complete control.
>>>>>
>>>>> The path walk control is probably among the more difficult Landlock
>>>>> feature requests. A simple implementation would be easy to implement
>>>>> technically, but it also requires a new LSM hook which will have to
>>>>> get called *during* path lookup, and we'd have to make sure that the
>>>>> performance impact stays in check. Path lookup is after all a very
>>>>> central facility in a OS kernel.
>>>>
>>>> What about instead using the inode-based hooks for directory searching?
>>>> SELinux can already restrict that.
>>>
>>> Oh, thanks, good pointer! I was under the impression that this didn't
>>> exist yet -- I assume you are referring to the
>>> security_inode_follow_link() hook, which is already happening during
>>> path resolution?
>>
>> I'm not familiar with existing LSM hooks, but I do know that SELinux
>> enforces checks on searching and reading directories and symlinks.
>
> SELinux uses inode-based hooks, which is not (directly) possible for
> Landlock because it is an unprivileged access control, which means it
> cannot rely on extended file attributes to define a security policy.
>
> See https://github.com/landlock-lsm/linux/issues/9
Could Landlock use a side table, with the inode's address in memory
as the key?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/5] landlock/selftests: add a missing close(srv_fd) call
From: Mickaël Salaün @ 2026-01-09 10:49 UTC (permalink / raw)
To: Günther Noack
Cc: Paul Moore, linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi
In-Reply-To: <20260109.Thoot8ooWai7@digikod.net>
On Fri, Jan 09, 2026 at 11:41:30AM +0100, Mickaël Salaün wrote:
> Good, I'll pick that in my -next branch.
>
> Nit: The prefix should be "selftests/landlock"
>
> On Thu, Jan 01, 2026 at 02:40:58PM +0100, Günther Noack wrote:
> > Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> > ---
> > tools/testing/selftests/landlock/fs_test.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
> > index 37a5a3df712ec..16503f2e6a481 100644
> > --- a/tools/testing/selftests/landlock/fs_test.c
> > +++ b/tools/testing/selftests/landlock/fs_test.c
> > @@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
> > EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
> >
> > ASSERT_EQ(0, close(cli_fd));
> > + ASSERT_EQ(0, close(srv_fd));
I'll also replace these ASSERT_EQ() with EXPECT_EQ().
> > }
> >
> > /* clang-format off */
> > --
> > 2.52.0
> >
> >
^ permalink raw reply
* Re: [RFC PATCH 1/5] landlock/selftests: add a missing close(srv_fd) call
From: Mickaël Salaün @ 2026-01-09 10:41 UTC (permalink / raw)
To: Günther Noack
Cc: Paul Moore, linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi
In-Reply-To: <20260101134102.25938-2-gnoack3000@gmail.com>
Good, I'll pick that in my -next branch.
Nit: The prefix should be "selftests/landlock"
On Thu, Jan 01, 2026 at 02:40:58PM +0100, Günther Noack wrote:
> Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> ---
> tools/testing/selftests/landlock/fs_test.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
> index 37a5a3df712ec..16503f2e6a481 100644
> --- a/tools/testing/selftests/landlock/fs_test.c
> +++ b/tools/testing/selftests/landlock/fs_test.c
> @@ -4400,6 +4400,7 @@ TEST_F_FORK(layout1, named_unix_domain_socket_ioctl)
> EXPECT_EQ(0, test_fionread_ioctl(cli_fd));
>
> ASSERT_EQ(0, close(cli_fd));
> + ASSERT_EQ(0, close(srv_fd));
> }
>
> /* clang-format off */
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Mickaël Salaün @ 2026-01-09 10:37 UTC (permalink / raw)
To: Günther Noack
Cc: Paul Moore, linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Kuniyuki Iwashima
In-Reply-To: <20260101134102.25938-1-gnoack3000@gmail.com>
On Thu, Jan 01, 2026 at 02:40:57PM +0100, Günther Noack wrote:
> Happy New Year!
Happy New Year!
>
> This patch set introduces a file-system-based Landlock restriction
> mechanism for connecting to Unix sockets.
Thanks for this patch series, this is an important feature for
sandboxing.
>
> ## Motivation
>
> Currently, landlocked processes can connect() to named UNIX sockets
> through the BSD socket API described in unix(7), by invoking socket(2)
> followed by connect(2) with a suitable struct sockname_un holding the
> socket's filename. This can come as a surprise for users (e.g. in
> [1]) and it can be used to escape a sandbox when a Unix service offers
> command execution (some scenarios were listed by Tingmao Wang in [2]).
>
> These patches are built on Justin Suess's patch which adds the LSM
> hook:
> https://lore.kernel.org/all/20251231213314.2979118-1-utilityemal77@gmail.com/
As Kuniyuki pointed out [1], we should handle both connect and send.
This would be similar to the scoped restriction from Tingmao. I guess
we'll need a similar hook for the send operation. Because there is no
need to differenciate between connected and disconnected unix socket in
a security policy, we should have one access right for both. Any
proposal for its name? Something like TRANSMIT_UNIX or EMIT_UNIX?
[1] https://lore.kernel.org/all/CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com/
^ permalink raw reply
* Re: [PATCH v3 5/6] keys/trusted_keys: establish PKWM as a trusted source
From: Srish Srinivasan @ 2026-01-09 8:47 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, keyrings, linuxppc-dev, maddy, mpe, npiggin,
christophe.leroy, James.Bottomley, zohar, nayna, rnsastry,
linux-kernel, linux-security-module
In-Reply-To: <aV-w2NbxAPuuXy_U@kernel.org>
Hi Jarkko,
thank you for taking a look.
On 1/8/26 6:57 PM, Jarkko Sakkinen wrote:
> On Tue, Jan 06, 2026 at 08:35:26PM +0530, Srish Srinivasan wrote:
>> The wrapping key does not exist by default and is generated by the
>> hypervisor as a part of PKWM initialization. This key is then persisted by
>> the hypervisor and is used to wrap trusted keys. These are variable length
>> symmetric keys, which in the case of PowerVM Key Wrapping Module (PKWM) are
>> generated using the kernel RNG. PKWM can be used as a trust source through
>> the following example keyctl commands:
>>
>> keyctl add trusted my_trusted_key "new 32" @u
>>
>> Use the wrap_flags command option to set the secure boot requirement for
>> the wrapping request through the following keyctl commands
>>
>> case1: no secure boot requirement. (default)
>> keyctl usage: keyctl add trusted my_trusted_key "new 32" @u
>> OR
>> keyctl add trusted my_trusted_key "new 32 wrap_flags=0x00" @u
>>
>> case2: secure boot required to in either audit or enforce mode. set bit 0
>> keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x01" @u
>>
>> case3: secure boot required to be in enforce mode. set bit 1
>> keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x02" @u
>>
>> NOTE:
>> -> Setting the secure boot requirement is NOT a must.
>> -> Only either of the secure boot requirement options should be set. Not
>> both.
>> -> All the other bits are required to be not set.
>> -> Set the kernel parameter trusted.source=pkwm to choose PKWM as the
>> backend for trusted keys implementation.
>> -> CONFIG_PSERIES_PLPKS must be enabled to build PKWM.
>>
>> Add PKWM, which is a combination of IBM PowerVM and Power LPAR Platform
>> KeyStore, as a new trust source for trusted keys.
>>
>> Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
>> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
>> ---
>> MAINTAINERS | 9 ++
>> include/keys/trusted-type.h | 7 +-
>> include/keys/trusted_pkwm.h | 22 +++
>> security/keys/trusted-keys/Kconfig | 8 ++
>> security/keys/trusted-keys/Makefile | 2 +
>> security/keys/trusted-keys/trusted_core.c | 6 +-
>> security/keys/trusted-keys/trusted_pkwm.c | 168 ++++++++++++++++++++++
>> 7 files changed, 220 insertions(+), 2 deletions(-)
>> create mode 100644 include/keys/trusted_pkwm.h
>> create mode 100644 security/keys/trusted-keys/trusted_pkwm.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a0dd762f5648..ba51eff21a16 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14003,6 +14003,15 @@ S: Supported
>> F: include/keys/trusted_dcp.h
>> F: security/keys/trusted-keys/trusted_dcp.c
>>
>> +KEYS-TRUSTED-PLPKS
>> +M: Srish Srinivasan <ssrish@linux.ibm.com>
>> +M: Nayna Jain <nayna@linux.ibm.com>
>> +L: linux-integrity@vger.kernel.org
>> +L: keyrings@vger.kernel.org
>> +S: Supported
>> +F: include/keys/trusted_plpks.h
>> +F: security/keys/trusted-keys/trusted_pkwm.c
>> +
>> KEYS-TRUSTED-TEE
>> M: Sumit Garg <sumit.garg@kernel.org>
>> L: linux-integrity@vger.kernel.org
>> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
>> index 4eb64548a74f..45c6c538df22 100644
>> --- a/include/keys/trusted-type.h
>> +++ b/include/keys/trusted-type.h
>> @@ -19,7 +19,11 @@
>>
>> #define MIN_KEY_SIZE 32
>> #define MAX_KEY_SIZE 128
>> -#define MAX_BLOB_SIZE 512
>> +#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
>> +#define MAX_BLOB_SIZE 1152
>> +#else
>> +#define MAX_BLOB_SIZE 512
>> +#endif
>> #define MAX_PCRINFO_SIZE 64
>> #define MAX_DIGEST_SIZE 64
>>
>> @@ -46,6 +50,7 @@ struct trusted_key_options {
>> uint32_t policydigest_len;
>> unsigned char policydigest[MAX_DIGEST_SIZE];
>> uint32_t policyhandle;
>> + uint16_t wrap_flags;
>> };
> We should introduce:
>
> void *private;
>
> And hold backend specific fields there.
>
> This patch set does not necessarily have to migrate TPM fields to this
> new framework, only start a better convention before this turns into
> a chaos.
Sure,
thanks for bringing this up.
I will make the required changes in my next version.
>
> BR, Jarkko
>
thanks,
Srish.
^ permalink raw reply
* Re: [PATCH v5 10/36] locking/mutex: Support Clang's context analysis
From: Christoph Hellwig @ 2026-01-09 6:02 UTC (permalink / raw)
To: Marco Elver
Cc: Bart Van Assche, Peter Zijlstra, Boqun Feng, Ingo Molnar,
Will Deacon, David S. Miller, Luc Van Oostenryck, Chris Li,
Paul E. McKenney, Alexander Potapenko, Arnd Bergmann,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu
In-Reply-To: <aWA9P3_oI7JFTdkC@elver.google.com>
On Fri, Jan 09, 2026 at 12:26:55AM +0100, Marco Elver wrote:
> Probably the most idiomatic option is to just factor out construction.
> Clearly separating complex object construction from use also helps
> readability regardless, esp. where concurrency is involved. We could
> document such advice somewhere.
Initializing and locking a mutex (or spinlock, or other primitive) is a
not too unusual pattern, often used when inserting an object into a
hash table or other lookup data structure. So supporting it without
creating pointless wrapper functions would be really useful. One thing
that would be nice to have and probably help here is to have lock
initializers that create the lock in a held state.
^ permalink raw reply
* Re: [PATCH v5 10/36] locking/mutex: Support Clang's context analysis
From: Marco Elver @ 2026-01-08 23:26 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <57062131-e79e-42c2-aa0b-8f931cb8cac2@acm.org>
On Thu, Jan 08, 2026 at 02:10PM -0800, 'Bart Van Assche' via kasan-dev wrote:
> On 12/19/25 8:39 AM, Marco Elver wrote:
> > diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> > index bf535f0118bb..89977c215cbd 100644
> > --- a/include/linux/mutex.h
> > +++ b/include/linux/mutex.h
> > @@ -62,6 +62,7 @@ do { \
> > static struct lock_class_key __key; \
> > \
> > __mutex_init((mutex), #mutex, &__key); \
> > + __assume_ctx_lock(mutex); \
> > } while (0)
>
> The above type of change probably will have to be reverted. If I enable
> context analysis for the entire kernel tree, drivers/base/devcoredump.c
> doesn't build. The following error is reported:
>
> drivers/base/devcoredump.c:406:2: error: acquiring mutex '_res->mutex' that
> is already held [-Werror,-Wthread-safety-analysis]
> 406 | mutex_lock(&devcd->mutex);
> | ^
>
> dev_coredumpm_timeout() calls mutex_init() and mutex_lock() from the same
> function. The above type of change breaks compilation of all code
> that initializes and locks a synchronization object from the same
> function. My understanding of dev_coredumpm_timeout() is that there is a
> good reason for calling both mutex_init() and mutex_lock() from that
> function. Possible solutions are disabling context analysis for that
> function or removing __assume_ctx_lock() again from mutex_init(). Does
> anyone want to share their opinion about this?
Probably the most idiomatic option is to just factor out construction.
Clearly separating complex object construction from use also helps
readability regardless, esp. where concurrency is involved. We could
document such advice somewhere.
For the above case, this seems cleanest and also clearer to me:
diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
index 55bdc7f5e59d..56ac8aa41608 100644
--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -339,6 +339,40 @@ void dev_coredump_put(struct device *dev)
}
EXPORT_SYMBOL_GPL(dev_coredump_put);
+static struct devcd_entry *
+dev_coredumpm_init(struct device *dev, struct module *owner, void *data,
+ size_t datalen, gfp_t gfp,
+ ssize_t (*read)(char *buffer, loff_t offset, size_t count,
+ void *data, size_t datalen),
+ void (*free)(void *data))
+{
+ static atomic_t devcd_count = ATOMIC_INIT(0);
+ struct devcd_entry *devcd;
+
+ devcd = kzalloc(sizeof(*devcd), gfp);
+ if (!devcd)
+ return NULL;
+
+ devcd->owner = owner;
+ devcd->data = data;
+ devcd->datalen = datalen;
+ devcd->read = read;
+ devcd->free = free;
+ devcd->failing_dev = get_device(dev);
+ devcd->deleted = false;
+
+ mutex_init(&devcd->mutex);
+ device_initialize(&devcd->devcd_dev);
+
+ dev_set_name(&devcd->devcd_dev, "devcd%d",
+ atomic_inc_return(&devcd_count));
+ devcd->devcd_dev.class = &devcd_class;
+
+ dev_set_uevent_suppress(&devcd->devcd_dev, true);
+
+ return devcd;
+}
+
/**
* dev_coredumpm_timeout - create device coredump with read/free methods with a
* custom timeout.
@@ -364,7 +398,6 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner,
void (*free)(void *data),
unsigned long timeout)
{
- static atomic_t devcd_count = ATOMIC_INIT(0);
struct devcd_entry *devcd;
struct device *existing;
@@ -381,27 +414,10 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner,
if (!try_module_get(owner))
goto free;
- devcd = kzalloc(sizeof(*devcd), gfp);
+ devcd = dev_coredumpm_init(dev, owner, data, datalen, gfp, read, free);
if (!devcd)
goto put_module;
- devcd->owner = owner;
- devcd->data = data;
- devcd->datalen = datalen;
- devcd->read = read;
- devcd->free = free;
- devcd->failing_dev = get_device(dev);
- devcd->deleted = false;
-
- mutex_init(&devcd->mutex);
- device_initialize(&devcd->devcd_dev);
-
- dev_set_name(&devcd->devcd_dev, "devcd%d",
- atomic_inc_return(&devcd_count));
- devcd->devcd_dev.class = &devcd_class;
-
- dev_set_uevent_suppress(&devcd->devcd_dev, true);
-
/* devcd->mutex prevents devcd_del() completing until init finishes */
mutex_lock(&devcd->mutex);
devcd->init_completed = false;
^ permalink raw reply related
* Re: [PATCH v5 10/36] locking/mutex: Support Clang's context analysis
From: Bart Van Assche @ 2026-01-08 22:10 UTC (permalink / raw)
To: Marco Elver, Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon
Cc: David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <20251219154418.3592607-11-elver@google.com>
On 12/19/25 8:39 AM, Marco Elver wrote:
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index bf535f0118bb..89977c215cbd 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -62,6 +62,7 @@ do { \
> static struct lock_class_key __key; \
> \
> __mutex_init((mutex), #mutex, &__key); \
> + __assume_ctx_lock(mutex); \
> } while (0)
The above type of change probably will have to be reverted. If I enable
context analysis for the entire kernel tree, drivers/base/devcoredump.c
doesn't build. The following error is reported:
drivers/base/devcoredump.c:406:2: error: acquiring mutex '_res->mutex'
that is already held [-Werror,-Wthread-safety-analysis]
406 | mutex_lock(&devcd->mutex);
| ^
dev_coredumpm_timeout() calls mutex_init() and mutex_lock() from the
same function. The above type of change breaks compilation of all code
that initializes and locks a synchronization object from the same
function. My understanding of dev_coredumpm_timeout() is that there is a
good reason for calling both mutex_init() and mutex_lock() from that
function. Possible solutions are disabling context analysis for that
function or removing __assume_ctx_lock() again from mutex_init(). Does
anyone want to share their opinion about this?
Thanks,
Bart.
^ permalink raw reply
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Günther Noack @ 2026-01-08 21:30 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: Günther Noack, Justin Suess, Paul Moore, James Morris,
Serge E . Hallyn, Simon Horman, Mickaël Salaün,
linux-security-module, Tingmao Wang, netdev, Alexander Viro,
Christian Brauner
In-Reply-To: <CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com>
On Thu, Jan 08, 2026 at 02:17:05AM -0800, Kuniyuki Iwashima wrote:
> On Wed, Jan 7, 2026 at 4:49 AM Günther Noack <gnoack@google.com> wrote:
> > On Tue, Jan 06, 2026 at 11:33:32PM -0800, Kuniyuki Iwashima wrote:
> > > +VFS maintainers
> > >
> > > [...]
> > >
> > > Thanks for the explanation !
> > >
> > > So basically what you need is resolving unix_sk(sk)->addr.name
> > > by kern_path() and comparing its d_backing_inode(path.dentry)
> > > with d_backing_inode (unix_sk(sk)->path.dendtry).
> > >
> > > If the new hook is only used by Landlock, I'd prefer doing that on
> > > the existing connect() hooks.
> >
> > I've talked about that in the "Alternative: Use existing LSM hooks" section in
> > https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
> >
> > If we resolve unix_sk(sk)->addr.name ourselves in the Landlock hook
> > again, we would resolve the path twice: Once in unix_find_bsd() in
> > net/unix/af_unix.c (the Time-Of-Use), and once in the Landlock
> > security hook for the connect() operation (the Time-Of-Check).
> >
> > If I understand you correctly, you are suggesting that we check that
> > the inode resolved by af_unix
> > (d_backing_inode(unix_sk(sk)->path.dentry)) is the same as the one
> > that we resolve in Landlock ourselves, and therefore we can detect the
> > TOCTOU race and pretend that this is equivalent to the case where
> > af_unix resolved to the same inode with the path that Landlock
> > observed?
> >
> > If the walked file system hierarchy changes in between these two
> > accesses, Landlock enforces the policy based on path elements that
> > have changed in between.
> >
> > * We start with a Landlock policy where Unix connect() is restricted
> > by default, but is permitted on "foo/bar2" and everything underneath
> > it. The hierarchy is:
> >
> > foo/
> > bar/
> > baz.sock
> > bar2/ <--- Landlock rule: socket connect() allowed here and below
> >
> > * We connect() to the path "foo/bar/baz.sock"
> > * af_unix.c path lookup resolves "foo/bar/baz.sock" (TOU)
> > This works because Landlock is not checked at this point yet.
> > * In between the two lookups:
> > * the directory foo/bar gets renamed to foo/bar.old
> > * foo/bar2 gets moved to foo/bar
> > * baz.sock gets moved into the (new) foo/bar directory
> > * Landlock check: path lookup of "foo/bar/baz.sock" (TOC)
> > and subsequent policy check using the resolved path.
> >
> > This succeeds because connect() is permitted on foo/bar2 and
> > beneath. We also check that the resolved inode is the same as the
> > one resolved by af_unix.c.
> >
> > And now the reasoning is basically that this is fine because the
> > (inode) result of the two lookups was the same and we pretend that the
> > Landlock path lookup was the one where the actual permission check was
> > done?
>
> Right. IIUC, even in your patch, the file could be renamed
> while LSM is checking the path, no ? I think holding the
> path ref does not lock concurrent rename operations.
>
> To me, it's not a small race and basically it's the same with
> the ops below,
>
> sk1.bind('test')
> sk1.listen()
> os.rename('test', 'test2')
> sk2.connect('test2')
>
> sk1.bind('test')
> sk1.listen()
> sk2.connect('test1')
> os.rename('test', 'test2')
>
> and the important part is whether the path _was_ the
> allowed one when LSM checked the path.
I think we are in agreement here, yes. What matters is that the LSM
does its check on the same path as connect() used for the lookup (or
that at least it behaves that way to an outside observer).
> > Some pieces of this which I am still unsure about:
> >
> > * What we are supposed to do when the two resolved inodes are not the
> > same, because we detected the race? We can not allow the connection
> > in that case, but it would be wrong to deny it as well. I'm not
> > sure whether returning one of the -ERESTART* variants is feasible in
> > this place and bubbles up correctly to the system call / io_uring
> > layer.
>
> Imagine that the rename ops was done a bit earlier, which is
> before the first lookup in unix_find_bsd(). Then, the socket
> will not be found, and -ECONNREFUSED is returned.
> LSM pcan pretend as such.
No, it can not pretend as such when the inodes differ - the reasoning
is:
The rename(2) operation can be used to put a new socket in the place
of the old one, and both sockets might be OK to use in the Landlock
policy. If Landlock observes the race and the inodes are different,
that still does not mean that it should refuse the connection.
The trace is:
* /sock1 and /sock2 exist
* initial unix_find_bsd() lookup for /sock1
* rename(2) /sock2 to /sock1, replacing it
* LSM (Landlock) lookup for /sock1
The two lookups return different inodes, but we still should not
refuse the connection because of that.
> > * What if other kinds of permission checks happen on a different
> > lookup code path? (If another stacked LSM had a similar
> > implementation with yet another path lookup based on a different
> > kind of policy, and if a race happened in between, it could at least
> > be possible that for one variant of the path, it would be OK for
> > Landlock but not the other LSM, and for the other variant of the
> > path it would be OK for the other LSM but not Landlock, and then the
> > connection could get accepted even if that would not have been
> > allowed on one of the two paths alone.) I find this a somewhat
> > brittle implementation approach.
>
> Do you mean that the evaluation of the stacked LSMs could
> return 0 if one of them allows it even though other LSMs deny ?
Yes. If there are two LSMs employing that scheme, that would
happen.
## Example scenario 1 (two LSMs)
* LSM1 permits connections to sockets under /dir1 and denies others,
based on the inode associated with dir1.
* LSM2 permits connections to sockets under /dir2 and denies others.
based on the inode associated with dir2.
* The sockets /dir1/sock1 and /dir2/sock2 exist.
* initial unix_find_bsd() lookup for /dir1/sock1
* LSM1 lookup for /dir1/sock1 ==> returns 0 (accepted because /dir1 is OK in LSM1)
* Race:
* /dir1 gets moved to /dir1.old,
* /dir2 gets moved to /dir1 (keeping the original /dir2 inode),
* /dir1.old/sock1 gets moved to /dir2/sock1.
* LSM2 lookup for /dir1/sock1 ==> returns 0
(accepted because /dir1 is the old /dir2 on whose inode LSM2 accepts the permission)
The race is not detected because the inode of the resolved socket is
the same for all three lookups.
At all points during the file renaming logic, sock1 stayed under the
inode of the original /dir1 or the inode of the original /dir2. The
connection is supposed to be denied because for both of these
directories, one of the two LSMs should deny connections to sockets
that are stored therein.
## Example scenario 2 (only one LSM)
I just realize that a similar scenario also already applies to the
simpler case where there is *only* the Landlock LSM and the af_unix.c
lookup. Bear with me, this is a bit of a wild scenario, but it shows
that the scheme of comparing the looked-up inode does not work:
* The directories /dir1 and /dir2 exist.
* On /dir1, the unprivileged user has Unix permissions but the LSM
denies access to sockets underneath based on the directories'
inode.
* On /dir2, the unprivileged user has *no* Unix permissions, but the
LSM accepts access to sockets underneath, based on the dir inode.
* The socket /dir1/sock is a hardlink to /dir2/sock
* Assume there is a highly privileged service that constantly invokes
renameat2() with RENAME_EXCHANGE, exchaning the two directories back
and forth.
Now the following operations happen:
* initial unix_find_bsd() lookup for /dir1/sock
* We get lucky and catch the inode where we get through Unix
permission checks
* Race:
* /dir1 and /dir2 get exchanged atomically
* LSM lookup for /dir1/sock
* Now /dir1 is the inode where the LSM passes the LSM check
So we end up passing both checks because a rename() happened in between.
At any given point in time, the directory through which we accessed
the socket was either /dir1 or /dir2, and we lacked either the Unix
permissions or the LSM policy should deny it. Yet, because of this
rename race, we manage to sneak through both checks.
The inode comparison for the looked up inode does not catch it,
because that is only the "sock" inode, and does not cover the other
inodes along the path.
The example is a bit artificial to make it clear, but it nevertheless
shows that in race scenarios, the behaviour can still be different
(and permit more access) than in the sceneario there is only a single
path lookup.
> > * Would have to double check the unix_dgram_connect code paths in
> > af_unix to see whether this is feasible for DGRAM sockets:
> >
> > There is a way to connect() a connectionless DGRAM socket, and in
> > that case, the path lookup in af_unix happens normally only during
> > connect(),
>
> Note that connected DGRAM socket can send() data to other sockets
> by specifying the peer name in each send(), and even they can
> disconnect by connect(AF_UNSPEC).
Yup. (That case would have been easier, I think, because the two
lookups would have been closer to each other.)
> > very far apart from the initial security_unix_may_send()
> > LSM hook which is used for DGRAM sockets - It would be weird if we
> > were able to connect() a DGRAM socket, thinking that now all path
> > lookups are done, but then when you try to send a message through
> > it, Landlock surprisingly does the path lookup again based on a very
> > old and possibly outdated path. If Landlock's path lookup fails
> > (e.g. because the path has disappeared, or because the inode now
> > differs), retries won't be able to recover this any more. Normally,
> > the path does not need to get resolved any more once the DGRAM
> > socket is connected.
> >
> > Noteworthy: When Unix servers restart, they commonly unlink the old
> > socket inode in the same place and create a new one with bind(). So
> > as the time window for the race increases, it is actually a common
> > scenario that a different inode with appear under the same path.
> >
> > I have to digest this idea a bit. I find it less intuitive than using
> > the exact same struct path with a newly introduced hook, but it does
> > admittedly mitigate the problem somewhat. I'm just not feeling very
> > comfortable with security policy code that requires difficult
> > reasoning. 🤔 Or maybe I interpreted too much into your suggestion. :)
> > I'd be interested to hear what you think.
> >
> > —Günther
As the above second example showed, when we do two path lookups, one
in af_unix and one in Landlock, even if we compare the resulting
socket inode to catch the TOCTOU, there are scenarios where the
resulting observable behaviour is different (and sometimes more lax)
than if there was only a single path lookup.
Given that, I'd be leaning towards the original proposal of adding new
LSM hook, provided that Paul and the respective network maintainers
are OK with it.
Thanks for bringing it up though. It was an interesting exploration
to think through these scenarios.
Thanks,
–Günther
^ permalink raw reply
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Mickaël Salaün @ 2026-01-08 18:42 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: Günther Noack, Justin Suess, Paul Moore, James Morris,
Serge E . Hallyn, Simon Horman, linux-security-module,
Tingmao Wang, netdev, Alexander Viro, Christian Brauner
In-Reply-To: <CAAVpQUAd==+Pw02+E6UC-qwaDNm7aFg+Q9YDbWzyniShAkAhFQ@mail.gmail.com>
On Thu, Jan 08, 2026 at 02:17:05AM -0800, Kuniyuki Iwashima wrote:
> On Wed, Jan 7, 2026 at 4:49 AM Günther Noack <gnoack@google.com> wrote:
> >
> > On Tue, Jan 06, 2026 at 11:33:32PM -0800, Kuniyuki Iwashima wrote:
> > > +VFS maintainers
> > >
> > > On Mon, Jan 5, 2026 at 3:04 AM Günther Noack <gnoack@google.com> wrote:
> > > >
> > > > Hello!
> > > >
> > > > On Sun, Jan 04, 2026 at 11:46:46PM -0800, Kuniyuki Iwashima wrote:
> > > > > On Wed, Dec 31, 2025 at 1:33 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > > Motivation
> > > > > > ---
> > > > > >
> > > > > > For AF_UNIX sockets bound to a filesystem path (aka named sockets), one
> > > > > > identifying object from a policy perspective is the path passed to
> > > > > > connect(2). However, this operation currently restricts LSMs that rely
> > > > > > on VFS-based mediation, because the pathname resolved during connect()
> > > > > > is not preserved in a form visible to existing hooks before connection
> > > > > > establishment.
> > > > >
> > > > > Why can't LSM use unix_sk(other)->path in security_unix_stream_connect()
> > > > > and security_unix_may_send() ?
> > > >
> > > > Thanks for bringing it up!
> > > >
> > > > That path is set by the process that acts as the listening side for
> > > > the socket. The listening and the connecting process might not live
> > > > in the same mount namespace, and in that case, it would not match the
> > > > path which is passed by the client in the struct sockaddr_un.
> > >
> > > Thanks for the explanation !
> > >
> > > So basically what you need is resolving unix_sk(sk)->addr.name
> > > by kern_path() and comparing its d_backing_inode(path.dentry)
> > > with d_backing_inode (unix_sk(sk)->path.dendtry).
I would definitely prefer to avoid any kind of hack to try to detect
potential race conditions. :) I think it would also be more difficult
to maintain.
A well-defined hook would avoid race conditions by design, simplify
kernel code, and document the security check.
> > >
> > > If the new hook is only used by Landlock, I'd prefer doing that on
> > > the existing connect() hooks.
I guess other security modules would like to rely on that too.
> >
> > I've talked about that in the "Alternative: Use existing LSM hooks" section in
> > https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
> >
> > If we resolve unix_sk(sk)->addr.name ourselves in the Landlock hook
> > again, we would resolve the path twice: Once in unix_find_bsd() in
> > net/unix/af_unix.c (the Time-Of-Use), and once in the Landlock
> > security hook for the connect() operation (the Time-Of-Check).
> >
> > If I understand you correctly, you are suggesting that we check that
> > the inode resolved by af_unix
> > (d_backing_inode(unix_sk(sk)->path.dentry)) is the same as the one
> > that we resolve in Landlock ourselves, and therefore we can detect the
> > TOCTOU race and pretend that this is equivalent to the case where
> > af_unix resolved to the same inode with the path that Landlock
> > observed?
> >
> > If the walked file system hierarchy changes in between these two
> > accesses, Landlock enforces the policy based on path elements that
> > have changed in between.
> >
> > * We start with a Landlock policy where Unix connect() is restricted
> > by default, but is permitted on "foo/bar2" and everything underneath
> > it. The hierarchy is:
> >
> > foo/
> > bar/
> > baz.sock
> > bar2/ <--- Landlock rule: socket connect() allowed here and below
> >
> > * We connect() to the path "foo/bar/baz.sock"
> > * af_unix.c path lookup resolves "foo/bar/baz.sock" (TOU)
> > This works because Landlock is not checked at this point yet.
> > * In between the two lookups:
> > * the directory foo/bar gets renamed to foo/bar.old
> > * foo/bar2 gets moved to foo/bar
> > * baz.sock gets moved into the (new) foo/bar directory
> > * Landlock check: path lookup of "foo/bar/baz.sock" (TOC)
> > and subsequent policy check using the resolved path.
> >
> > This succeeds because connect() is permitted on foo/bar2 and
> > beneath. We also check that the resolved inode is the same as the
> > one resolved by af_unix.c.
> >
> > And now the reasoning is basically that this is fine because the
> > (inode) result of the two lookups was the same and we pretend that the
> > Landlock path lookup was the one where the actual permission check was
> > done?
>
> Right. IIUC, even in your patch, the file could be renamed
> while LSM is checking the path, no ?
Yes but that should not be an issue wrt to the security policy. The
check should atomic and consistent with the unix socket path resolution
used by the network stack. In fact, comparing paths would potentially
forbid such rename, whereas this might be legitimate.
> I think holding the
> path ref does not lock concurrent rename operations.
We cannot hold a path ref without potential VFS issues.
>
> To me, it's not a small race and basically it's the same with
> the ops below,
>
> sk1.bind('test')
> sk1.listen()
> os.rename('test', 'test2')
> sk2.connect('test2')
>
> sk1.bind('test')
> sk1.listen()
> sk2.connect('test1')
> os.rename('test', 'test2')
>
> and the important part is whether the path _was_ the
> allowed one when LSM checked the path.
In the case of Landlock's sandboxing, we want to check the path at
connect time because that's when it makes sense for the client wrt to
its request (and its security policy).
FYI, Landlock identifies paths with a set of inodes, so if the unix
socket is explicitly allowed, then a rename may still be allowed by the
security policy.
>
> >
> > Some pieces of this which I am still unsure about:
> >
> > * What we are supposed to do when the two resolved inodes are not the
> > same, because we detected the race? We can not allow the connection
> > in that case, but it would be wrong to deny it as well. I'm not
> > sure whether returning one of the -ERESTART* variants is feasible in
> > this place and bubbles up correctly to the system call / io_uring
> > layer.
>
> Imagine that the rename ops was done a bit earlier, which is
> before the first lookup in unix_find_bsd(). Then, the socket
> will not be found, and -ECONNREFUSED is returned.
> LSM pcan pretend as such.
Yes but this would be inconsistent with the network stack. It would
introduce a race condition where unix socket cannot be used for
potentially no legitimate reason.
>
>
> >
> > * What if other kinds of permission checks happen on a different
> > lookup code path? (If another stacked LSM had a similar
> > implementation with yet another path lookup based on a different
> > kind of policy, and if a race happened in between, it could at least
> > be possible that for one variant of the path, it would be OK for
> > Landlock but not the other LSM, and for the other variant of the
> > path it would be OK for the other LSM but not Landlock, and then the
> > connection could get accepted even if that would not have been
> > allowed on one of the two paths alone.) I find this a somewhat
> > brittle implementation approach.
>
> Do you mean that the evaluation of the stacked LSMs could
> return 0 if one of them allows it even though other LSMs deny ?
If any LSM returns a non-zero value, then the call stops.
I think what Günther wanted to highlight is that a hook call may lead to
different hook implementation calls, and all these implementations should
be able to return consistent results wrt to other calls.
>
>
> >
> > * Would have to double check the unix_dgram_connect code paths in
> > af_unix to see whether this is feasible for DGRAM sockets:
> >
> > There is a way to connect() a connectionless DGRAM socket, and in
> > that case, the path lookup in af_unix happens normally only during
> > connect(),
>
> Note that connected DGRAM socket can send() data to other sockets
> by specifying the peer name in each send(), and even they can
> disconnect by connect(AF_UNSPEC).
Yes, thanks for pointing this out. It's the duty of LSMs to correctly
handle this case. It is handled by Landlock for abstract unix sockets.
>
>
> > very far apart from the initial security_unix_may_send()
> > LSM hook which is used for DGRAM sockets - It would be weird if we
> > were able to connect() a DGRAM socket, thinking that now all path
> > lookups are done, but then when you try to send a message through
> > it, Landlock surprisingly does the path lookup again based on a very
> > old and possibly outdated path. If Landlock's path lookup fails
> > (e.g. because the path has disappeared, or because the inode now
> > differs), retries won't be able to recover this any more. Normally,
> > the path does not need to get resolved any more once the DGRAM
> > socket is connected.
> >
> > Noteworthy: When Unix servers restart, they commonly unlink the old
> > socket inode in the same place and create a new one with bind(). So
> > as the time window for the race increases, it is actually a common
> > scenario that a different inode with appear under the same path.
> >
> > I have to digest this idea a bit. I find it less intuitive than using
> > the exact same struct path with a newly introduced hook, but it does
> > admittedly mitigate the problem somewhat. I'm just not feeling very
> > comfortable with security policy code that requires difficult
> > reasoning. 🤔 Or maybe I interpreted too much into your suggestion. :)
> > I'd be interested to hear what you think.
> >
> > —Günther
^ permalink raw reply
* Improved guidance for LSM submissions.
From: Dr. Greg @ 2026-01-08 15:46 UTC (permalink / raw)
To: paul; +Cc: linux-security-module
Good morning Paul, I hope this note finds your week going well and you
were able to have enjoyed a pleasant holiday season.
The Linux security community has benefited from your prescriptive
guidelines for the sub-system that you developed when you took over
the maintainership role.
What is not clear in these guidelines is how a virgin LSM should be
structured for initial submission. Moving forward, we believe the
community would benefit from having clear guidance on this issue.
It would be helpful if the guidance covers a submission of 10-15 KLOC
of code and 5-8 compilation units, which seems to cover the average
range of sizes for LSM's that have significant coverage of the event
handlers/hooks.
We will look forward to your reflections and guidance on this issue.
Have a good remainder of the week.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
^ permalink raw reply
* Re: [PATCH v3 5/6] keys/trusted_keys: establish PKWM as a trusted source
From: Jarkko Sakkinen @ 2026-01-08 13:27 UTC (permalink / raw)
To: Srish Srinivasan
Cc: linux-integrity, keyrings, linuxppc-dev, maddy, mpe, npiggin,
christophe.leroy, James.Bottomley, zohar, nayna, rnsastry,
linux-kernel, linux-security-module
In-Reply-To: <20260106150527.446525-6-ssrish@linux.ibm.com>
On Tue, Jan 06, 2026 at 08:35:26PM +0530, Srish Srinivasan wrote:
> The wrapping key does not exist by default and is generated by the
> hypervisor as a part of PKWM initialization. This key is then persisted by
> the hypervisor and is used to wrap trusted keys. These are variable length
> symmetric keys, which in the case of PowerVM Key Wrapping Module (PKWM) are
> generated using the kernel RNG. PKWM can be used as a trust source through
> the following example keyctl commands:
>
> keyctl add trusted my_trusted_key "new 32" @u
>
> Use the wrap_flags command option to set the secure boot requirement for
> the wrapping request through the following keyctl commands
>
> case1: no secure boot requirement. (default)
> keyctl usage: keyctl add trusted my_trusted_key "new 32" @u
> OR
> keyctl add trusted my_trusted_key "new 32 wrap_flags=0x00" @u
>
> case2: secure boot required to in either audit or enforce mode. set bit 0
> keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x01" @u
>
> case3: secure boot required to be in enforce mode. set bit 1
> keyctl usage: keyctl add trusted my_trusted_key "new 32 wrap_flags=0x02" @u
>
> NOTE:
> -> Setting the secure boot requirement is NOT a must.
> -> Only either of the secure boot requirement options should be set. Not
> both.
> -> All the other bits are required to be not set.
> -> Set the kernel parameter trusted.source=pkwm to choose PKWM as the
> backend for trusted keys implementation.
> -> CONFIG_PSERIES_PLPKS must be enabled to build PKWM.
>
> Add PKWM, which is a combination of IBM PowerVM and Power LPAR Platform
> KeyStore, as a new trust source for trusted keys.
>
> Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
> MAINTAINERS | 9 ++
> include/keys/trusted-type.h | 7 +-
> include/keys/trusted_pkwm.h | 22 +++
> security/keys/trusted-keys/Kconfig | 8 ++
> security/keys/trusted-keys/Makefile | 2 +
> security/keys/trusted-keys/trusted_core.c | 6 +-
> security/keys/trusted-keys/trusted_pkwm.c | 168 ++++++++++++++++++++++
> 7 files changed, 220 insertions(+), 2 deletions(-)
> create mode 100644 include/keys/trusted_pkwm.h
> create mode 100644 security/keys/trusted-keys/trusted_pkwm.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a0dd762f5648..ba51eff21a16 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14003,6 +14003,15 @@ S: Supported
> F: include/keys/trusted_dcp.h
> F: security/keys/trusted-keys/trusted_dcp.c
>
> +KEYS-TRUSTED-PLPKS
> +M: Srish Srinivasan <ssrish@linux.ibm.com>
> +M: Nayna Jain <nayna@linux.ibm.com>
> +L: linux-integrity@vger.kernel.org
> +L: keyrings@vger.kernel.org
> +S: Supported
> +F: include/keys/trusted_plpks.h
> +F: security/keys/trusted-keys/trusted_pkwm.c
> +
> KEYS-TRUSTED-TEE
> M: Sumit Garg <sumit.garg@kernel.org>
> L: linux-integrity@vger.kernel.org
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 4eb64548a74f..45c6c538df22 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -19,7 +19,11 @@
>
> #define MIN_KEY_SIZE 32
> #define MAX_KEY_SIZE 128
> -#define MAX_BLOB_SIZE 512
> +#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> +#define MAX_BLOB_SIZE 1152
> +#else
> +#define MAX_BLOB_SIZE 512
> +#endif
> #define MAX_PCRINFO_SIZE 64
> #define MAX_DIGEST_SIZE 64
>
> @@ -46,6 +50,7 @@ struct trusted_key_options {
> uint32_t policydigest_len;
> unsigned char policydigest[MAX_DIGEST_SIZE];
> uint32_t policyhandle;
> + uint16_t wrap_flags;
> };
We should introduce:
void *private;
And hold backend specific fields there.
This patch set does not necessarily have to migrate TPM fields to this
new framework, only start a better convention before this turns into
a chaos.
BR, Jarkko
^ permalink raw reply
* Re: [RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX
From: Mickaël Salaün @ 2026-01-08 12:12 UTC (permalink / raw)
To: Günther Noack
Cc: Demi Marie Obenour, Justin Suess, Tingmao Wang, fahimitahera, hi,
ivanov.mikhail1, jannh, konstantin.meskhidze,
linux-security-module, matthieu, paul, samasth.norway.ananda
In-Reply-To: <20260102.d6870733fe10@gnoack.org>
On Fri, Jan 02, 2026 at 10:53:49AM +0100, Günther Noack wrote:
> On Thu, Jan 01, 2026 at 05:39:26PM -0500, Demi Marie Obenour wrote:
> > On 1/1/26 17:38, Justin Suess wrote:
> > > On 1/1/26 17:19, Tingmao Wang wrote:
> > >> On 1/1/26 22:11, Demi Marie Obenour wrote:
> > >>> On 1/1/26 17:07, Tingmao Wang wrote:
> > >>>
> > >>> (snip)
> > >>>
> > >>>> Looking at this I guess it might also make sense for the kernel side to
> > >>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
> > >>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
> > >>>>
> > >>>> Also, for the sandboxer logic, maybe a better way would be having
> > >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
> > >>>> then another if(!S_ISSOCK) below this that will clear out
> > >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
> > >>> A process might legitimately need to connect to a socket that doesn't
> > >>> exist at the time it sandboxes itself. Therefore, I think it makes
> > >>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
> > >>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
> > >>> directory. This matches the flexibility mount namespaces can achieve.
> > >> Right, I forgot about the fact that we also need it on dirs, apologies.
> > >>
> > >> (But maybe it might still make sense to not allow this on files which are
> > >> neither a socket or a dir? (If the file later gets removed and recreated
> > >> as a socket, the rule would not apply retroactively anyway due to being
> > >> tied to the inode.))
> > > How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.
> >
> > Regular files definitely support ioctls.
>
> The LANDLOCK_ACCESS_FS_IOCTL_DEV right only applies to ioctl(2)
> invocations on device files.
>
>
> > > Sockets seem like a similar case where the operation is only valid for a subset of file types.
> > >
> > > I think we should mirror the existing behavior is for consistency.
> > >
> > > Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).
> >
> > I agree.
>
> I also agree with your interpretation, Justin.
>
> For the record, Landlock's kernel implementation currently groups FS
> access rights into two groups:
>
> - file access rights
> - directory-only rights
>
> When adding a rule, the directory access rights can only be granted on
> a directory inode. The file access rights can be granted on both a
> directory inode and a regular file inode.
>
> It is pointless to grant the CONNECT_UNIX (or IOCTL_DEV) right on a
> file which is not a Unix socket (or device file). But it complicates
> the userspace API if we introduce more special rules there. - Users of
> Landlock would have to keep track of all these special cases and
> mirror the logic, which is error prone. IMHO is is granular enough if
> we differentiate between files and directories as we currently do.
Agreed. We discussed about making it more granular (see the IOCTL patch
series), but it is not worth it. Even the directory/file
differentiation is questionable, but I initially made this decision to
incentivise user space to know if they are dealing with directories or
files because access right inheritance should be carefully managed.
In most cases, when programs sandbox themselves, they should not need to
stat the file because they should already know if it's a file or a
directory; only sandboxers need too check the file type.
>
> For reference, this is documented at
> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
> and the logic is implemented in landlock_append_fs_rule() in fs.c.
>
> (Actually, in the implementation, the IOCTL_DEV right is treated the
> same as one of the ACCESS_FILE rights - I should probably revise that
> documentation: That right does not *directly* apply to a directory
> inode, as directories are not device files. It only inherits down in
> the file system hierarchy. Looking back at earlier versions of the
> IOCTL_DEV patch set, it was different there. I think I missed to keep
> the documentation in-line.)
Indeed
^ permalink raw reply
* Re: [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Jarkko Sakkinen @ 2026-01-08 12:38 UTC (permalink / raw)
To: Jens Wiklander
Cc: Alexandre Belloni, Uwe Kleine-König, Jonathan Corbet,
Sumit Garg, Olivia Mackall, Herbert Xu, Clément Léger,
Ard Biesheuvel, Maxime Coquelin, Alexandre Torgue, Sumit Garg,
Ilias Apalodimas, Jan Kiszka, Sudeep Holla, Christophe JAILLET,
Rafał Miłecki, Michael Chan, Pavan Chebbi,
James Bottomley, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-doc, linux-crypto, linux-rtc, linux-efi, linux-stm32,
linux-arm-kernel, Cristian Marussi, arm-scmi, linux-mips, netdev,
linux-integrity, keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <CAHUa44HqRbCJTXsrTCm0G5iwtkQtq+Si=yOspCjpAn-N2uVSVg@mail.gmail.com>
On Mon, Jan 05, 2026 at 10:16:09AM +0100, Jens Wiklander wrote:
> Hi,
>
> On Thu, Dec 18, 2025 at 5:29 PM Jens Wiklander
> <jens.wiklander@linaro.org> wrote:
> >
> > On Thu, Dec 18, 2025 at 2:53 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > >
> > > On 18/12/2025 08:21:27+0100, Jens Wiklander wrote:
> > > > Hi,
> > > >
> > > > On Mon, Dec 15, 2025 at 3:17 PM Uwe Kleine-König
> > > > <u.kleine-koenig@baylibre.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > the objective of this series is to make tee driver stop using callbacks
> > > > > in struct device_driver. These were superseded by bus methods in 2006
> > > > > (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> > > > > methods.")) but nobody cared to convert all subsystems accordingly.
> > > > >
> > > > > Here the tee drivers are converted. The first commit is somewhat
> > > > > unrelated, but simplifies the conversion (and the drivers). It
> > > > > introduces driver registration helpers that care about setting the bus
> > > > > and owner. (The latter is missing in all drivers, so by using these
> > > > > helpers the drivers become more correct.)
> > > > >
> > > > > v1 of this series is available at
> > > > > https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
> > > > >
> > > > > Changes since v1:
> > > > >
> > > > > - rebase to v6.19-rc1 (no conflicts)
> > > > > - add tags received so far
> > > > > - fix whitespace issues pointed out by Sumit Garg
> > > > > - fix shutdown callback to shutdown and not remove
> > > > >
> > > > > As already noted in v1's cover letter, this series should go in during a
> > > > > single merge window as there are runtime warnings when the series is
> > > > > only applied partially. Sumit Garg suggested to apply the whole series
> > > > > via Jens Wiklander's tree.
> > > > > If this is done the dependencies in this series are honored, in case the
> > > > > plan changes: Patches #4 - #17 depend on the first two.
> > > > >
> > > > > Note this series is only build tested.
> > > > >
> > > > > Uwe Kleine-König (17):
> > > > > tee: Add some helpers to reduce boilerplate for tee client drivers
> > > > > tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> > > > > tee: Adapt documentation to cover recent additions
> > > > > hwrng: optee - Make use of module_tee_client_driver()
> > > > > hwrng: optee - Make use of tee bus methods
> > > > > rtc: optee: Migrate to use tee specific driver registration function
> > > > > rtc: optee: Make use of tee bus methods
> > > > > efi: stmm: Make use of module_tee_client_driver()
> > > > > efi: stmm: Make use of tee bus methods
> > > > > firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> > > > > firmware: arm_scmi: Make use of tee bus methods
> > > > > firmware: tee_bnxt: Make use of module_tee_client_driver()
> > > > > firmware: tee_bnxt: Make use of tee bus methods
> > > > > KEYS: trusted: Migrate to use tee specific driver registration
> > > > > function
> > > > > KEYS: trusted: Make use of tee bus methods
> > > > > tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> > > > > tpm/tpm_ftpm_tee: Make use of tee bus methods
> > > > >
> > > > > Documentation/driver-api/tee.rst | 18 +----
> > > > > drivers/char/hw_random/optee-rng.c | 26 ++----
> > > > > drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
> > > > > drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
> > > > > drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
> > > > > drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
> > > > > drivers/rtc/rtc-optee.c | 27 ++-----
> > > > > drivers/tee/tee_core.c | 84 ++++++++++++++++++++
> > > > > include/linux/tee_drv.h | 12 +++
> > > > > security/keys/trusted-keys/trusted_tee.c | 17 ++--
> > > > > 10 files changed, 164 insertions(+), 138 deletions(-)
> > > > >
> > > > > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > > > > --
> > > > > 2.47.3
> > > > >
> > > >
> > > > Thank you for the nice cleanup, Uwe.
> > > >
> > > > I've applied patch 1-3 to the branch tee_bus_callback_for_6.20 in my
> > > > tree at https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git/
> > > >
> > > > The branch is based on v6.19-rc1, and I'll try to keep it stable for
> > > > others to depend on, if needed. Let's see if we can agree on taking
> > > > the remaining patches via that branch.
> > >
> > > 6 and 7 can go through your branch.
> >
> > Good, I've added them to my branch now.
>
> This entire patch set should go in during a single merge window. I
> will not send any pull request until I'm sure all patches will be
> merged.
>
> So far (if I'm not mistaken), only the patches I've already added to
> next have appeared next. I can take the rest of the patches, too, but
> I need OK for the following:
>
> Jarkko, you seem happy with the following patches
> - KEYS: trusted: Migrate to use tee specific driver registration function
> - KEYS: trusted: Make use of tee bus methods
> - tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> - tpm/tpm_ftpm_tee: Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
I don't mind.
>
> Herbert, you seem happy with the following patches
> - hwrng: optee - Make use of module_tee_client_driver()
> - hwrng: optee - Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
>
> Sudeep, you seem happy with the following patches
> - firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> - firmware: arm_scmi: Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
>
> Michael, Pavan, are you OK with the following patches
> - firmware: tee_bnxt: Make use of module_tee_client_driver()
> - firmware: tee_bnxt: Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
>
> Thanks,
> Jens
BR, Jarkko
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Mickaël Salaün @ 2026-01-08 11:14 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Günther Noack, Tingmao Wang, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <64484ab4-e137-4fd9-9441-a63ccdff1616@gmail.com>
On Fri, Jan 02, 2026 at 01:37:14PM -0500, Demi Marie Obenour wrote:
> On 1/2/26 05:50, Günther Noack wrote:
> > On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
> >> On 1/2/26 05:16, Günther Noack wrote:
> >>> On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
> >>>> On 1/1/26 17:34, Tingmao Wang wrote:
> >>>>> On 1/1/26 22:14, Demi Marie Obenour wrote:
> >>>>>> [...]
> >>>>>> Does this leave directory traversal as the only missing Landlock
> >>>>>> filesystem access control? Ideally Landlock could provide the same
> >>>>>> isolation from the filesystem that mount namespaces do.
> >>>>>
> >>>>> I think that level of isolation would require path walk control - see:
> >>>>> https://github.com/landlock-lsm/linux/issues/9
> >>>>>
> >>>>> (Landlock also doesn't currently control some metadata operations - see
> >>>>> the warning at the end of the "Filesystem flags" section in [1])
> >>>>>
> >>>>> [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
> >>>>
> >>>> Could this replace all of the existing hooks?
> >>>
> >>> If you do not need to distinguish between the different operations
> >>> which Landlock offers access rights for, but you only want to limit
> >>> the visibility of directory hierarchies in the file system, then yes,
> >>> the path walk control described in issue 9 would be sufficient and a
> >>> more complete control.
> >>>
> >>> The path walk control is probably among the more difficult Landlock
> >>> feature requests. A simple implementation would be easy to implement
> >>> technically, but it also requires a new LSM hook which will have to
> >>> get called *during* path lookup, and we'd have to make sure that the
> >>> performance impact stays in check. Path lookup is after all a very
> >>> central facility in a OS kernel.
> >>
> >> What about instead using the inode-based hooks for directory searching?
> >> SELinux can already restrict that.
> >
> > Oh, thanks, good pointer! I was under the impression that this didn't
> > exist yet -- I assume you are referring to the
> > security_inode_follow_link() hook, which is already happening during
> > path resolution?
>
> I'm not familiar with existing LSM hooks, but I do know that SELinux
> enforces checks on searching and reading directories and symlinks.
SELinux uses inode-based hooks, which is not (directly) possible for
Landlock because it is an unprivileged access control, which means it
cannot rely on extended file attributes to define a security policy.
See https://github.com/landlock-lsm/linux/issues/9
>
> > I take it back then. :) If there is prior art, implementing this might
> > be more feasible than I thought.
>
> I think so too!
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: [RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control
From: Mickaël Salaün @ 2026-01-08 11:14 UTC (permalink / raw)
To: Günther Noack
Cc: Demi Marie Obenour, Tingmao Wang, Paul Moore,
linux-security-module, Justin Suess, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Alyssa Ross, Jann Horn, Tahera Fahimi
In-Reply-To: <20260102.ae35fcc3c4d8@gnoack.org>
On Fri, Jan 02, 2026 at 11:25:38AM +0100, Günther Noack wrote:
> On Fri, Jan 02, 2026 at 11:16:33AM +0100, Günther Noack wrote:
> > Regarding the un-restrictable operations, Tingmao's pointers are
> > correct. In the warning box in the documentation, the missing
> > operations that I am aware of are (a) the Unix socket connect()
> > operation, and (b) the symlink lookup which happens implicitly during
> > path traversal and which Landlock and other LSMs can not control
> > through LSM hooks at the moment. (A symlink always gets implicitly
> > resolved during path lookup even when you do not have directory read
> > permissions on the directory where the symlink is.)
>
> I forgot to mention - the error codes returned by Landlock make it
> possible to probe for the presence of files, even when all available
It is not specifically the error codes but the inability to restrict
path resolution.
> FS access rights are denied on a directory. Attempting to open a file
> for reading will return EEXIST if it is missing, but will return
> EACCES if it is denied by Landlock.
>
> gnoack:/tmp/xxx$ ls
> foobar.txt
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat foobar.txt
> cat: foobar.txt: Permission denied
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat nonexistent.txt
> cat: nonexistent.txt: No such file or directory
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/ls
> ls: cannot open directory '.': Permission denied
FYI, there are several ways to infer file presence, and this also work
with other LSMs such as AppArmor and Tomoyo. It is a limitation of
path-based hooks, see https://github.com/landlock-lsm/linux/issues/52
As Tingmao noted, this is part of Landlock's documentation, but it could
be improved.
^ permalink raw reply
* Re: [RFC PATCH 0/1] lsm: Add hook unix_path_connect
From: Kuniyuki Iwashima @ 2026-01-08 10:17 UTC (permalink / raw)
To: Günther Noack
Cc: Justin Suess, Paul Moore, James Morris, Serge E . Hallyn,
Simon Horman, Mickaël Salaün, linux-security-module,
Tingmao Wang, netdev, Alexander Viro, Christian Brauner
In-Reply-To: <aV5WTGvQB0XI8Q_N@google.com>
On Wed, Jan 7, 2026 at 4:49 AM Günther Noack <gnoack@google.com> wrote:
>
> On Tue, Jan 06, 2026 at 11:33:32PM -0800, Kuniyuki Iwashima wrote:
> > +VFS maintainers
> >
> > On Mon, Jan 5, 2026 at 3:04 AM Günther Noack <gnoack@google.com> wrote:
> > >
> > > Hello!
> > >
> > > On Sun, Jan 04, 2026 at 11:46:46PM -0800, Kuniyuki Iwashima wrote:
> > > > On Wed, Dec 31, 2025 at 1:33 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > > Motivation
> > > > > ---
> > > > >
> > > > > For AF_UNIX sockets bound to a filesystem path (aka named sockets), one
> > > > > identifying object from a policy perspective is the path passed to
> > > > > connect(2). However, this operation currently restricts LSMs that rely
> > > > > on VFS-based mediation, because the pathname resolved during connect()
> > > > > is not preserved in a form visible to existing hooks before connection
> > > > > establishment.
> > > >
> > > > Why can't LSM use unix_sk(other)->path in security_unix_stream_connect()
> > > > and security_unix_may_send() ?
> > >
> > > Thanks for bringing it up!
> > >
> > > That path is set by the process that acts as the listening side for
> > > the socket. The listening and the connecting process might not live
> > > in the same mount namespace, and in that case, it would not match the
> > > path which is passed by the client in the struct sockaddr_un.
> >
> > Thanks for the explanation !
> >
> > So basically what you need is resolving unix_sk(sk)->addr.name
> > by kern_path() and comparing its d_backing_inode(path.dentry)
> > with d_backing_inode (unix_sk(sk)->path.dendtry).
> >
> > If the new hook is only used by Landlock, I'd prefer doing that on
> > the existing connect() hooks.
>
> I've talked about that in the "Alternative: Use existing LSM hooks" section in
> https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
>
> If we resolve unix_sk(sk)->addr.name ourselves in the Landlock hook
> again, we would resolve the path twice: Once in unix_find_bsd() in
> net/unix/af_unix.c (the Time-Of-Use), and once in the Landlock
> security hook for the connect() operation (the Time-Of-Check).
>
> If I understand you correctly, you are suggesting that we check that
> the inode resolved by af_unix
> (d_backing_inode(unix_sk(sk)->path.dentry)) is the same as the one
> that we resolve in Landlock ourselves, and therefore we can detect the
> TOCTOU race and pretend that this is equivalent to the case where
> af_unix resolved to the same inode with the path that Landlock
> observed?
>
> If the walked file system hierarchy changes in between these two
> accesses, Landlock enforces the policy based on path elements that
> have changed in between.
>
> * We start with a Landlock policy where Unix connect() is restricted
> by default, but is permitted on "foo/bar2" and everything underneath
> it. The hierarchy is:
>
> foo/
> bar/
> baz.sock
> bar2/ <--- Landlock rule: socket connect() allowed here and below
>
> * We connect() to the path "foo/bar/baz.sock"
> * af_unix.c path lookup resolves "foo/bar/baz.sock" (TOU)
> This works because Landlock is not checked at this point yet.
> * In between the two lookups:
> * the directory foo/bar gets renamed to foo/bar.old
> * foo/bar2 gets moved to foo/bar
> * baz.sock gets moved into the (new) foo/bar directory
> * Landlock check: path lookup of "foo/bar/baz.sock" (TOC)
> and subsequent policy check using the resolved path.
>
> This succeeds because connect() is permitted on foo/bar2 and
> beneath. We also check that the resolved inode is the same as the
> one resolved by af_unix.c.
>
> And now the reasoning is basically that this is fine because the
> (inode) result of the two lookups was the same and we pretend that the
> Landlock path lookup was the one where the actual permission check was
> done?
Right. IIUC, even in your patch, the file could be renamed
while LSM is checking the path, no ? I think holding the
path ref does not lock concurrent rename operations.
To me, it's not a small race and basically it's the same with
the ops below,
sk1.bind('test')
sk1.listen()
os.rename('test', 'test2')
sk2.connect('test2')
sk1.bind('test')
sk1.listen()
sk2.connect('test1')
os.rename('test', 'test2')
and the important part is whether the path _was_ the
allowed one when LSM checked the path.
>
> Some pieces of this which I am still unsure about:
>
> * What we are supposed to do when the two resolved inodes are not the
> same, because we detected the race? We can not allow the connection
> in that case, but it would be wrong to deny it as well. I'm not
> sure whether returning one of the -ERESTART* variants is feasible in
> this place and bubbles up correctly to the system call / io_uring
> layer.
Imagine that the rename ops was done a bit earlier, which is
before the first lookup in unix_find_bsd(). Then, the socket
will not be found, and -ECONNREFUSED is returned.
LSM pcan pretend as such.
>
> * What if other kinds of permission checks happen on a different
> lookup code path? (If another stacked LSM had a similar
> implementation with yet another path lookup based on a different
> kind of policy, and if a race happened in between, it could at least
> be possible that for one variant of the path, it would be OK for
> Landlock but not the other LSM, and for the other variant of the
> path it would be OK for the other LSM but not Landlock, and then the
> connection could get accepted even if that would not have been
> allowed on one of the two paths alone.) I find this a somewhat
> brittle implementation approach.
Do you mean that the evaluation of the stacked LSMs could
return 0 if one of them allows it even though other LSMs deny ?
>
> * Would have to double check the unix_dgram_connect code paths in
> af_unix to see whether this is feasible for DGRAM sockets:
>
> There is a way to connect() a connectionless DGRAM socket, and in
> that case, the path lookup in af_unix happens normally only during
> connect(),
Note that connected DGRAM socket can send() data to other sockets
by specifying the peer name in each send(), and even they can
disconnect by connect(AF_UNSPEC).
> very far apart from the initial security_unix_may_send()
> LSM hook which is used for DGRAM sockets - It would be weird if we
> were able to connect() a DGRAM socket, thinking that now all path
> lookups are done, but then when you try to send a message through
> it, Landlock surprisingly does the path lookup again based on a very
> old and possibly outdated path. If Landlock's path lookup fails
> (e.g. because the path has disappeared, or because the inode now
> differs), retries won't be able to recover this any more. Normally,
> the path does not need to get resolved any more once the DGRAM
> socket is connected.
>
> Noteworthy: When Unix servers restart, they commonly unlink the old
> socket inode in the same place and create a new one with bind(). So
> as the time window for the race increases, it is actually a common
> scenario that a different inode with appear under the same path.
>
> I have to digest this idea a bit. I find it less intuitive than using
> the exact same struct path with a newly introduced hook, but it does
> admittedly mitigate the problem somewhat. I'm just not feeling very
> comfortable with security policy code that requires difficult
> reasoning. 🤔 Or maybe I interpreted too much into your suggestion. :)
> I'd be interested to hear what you think.
>
> —Günther
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox