* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Jens Axboe @ 2026-06-17 2:44 UTC (permalink / raw)
To: Bryam Vargas
Cc: Mickaël Salaün, Günther Noack,
linux-security-module
In-Reply-To: <20260617022541.328550-1-hexlabsecurity@proton.me>
On 6/16/26 8:25 PM, Bryam Vargas wrote:
> Thanks Jens ? noted, the fix belongs in Landlock. Micka?l has the full
> report.
Indeed - and hence no need to bother anyone else with it by blasting it
wide. I've already explained this multiple times, but on the private
security list, when the occasional AI report comes in on things like
this. Hence why it's a bit tiring to see the same stuff come across,
once again.
For the landlock folks, I'd suggest taking a look at what hooks already
exists (and existed, when landlock was merged) for selinux etc, that'd
be a really good hint on the existing surface covered.
--
Jens Axboe
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Bryam Vargas @ 2026-06-17 2:25 UTC (permalink / raw)
To: Jens Axboe
Cc: Mickaël Salaün, Günther Noack,
linux-security-module
In-Reply-To: <fcfa9bc9-4f7d-478c-90a2-ec4efd4c7d43@kernel.dk>
Thanks Jens — noted, the fix belongs in Landlock. Mickaël has the full report.
Bryam
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-17 2:20 UTC (permalink / raw)
To: Roman Gushchin
Cc: Mickaël Salaün, linux-security-module, sashiko,
Günther Noack
In-Reply-To: <7ia4v7biqe64.fsf@castle.c.googlers.com>
On Tue, Jun 16, 2026 at 7:06 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> Mickaël Salaün <mic@digikod.net> writes:
> > On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> >> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> >> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> >> > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
...
> >> I would suggest enabling Sashiko for the LSM list, but not enabling
> >> the email replies at first. This would allow people to view the
> >> reviews and perhaps make a better informed decision.
>
> I just did this: 611f4cd410d9a7f7ad923a068a6ced455e3a244e , for enabling
> reviews I don't really need maintainers consensus. (I might roll it out
> a bit later)
>
> But when it comes to email policy I do, so I'll just sit and wait here.
Thanks Roman.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Roman Gushchin @ 2026-06-16 23:05 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, linux-security-module, sashiko, Günther Noack
In-Reply-To: <20260616.aiGaim8xie8z@digikod.net>
Mickaël Salaün <mic@digikod.net> writes:
> On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
>> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
>> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
>> > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
>> > > > most of them were valuable. It found issues (security or not), but it
>> > > > requires to go to https://sashiko.dev to find them, which is too easy to
>> > > > forget, and requires additional work from maintainers to copy or point
>> > > > to these reviews. I sent a PR (currently in draft) to enable email
>> > > > replies from Sashiko to the Linux Security Module mailing list (most
>> > > > patches are already reviewed anyway):
>> > > > https://github.com/sashiko-dev/sashiko/pull/278
>> > > >
>> > > > Making such reviews broadly available can improve the quality of patches
>> > > > we receive without much noise, helping for all LSM-related code. We can
>> > > > fine tune some email-related settings if needed.
>> > > >
>> > > > If there are any concern or question, this is the right time to start a
>> > > > discussion.
>> > >
>> > > I recently enabled Sashiko for the SELinux list to trial it there
>> > > first, with the goal of eventually bringing this topic up for the rest
>> > > of the LSM folks on the LSM list.
>> > >
>> > > While I think Sashiko's review comments are generally okay, you should
>> > > have contacted the LSM mailing list folks *before* submitting a PR
>> > > that would cause an automated bot to send email to the LSM list (this
>> > > applies to all automated emails, not just LLM reviews). Please hold
>> > > the PR until you have given people a chance to comment on the issue.
>> >
>> > As I explained just above, the PR is a draft (GitHub specific state for
>> > WIP), so it cannot be merged as-is, but it is useful for reviews and for
>> > LSM folks to get a look if they are interested.
>> >
>> > > Personally, I'm okay with it.
>> >
>> > Looks good. What about waiting a week to get some feedback here and
>> > then ask for a merge of the PR?
>>
>> I would suggest enabling Sashiko for the LSM list, but not enabling
>> the email replies at first. This would allow people to view the
>> reviews and perhaps make a better informed decision.
I just did this: 611f4cd410d9a7f7ad923a068a6ced455e3a244e , for enabling
reviews I don't really need maintainers consensus. (I might roll it out
a bit later)
But when it comes to email policy I do, so I'll just sit and wait here.
Thanks
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Jens Axboe @ 2026-06-16 20:36 UTC (permalink / raw)
To: Bryam Vargas, Mickaël Salaün
Cc: Günther Noack, Paul Moore, Keith Busch, Christoph Hellwig,
Sagi Grimberg, linux-security-module, io-uring, linux-block,
linux-nvme, linux-kernel
In-Reply-To: <20260616201633.275067-1-hexlabsecurity@proton.me>
On 6/16/26 2:16 PM, Bryam Vargas wrote:
> Hello Micka?l, and Landlock / io_uring folks,
>
> A task confined by a Landlock ruleset that grants READ_FILE/WRITE_FILE
> on a block or NVMe character device but withholds
> LANDLOCK_ACCESS_FS_IOCTL_DEV can still reach the device-command
> surface through io_uring IORING_OP_URING_CMD with the IOCTL_DEV check
> bypassed: the request enters the device-command handler (block
> discard, or the NVMe char-device passthrough) where the equivalent
> ioctl(2) is denied. The destructive completion and the NVMe-admin
> surface follow from the code -- see Impact.
I've said this before, but apparently it hasn't been received - this
isn't an io_uring issue. If landlock is missing a hook, then that's on
landlock and they should add it. Other security handlers already have
that. Hence no need to broadcast this to a bunch of lists, it's strictly
a landlock issue.
--
Jens Axboe
^ permalink raw reply
* Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Bryam Vargas @ 2026-06-16 20:16 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Paul Moore, Jens Axboe, Keith Busch,
Christoph Hellwig, Sagi Grimberg, linux-security-module, io-uring,
linux-block, linux-nvme, linux-kernel
Hello Mickaël, and Landlock / io_uring folks,
A task confined by a Landlock ruleset that grants READ_FILE/WRITE_FILE on a block
or NVMe character device but withholds LANDLOCK_ACCESS_FS_IOCTL_DEV can still
reach the device-command surface through io_uring IORING_OP_URING_CMD with the
IOCTL_DEV check bypassed: the request enters the device-command handler (block
discard, or the NVMe char-device passthrough) where the equivalent ioctl(2) is
denied. The destructive completion and the NVMe-admin surface follow from the
code -- see Impact.
Affected
--------
Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
LANDLOCK_ACCESS_FS_IOCTL_DEV (Landlock ABI >= 5, since Linux 6.8) and io_uring
uring_cmd for the device class (block BLOCK_URING_CMD_DISCARD; NVMe passthrough).
Confirmed by source inspection on mainline (v7.1-rc7) and reproduced on Linux
7.0.11 (Landlock ABI 8). The confined task needs a writable fd to a device it is
legitimately allowed to use (e.g. a partition/loop device or an NVMe namespace
passed into a container or granted by the ruleset); no CAP is required to reach
the io_uring path. The gap is structural -- Landlock has never registered a
uring_cmd hook -- so it is present from ABI 5 (Linux 6.8) through current
mainline (v7.1-rc7) and is not a regression tied to a single Fixes: commit.
Root cause
----------
On the ioctl(2) path, the syscall handler in fs/ioctl.c calls
security_file_ioctl() (its only call site on the ioctl(2) path) before
dispatching to do_vfs_ioctl(); that reaches Landlock hook_file_ioctl_common(),
which denies a device ioctl unless the file's
allowed_access holds LANDLOCK_ACCESS_FS_IOCTL_DEV (BLKDISCARD/BLKSECDISCARD/
BLKZEROOUT and NVMe passthrough are not in the is_masked_device_ioctl()
allow-list, so they require the right).
io_uring reaches the same device-command surface by a different producer:
IORING_OP_URING_CMD -> io_uring_cmd() io_uring/uring_cmd.c
-> security_uring_cmd(ioucmd) (the ONLY LSM gate on this path)
-> file->f_op->uring_cmd() e.g. blkdev_uring_cmd() / nvme_ns_chr_uring_cmd()
Landlock's LSM_HOOK_INIT list (security/landlock/fs.c, net.c, task.c) registers
file_ioctl/file_ioctl_compat but no uring_cmd hook -- only SELinux
(selinux_uring_cmd) and Smack (smack_uring_cmd) gate this surface -- so
security_uring_cmd() returns 0 for a Landlocked task and hook_file_ioctl /
IOCTL_DEV is never consulted. For block, blkdev_cmd_discard() is then gated only
by BLK_OPEN_WRITE; for NVMe, nvme_ns_chr_uring_cmd() reaches the admin/IO
passthrough with no security_file_ioctl on the path. There is no shared helper
that re-applies the IOCTL_DEV check.
SELinux and Smack hooking uring_cmd while Landlock does not is the coverage
asymmetry; the Landlock documentation describes IOCTL_DEV as gating ioctl(2) but
does not mention io_uring.
Reproducer
----------
A self-contained PoC is available on request (it needs root only to set up a loop
block device and open it; Landlock enforcement is uid-independent, so the
confined child demonstrates the gap regardless of the setup uid). The child
applies a Landlock ruleset handling READ_FILE|WRITE_FILE|IOCTL_DEV with a rule
granting only READ_FILE|WRITE_FILE on the device, then:
(1) ioctl(fd, BLKDISCARD, range) -> -EACCES (Landlock enforces IOCTL_DEV)
(2) IORING_OP_URING_CMD,
cmd_op = BLOCK_URING_CMD_DISCARD -> reaches the block command handler
Observed on Linux 7.0.11 (Landlock ABI 8):
[1] ioctl(BLKDISCARD) -> ret=-1 errno=13 (Permission denied)
[2] uring_cmd(DISCARD) -> cqe.res=-22 (Invalid argument)
A Landlock denial is always -EACCES; the io_uring path returned -EINVAL, which
originates in a post-authorization check inside the block command handler
(blk_validate_byte_range() in blkdev_cmd_discard()), reached only after
security_uring_cmd() returned 0. So this run demonstrates the authorization
bypass -- the request traversed the LSM gate into the block device-command
handler with no IOCTL_DEV check -- and then failed a parameter check, not an
authorization check. The destructive completion (an authorized discard with a
granularity-aligned range) is the expected behaviour but was not exercised in
this run.
Impact
------
Demonstrated: the LANDLOCK_ACCESS_FS_IOCTL_DEV authorization is bypassed. The
device-command request reaches the block command handler with no Landlock check;
the only remaining gate is BLK_OPEN_WRITE (held, since the policy granted write).
Inferred from the code, not exercised here: an authorized DISCARD with a valid
range completes (DISCARD/secure-erase semantics, destroying on-device data), and
the same missing hook leaves the NVMe char-device uring_cmd surface ungated --
nvme_ns_chr_uring_cmd (namespace device /dev/nvmeXnY) -> nvme_ns_uring_cmd for
NVME_URING_CMD_IO/IO_VEC passthrough, and nvme_dev_uring_cmd (controller device
/dev/nvmeX) for NVME_URING_CMD_ADMIN (format, sanitize, firmware download,
security send) -- both reach f_op->uring_cmd with no Landlock/IOCTL_DEV gate.
So the confirmed finding is a missing authorization (the confined task escapes
its own IOCTL_DEV restriction); the destructive data effect and the NVMe-admin
high-water-mark follow from the code but are not shown in the run above. The
proven authorization bypass alone scores CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
(6.5 Medium) -- S:C because the confined task crosses the Landlock policy
boundary it was placed under, I:H because the bypassed path reaches a handler
whose authorized completion modifies device data. With the device command
completing destructively the projected ceiling is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H (8.4 High), the A:H component
reasoned from the source rather than executed. No memory safety is involved.
Suggested direction
-------------------
Have Landlock register a uring_cmd hook that maps the device command to the same
checks the ioctl path applies (IOCTL_DEV, and truncate where relevant), so a
single chokepoint covers every f_op->uring_cmd provider (block, NVMe, ublk, and
any future one). Mirrors how SELinux/Smack already gate this surface.
I am happy to send a patch for this if you would like.
Best regards,
Bryam Vargas
Independent security researcher, HEXLAB S.A.S., Cali, Colombia
hexlabsecurity@proton.me
^ permalink raw reply
* Landlock: LANDLOCK_ACCESS_NET_CONNECT_TCP bypass via TCP Fast Open
From: Bryam Vargas @ 2026-06-16 20:16 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Matthieu Buffet, Paul Moore, Eric Dumazet,
Neal Cardwell, linux-security-module, netdev, linux-kernel
Hello Mickaël, and Landlock folks,
A task confined by a Landlock ruleset that handles
LANDLOCK_ACCESS_NET_CONNECT_TCP and is denied connecting to a given port can
still establish a TCP connection to that port by using TCP Fast Open, i.e.
sendto(fd, ..., MSG_FASTOPEN, &dst, dstlen) on a fresh stream socket. The
network-egress confinement for TCP connect is silently bypassed.
Affected
--------
Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
the TCP network access rights (Landlock ABI >= 4, since Linux 6.7). Confirmed by
source inspection on mainline (v7.1-rc7) and reproduced on Linux 7.0.11
(Landlock ABI 8). No CONFIG beyond Landlock + IPv4/IPv6 TCP; TCP Fast Open client
is enabled by the per-netns default (net.ipv4.tcp_fastopen has TFO_CLIENT_ENABLE
set), so no sysctl change and no setsockopt are required.
Root cause
----------
LANDLOCK_ACCESS_NET_CONNECT_TCP is enforced only by the socket_connect LSM hook
(hook_socket_connect -> current_check_access_socket). security_socket_connect()
has exactly one call site in the tree, net/socket.c (the connect(2) syscall).
TCP Fast Open performs an implicit connect inside sendmsg:
tcp_sendmsg_locked() net/ipv4/tcp.c (MSG_FASTOPEN branch)
-> tcp_sendmsg_fastopen() net/ipv4/tcp.c
-> __inet_stream_connect(..., is_sendmsg=1) net/ipv4/af_inet.c
-> sk->sk_prot->connect() net/ipv4/af_inet.c -> tcp_v4_connect()
This path establishes the connection to the address taken from msg_name but
never calls security_socket_connect(). The only LSM hook fired on the sendmsg
path is security_socket_sendmsg(), and Landlock registers no socket_sendmsg
hook, so LANDLOCK_ACCESS_NET_CONNECT_TCP is never re-checked. __inet_stream_connect()
itself carries no LSM hook (only the cgroup-BPF pre_connect, a different
mechanism).
Notably the kernel already mediates the analogous AF_UNIX implicit-connect on the
send path via the unix_may_send hook, which Landlock does register
(hook_unix_may_send) -- so the sendmsg-implies-connect pattern is recognized, but
the TCP Fast Open case has no equivalent coverage. The MPTCP fast-open path
(mptcp_sendmsg_fastopen -> __inet_stream_connect) is a second producer of the
same unmediated connect (by source inspection; not separately reproduced).
Reproducer
----------
A self-contained, fully unprivileged PoC is available on request. It forks an
unconfined TFO-capable loopback listener, then in a child applies a Landlock
ruleset handling LANDLOCK_ACCESS_NET_CONNECT_TCP with no allow rule
(landlock_create_ruleset() with handled_access_net =
LANDLOCK_ACCESS_NET_CONNECT_TCP, no landlock_add_rule(), then
landlock_restrict_self(); every TCP connect is denied) and tries the forbidden
port two ways:
(1) connect(fd, &dst) -> -EACCES (Landlock enforces CONNECT_TCP)
(2) sendto(fd2, buf, len, MSG_FASTOPEN, &dst, dstlen)
-> succeeds; the listener accepts the
connection and reads the payload.
Observed on Linux 7.0.11 (Landlock ABI 8):
[1] connect(2) -> ret=-1 errno=13 (Permission denied)
[2] sendto(MSG_FASTOPEN) -> ret=14 errno=0 (OK/queued)
[+] listener ACCEPTED the confined child's connection; payload="..."
connect(2) to the port is denied while sendto(MSG_FASTOPEN) reaches the identical
port and delivers data.
Impact
------
A sandbox that uses LANDLOCK_ACCESS_NET_CONNECT_TCP to restrict outbound TCP
(e.g. to keep a confined component from reaching an internal service or a
metadata endpoint) can be escaped by an unprivileged, self-confined task with no
CAP and no namespace transition -- for any destination port, since the
implicit-connect path never consults the connect hook regardless of address (the
run above shows one port). It is an integrity
bypass of the network-confinement property; no memory safety is involved.
I score it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N (6.5 Medium) -- the
confined task escapes the policy authority that defined its sandbox, a scope
change; 5.5 if you treat the Landlock boundary as the same authority (S:U).
Note on the in-flight UDP series
--------------------------------
The "landlock: Add UDP access control support" series (v5, Matthieu Buffet,
https://lore.kernel.org/r/20260611162107.49278-3-matthieu@buffet.re) adds a
socket_sendmsg hook, hook_socket_sendmsg(), but it returns 0 for non-UDP
sockets:
if (sk_is_udp(sock->sk))
access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
else
return 0;
so a TCP socket using MSG_FASTOPEN still bypasses LANDLOCK_ACCESS_NET_CONNECT_TCP
even after that series lands. It may be most convenient to fix this there.
Suggested direction
-------------------
Re-check LANDLOCK_ACCESS_NET_CONNECT_TCP on the implicit-connect path: either have
the socket_sendmsg hook evaluate CONNECT_TCP for stream sockets when the call
performs an implicit connect (mirroring the AF_UNIX unix_may_send handling), or
place the check inside __inet_stream_connect() so a single chokepoint covers
connect(2), TCP Fast Open, and the MPTCP fast-open sibling.
I am happy to send a patch for this if you would like me to.
Best regards,
Bryam Vargas
Independent security researcher, HEXLAB S.A.S., Cali, Colombia
hexlabsecurity@proton.me
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 19:03 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhQyN3CczsTHG=sJF8G=MqxGL6NO7assuAjuF9K1t-qDmQ@mail.gmail.com>
On Tue, Jun 16, 2026 at 11:23:54AM -0400, Paul Moore wrote:
> On Tue, Jun 16, 2026 at 10:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> > > On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > > > > most of them were valuable. It found issues (security or not), but it
> > > > > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > > > > forget, and requires additional work from maintainers to copy or point
> > > > > > to these reviews. I sent a PR (currently in draft) to enable email
> > > > > > replies from Sashiko to the Linux Security Module mailing list (most
> > > > > > patches are already reviewed anyway):
> > > > > > https://github.com/sashiko-dev/sashiko/pull/278
> > > > > >
> > > > > > Making such reviews broadly available can improve the quality of patches
> > > > > > we receive without much noise, helping for all LSM-related code. We can
> > > > > > fine tune some email-related settings if needed.
> > > > > >
> > > > > > If there are any concern or question, this is the right time to start a
> > > > > > discussion.
> > > > >
> > > > > I recently enabled Sashiko for the SELinux list to trial it there
> > > > > first, with the goal of eventually bringing this topic up for the rest
> > > > > of the LSM folks on the LSM list.
> > > > >
> > > > > While I think Sashiko's review comments are generally okay, you should
> > > > > have contacted the LSM mailing list folks *before* submitting a PR
> > > > > that would cause an automated bot to send email to the LSM list (this
> > > > > applies to all automated emails, not just LLM reviews). Please hold
> > > > > the PR until you have given people a chance to comment on the issue.
> > > >
> > > > As I explained just above, the PR is a draft (GitHub specific state for
> > > > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > > > LSM folks to get a look if they are interested.
> > > >
> > > > > Personally, I'm okay with it.
> > > >
> > > > Looks good. What about waiting a week to get some feedback here and
> > > > then ask for a merge of the PR?
> > >
> > > I would suggest enabling Sashiko for the LSM list, but not enabling
> > > the email replies at first. This would allow people to view the
> > > reviews and perhaps make a better informed decision.
> >
> > The point of this PR and the related discussion is to enable email
> > replies ...
>
> ... and you've heard my opinions on that.
>
> > the reviews are already there.
>
> I don't believe the LSM list is being directly reviewed by sashiko.dev
> at the moment (check the lists drop-down in the web UI). Any
> LSM-posted patches being reviewed are being reviewed due to a CC to a
> sashiko.dev monitored list.
I reiterate my claim that the LSM list is already being reviewed. You
just need to enter an LSM name in the search box to see the reviewed
patch series. They are already categorized by mailing list, only the
drop-down menu doesn't list all of them. For instance, the latest for
AppArmor (neither the LKML nor the LSM mailing list are being explicitly
registered for Sashiko):
https://sashiko.dev/#/patchset/20260613060424.2213712-1-junxiao.chang%40intel.com
>
> > As explained, my motivation for
> > this change is to get reviews, and without emails I suspect almost nobody
> > (will) take a look and that would not even be an experiment. I'm saying
> > that because I forgot several times to take a look and it adds more work
> > to the review/maintenance.
>
> I think it's important to allow people a chance to see what the
> reviews are like before you enable an automated bot on the mailing
> list. I'm sorry you found it cumbersome to check the web UI, but a
> change to what is sent to the mailing list affects more than just you.
>
> Perhaps we do eventually enable sashiko.dev to post to the LSM list,
> as I said before I have no problem with that, but I want to give
> people a chance to look at the Sashiko reviews first and make a more
> informed decision.
Sure, I sent this emails to start this discussion, and we can already
take a look, but I guess a drop-down menu will help. Are you OK to
start with this drop-down menu?
>
> > FWIW, there are currently 41 kernel mailing lists registered:
> > https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
>
> Yes, I think we can all read a configuration file.
>
> > > > Anyway, it would not be written in
> > > > stone, we can update Sashiko config with new PRs.
> > >
> > > It is worth noting that sashiko.dev updates are not immediate, so
> > > there is a delay between a PR being merged and it taking effect.
> >
> > Sure and I don't think it's an issue. It's really easy to filter
> > emails on any MUA if really needed, and I'm sure the Sashiko maintainers
> > would be able to fix things quickly if needed.
>
> I think it's important to understand that not everyone approaches the
> email lists the same way, and something that is a non-issue for you
> might be a larger issue for someone else.
I know, it's not about me.
>
> As a reminder, you are always welcome to create your own list for
> Landlock if you find that the LSM list no longer meets your needs.
> The only thing I ask is that any patches touching/affecting the LSM
> framework are sent to the LSM list and of course any pull requests
> sent to Linus should CC the LSM list.
That would be easier, but that's an option I would prefer to avoid
because I want everyone to benefit form these reviews.
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Serge E. Hallyn @ 2026-06-16 17:14 UTC (permalink / raw)
To: Casey Schaufler
Cc: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn,
linux-security-module, linux-kernel
In-Reply-To: <bdf7591c-4078-4ee5-9e63-e5dc27602fb6@schaufler-ca.com>
On Tue, Jun 16, 2026 at 09:07:40AM -0700, Casey Schaufler wrote:
> On 6/15/2026 1:03 PM, Bill Roberts wrote:
> > The task_prctl hook comment incorrectly described the hook as checking
> > whether a prctl operation is allowed. In reality, the hook exists for
> > LSMs to handle LSM-specific prctl operations.
> >
> > Update the function description and kernel-doc comment to reflect the
> > actual behavior. The old wording appears to have been copied from other
> > permission-check hooks despite differing semantics.
> >
> > Signed-off-by: Bill Roberts <bill.roberts@arm.com>
>
> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Yeah, this is an important distinction, thanks.
Reviewed-by: Serge Hallyn <serge@hallyn.com>
> > ---
> > security/security.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/security/security.c b/security/security.c
> > index 4e999f023651..96e6ef088801 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
> > }
> >
> > /**
> > - * security_task_prctl() - Check if a prctl op is allowed
> > + * security_task_prctl() - Handle an LSM specific prctl call
> > * @option: operation
> > * @arg2: argument
> > * @arg3: argument
> > * @arg4: argument
> > * @arg5: argument
> > *
> > - * Check permission before performing a process control operation on the
> > - * current process.
> > + * Handle lsm specific prctl operations.
> > *
> > * Return: Return -ENOSYS if no-one wanted to handle this op, any other value
> > * to cause prctl() to return immediately with that value.
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Casey Schaufler @ 2026-06-16 16:07 UTC (permalink / raw)
To: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-security-module, linux-kernel, Casey Schaufler
In-Reply-To: <20260615200325.260057-1-bill.roberts@arm.com>
On 6/15/2026 1:03 PM, Bill Roberts wrote:
> The task_prctl hook comment incorrectly described the hook as checking
> whether a prctl operation is allowed. In reality, the hook exists for
> LSMs to handle LSM-specific prctl operations.
>
> Update the function description and kernel-doc comment to reflect the
> actual behavior. The old wording appears to have been copied from other
> permission-check hooks despite differing semantics.
>
> Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> security/security.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 4e999f023651..96e6ef088801 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
> }
>
> /**
> - * security_task_prctl() - Check if a prctl op is allowed
> + * security_task_prctl() - Handle an LSM specific prctl call
> * @option: operation
> * @arg2: argument
> * @arg3: argument
> * @arg4: argument
> * @arg5: argument
> *
> - * Check permission before performing a process control operation on the
> - * current process.
> + * Handle lsm specific prctl operations.
> *
> * Return: Return -ENOSYS if no-one wanted to handle this op, any other value
> * to cause prctl() to return immediately with that value.
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 15:23 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.aiGaim8xie8z@digikod.net>
On Tue, Jun 16, 2026 at 10:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> > On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > > > most of them were valuable. It found issues (security or not), but it
> > > > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > > > forget, and requires additional work from maintainers to copy or point
> > > > > to these reviews. I sent a PR (currently in draft) to enable email
> > > > > replies from Sashiko to the Linux Security Module mailing list (most
> > > > > patches are already reviewed anyway):
> > > > > https://github.com/sashiko-dev/sashiko/pull/278
> > > > >
> > > > > Making such reviews broadly available can improve the quality of patches
> > > > > we receive without much noise, helping for all LSM-related code. We can
> > > > > fine tune some email-related settings if needed.
> > > > >
> > > > > If there are any concern or question, this is the right time to start a
> > > > > discussion.
> > > >
> > > > I recently enabled Sashiko for the SELinux list to trial it there
> > > > first, with the goal of eventually bringing this topic up for the rest
> > > > of the LSM folks on the LSM list.
> > > >
> > > > While I think Sashiko's review comments are generally okay, you should
> > > > have contacted the LSM mailing list folks *before* submitting a PR
> > > > that would cause an automated bot to send email to the LSM list (this
> > > > applies to all automated emails, not just LLM reviews). Please hold
> > > > the PR until you have given people a chance to comment on the issue.
> > >
> > > As I explained just above, the PR is a draft (GitHub specific state for
> > > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > > LSM folks to get a look if they are interested.
> > >
> > > > Personally, I'm okay with it.
> > >
> > > Looks good. What about waiting a week to get some feedback here and
> > > then ask for a merge of the PR?
> >
> > I would suggest enabling Sashiko for the LSM list, but not enabling
> > the email replies at first. This would allow people to view the
> > reviews and perhaps make a better informed decision.
>
> The point of this PR and the related discussion is to enable email
> replies ...
... and you've heard my opinions on that.
> the reviews are already there.
I don't believe the LSM list is being directly reviewed by sashiko.dev
at the moment (check the lists drop-down in the web UI). Any
LSM-posted patches being reviewed are being reviewed due to a CC to a
sashiko.dev monitored list.
> As explained, my motivation for
> this change is to get reviews, and without emails I suspect almost nobody
> (will) take a look and that would not even be an experiment. I'm saying
> that because I forgot several times to take a look and it adds more work
> to the review/maintenance.
I think it's important to allow people a chance to see what the
reviews are like before you enable an automated bot on the mailing
list. I'm sorry you found it cumbersome to check the web UI, but a
change to what is sent to the mailing list affects more than just you.
Perhaps we do eventually enable sashiko.dev to post to the LSM list,
as I said before I have no problem with that, but I want to give
people a chance to look at the Sashiko reviews first and make a more
informed decision.
> FWIW, there are currently 41 kernel mailing lists registered:
> https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
Yes, I think we can all read a configuration file.
> > > Anyway, it would not be written in
> > > stone, we can update Sashiko config with new PRs.
> >
> > It is worth noting that sashiko.dev updates are not immediate, so
> > there is a delay between a PR being merged and it taking effect.
>
> Sure and I don't think it's an issue. It's really easy to filter
> emails on any MUA if really needed, and I'm sure the Sashiko maintainers
> would be able to fix things quickly if needed.
I think it's important to understand that not everyone approaches the
email lists the same way, and something that is a non-issue for you
might be a larger issue for someone else.
As a reminder, you are always welcome to create your own list for
Landlock if you find that the LSM list no longer meets your needs.
The only thing I ask is that any patches touching/affecting the LSM
framework are sent to the LSM list and of course any pull requests
sent to Linus should CC the LSM list.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 14:59 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhRa8DQ-ekrmPQSg2pO9pBFj6GA9DO=x5kguGFTbKKyv7Q@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > > most of them were valuable. It found issues (security or not), but it
> > > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > > forget, and requires additional work from maintainers to copy or point
> > > > to these reviews. I sent a PR (currently in draft) to enable email
> > > > replies from Sashiko to the Linux Security Module mailing list (most
> > > > patches are already reviewed anyway):
> > > > https://github.com/sashiko-dev/sashiko/pull/278
> > > >
> > > > Making such reviews broadly available can improve the quality of patches
> > > > we receive without much noise, helping for all LSM-related code. We can
> > > > fine tune some email-related settings if needed.
> > > >
> > > > If there are any concern or question, this is the right time to start a
> > > > discussion.
> > >
> > > I recently enabled Sashiko for the SELinux list to trial it there
> > > first, with the goal of eventually bringing this topic up for the rest
> > > of the LSM folks on the LSM list.
> > >
> > > While I think Sashiko's review comments are generally okay, you should
> > > have contacted the LSM mailing list folks *before* submitting a PR
> > > that would cause an automated bot to send email to the LSM list (this
> > > applies to all automated emails, not just LLM reviews). Please hold
> > > the PR until you have given people a chance to comment on the issue.
> >
> > As I explained just above, the PR is a draft (GitHub specific state for
> > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > LSM folks to get a look if they are interested.
> >
> > > Personally, I'm okay with it.
> >
> > Looks good. What about waiting a week to get some feedback here and
> > then ask for a merge of the PR?
>
> I would suggest enabling Sashiko for the LSM list, but not enabling
> the email replies at first. This would allow people to view the
> reviews and perhaps make a better informed decision.
The point of this PR and the related discussion is to enable email
replies, the reviews are already there. As explained, my motivation for
this change is to get reviews, and without emails I suspect almost nobody
(will) take a look and that would not even be an experiment. I'm saying
that because I forgot several times to take a look and it adds more work
to the review/maintenance.
FWIW, there are currently 41 kernel mailing lists registered:
https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
>
> > Anyway, it would not be written in
> > stone, we can update Sashiko config with new PRs.
>
> It is worth noting that sashiko.dev updates are not immediate, so
> there is a delay between a PR being merged and it taking effect.
Sure and I don't think it's an issue. It's really easy to filter
emails on any MUA if really needed, and I'm sure the Sashiko maintainers
would be able to fix things quickly if needed.
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 14:11 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.EPh8ked0niko@digikod.net>
On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > > Hi,
> > >
> > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > most of them were valuable. It found issues (security or not), but it
> > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > forget, and requires additional work from maintainers to copy or point
> > > to these reviews. I sent a PR (currently in draft) to enable email
> > > replies from Sashiko to the Linux Security Module mailing list (most
> > > patches are already reviewed anyway):
> > > https://github.com/sashiko-dev/sashiko/pull/278
> > >
> > > Making such reviews broadly available can improve the quality of patches
> > > we receive without much noise, helping for all LSM-related code. We can
> > > fine tune some email-related settings if needed.
> > >
> > > If there are any concern or question, this is the right time to start a
> > > discussion.
> >
> > I recently enabled Sashiko for the SELinux list to trial it there
> > first, with the goal of eventually bringing this topic up for the rest
> > of the LSM folks on the LSM list.
> >
> > While I think Sashiko's review comments are generally okay, you should
> > have contacted the LSM mailing list folks *before* submitting a PR
> > that would cause an automated bot to send email to the LSM list (this
> > applies to all automated emails, not just LLM reviews). Please hold
> > the PR until you have given people a chance to comment on the issue.
>
> As I explained just above, the PR is a draft (GitHub specific state for
> WIP), so it cannot be merged as-is, but it is useful for reviews and for
> LSM folks to get a look if they are interested.
>
> > Personally, I'm okay with it.
>
> Looks good. What about waiting a week to get some feedback here and
> then ask for a merge of the PR?
I would suggest enabling Sashiko for the LSM list, but not enabling
the email replies at first. This would allow people to view the
reviews and perhaps make a better informed decision.
> Anyway, it would not be written in
> stone, we can update Sashiko config with new PRs.
It is worth noting that sashiko.dev updates are not immediate, so
there is a delay between a PR being merged and it taking effect.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v17 03/10] rust: implement `ForeignOwnable` for `Owned`
From: Gary Guo @ 2026-06-16 11:55 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Greg Kroah-Hartman, Dave Ertman, Ira Weiny, Leon Romanovsky,
Paul Moore, Serge Hallyn, Rafael J. Wysocki, David Airlie,
Simona Vetter, Alexander Viro, Christian Brauner, Jan Kara,
Daniel Almeida, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Boqun Feng,
Uladzislau Rezki, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Igor Korotin, Pavel Tikhomirov
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-3-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
> places such as the `XArray`.
>
> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
> implement `ForeignOwnable`.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> rust/kernel/owned.rs | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
> index 456e239e906e..5eacdf327d12 100644
> --- a/rust/kernel/owned.rs
> +++ b/rust/kernel/owned.rs
> @@ -15,6 +15,8 @@
> ptr::NonNull, //
> };
>
> +use kernel::types::ForeignOwnable;
> +
> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
> /// is implemented on types from the C side.
> ///
> @@ -108,6 +110,7 @@ pub trait Ownable {
> ///
> /// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
> /// - The `T` value is pinned.
> +#[repr(transparent)]
AFAIT this `#[repr(transparent)]` isn't actually needed.
> pub struct Owned<T: Ownable> {
> ptr: NonNull<T>,
> }
> @@ -185,3 +188,46 @@ fn drop(&mut self) {
> unsafe { T::release(self.ptr.as_mut()) };
> }
> }
> +
> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
> +// pointer satisfy alignment requirements of `T`.
> +unsafe impl<T: Ownable + 'static> ForeignOwnable for Owned<T> {
You should drop the `'static` bound and put where bound on the GAT below
instead. See how `Box` is doing it.
Best,
Gary
> + const FOREIGN_ALIGN: usize = core::mem::align_of::<Owned<T>>();
> +
> + type Borrowed<'a> = &'a T;
> + type BorrowedMut<'a> = Pin<&'a mut T>;
> +
> + #[inline]
> + fn into_foreign(self) -> *mut kernel::ffi::c_void {
> + let ptr = self.ptr.as_ptr().cast();
> + core::mem::forget(self);
> + ptr
> + }
> +
> + #[inline]
> + unsafe fn from_foreign(ptr: *mut kernel::ffi::c_void) -> Self {
> + Self {
> + // SAFETY: By function safety contract, `ptr` came from
> + // `into_foreign` and cannot be null.
> + ptr: unsafe { NonNull::new_unchecked(ptr.cast()) },
> + }
> + }
> +
> + #[inline]
> + unsafe fn borrow<'a>(ptr: *mut kernel::ffi::c_void) -> Self::Borrowed<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // reference for `'a`.
> + unsafe { &*ptr.cast() }
> + }
> +
> + #[inline]
> + unsafe fn borrow_mut<'a>(ptr: *mut kernel::ffi::c_void) -> Self::BorrowedMut<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // unique reference for `'a`.
> + let inner = unsafe { &mut *ptr.cast() };
> +
> + // SAFETY: We never move out of inner, and we do not hand out mutable
> + // references when `T: !Unpin`.
> + unsafe { Pin::new_unchecked(inner) }
> + }
> +}
^ permalink raw reply
* Re: [PATCH v17 02/10] rust: types: Add Ownable/Owned types
From: Alice Ryhl @ 2026-06-16 11:54 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina, Oliver Mangold
In-Reply-To: <20260604-unique-ref-v17-2-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:14PM +0200, Andreas Hindborg wrote:
> From: Asahi Lina <lina+kernel@asahilina.net>
>
> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
> `AlwaysRefCounted`, this mechanism expects the reference to be unique
> within Rust, and does not allow cloning.
>
> Conceptually, this is similar to a `KBox<T>`, except that it delegates
> resource management to the `T` instead of using a generic allocator.
>
> [ om:
> - Split code into separate file and `pub use` it from types.rs.
> - Make from_raw() and into_raw() public.
> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
> - Usage example/doctest for Ownable/Owned.
> - Fixes to documentation and commit message.
> ]
>
> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> [ Andreas: Updated documentation, examples, and formatting. Change safety
> requirements, safety comments. Use a reference for `release`. ]
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Overall looks good to me, but two nits below. With them fixed:
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> +pub trait Ownable {
> + /// Tear down this `Ownable`.
> + ///
> + /// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
> + /// include freeing the underlying object.
> + ///
> + /// # Safety
> + ///
> + /// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
> + /// be transferred to the `release` method.
> + unsafe fn release(&mut self);
I'd make this take a raw pointer because the pointer can be freed during
the execution of release(), which references don't allow.
> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> index 4329d3c2c2e5..4aec7b699269 100644
> --- a/rust/kernel/types.rs
> +++ b/rust/kernel/types.rs
> @@ -11,6 +11,17 @@
> };
> use pin_init::{PinInit, Wrapper, Zeroable};
>
> +pub use crate::{
> + owned::{
> + Ownable,
> + Owned, //
> + },
> + sync::aref::{
> + ARef,
> + AlwaysRefCounted, //
> + }, //
> +};
We removed the types::ARef re-export, so you shouldn't add it back.
Alice
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Gary Guo @ 2026-06-16 11:52 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Greg Kroah-Hartman, Dave Ertman, Ira Weiny, Leon Romanovsky,
Paul Moore, Serge Hallyn, Rafael J. Wysocki, David Airlie,
Simona Vetter, Alexander Viro, Christian Brauner, Jan Kara,
Daniel Almeida, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Boqun Feng,
Uladzislau Rezki, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Igor Korotin, Pavel Tikhomirov
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/alloc/kbox.rs | 9 +++++++++
> 1 file changed, 9 insertions(+)
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Alice Ryhl @ 2026-06-16 11:50 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:13PM +0200, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 8:49 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhQxHEuznN-xiMJ-LCsz2z-UB0ri6MeMn+Ajyn1WUTDNDw@mail.gmail.com>
On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> >
> > Hi,
> >
> > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > most of them were valuable. It found issues (security or not), but it
> > requires to go to https://sashiko.dev to find them, which is too easy to
> > forget, and requires additional work from maintainers to copy or point
> > to these reviews. I sent a PR (currently in draft) to enable email
> > replies from Sashiko to the Linux Security Module mailing list (most
> > patches are already reviewed anyway):
> > https://github.com/sashiko-dev/sashiko/pull/278
> >
> > Making such reviews broadly available can improve the quality of patches
> > we receive without much noise, helping for all LSM-related code. We can
> > fine tune some email-related settings if needed.
> >
> > If there are any concern or question, this is the right time to start a
> > discussion.
>
> I recently enabled Sashiko for the SELinux list to trial it there
> first, with the goal of eventually bringing this topic up for the rest
> of the LSM folks on the LSM list.
>
> While I think Sashiko's review comments are generally okay, you should
> have contacted the LSM mailing list folks *before* submitting a PR
> that would cause an automated bot to send email to the LSM list (this
> applies to all automated emails, not just LLM reviews). Please hold
> the PR until you have given people a chance to comment on the issue.
As I explained just above, the PR is a draft (GitHub specific state for
WIP), so it cannot be merged as-is, but it is useful for reviews and for
LSM folks to get a look if they are interested.
>
> Personally, I'm okay with it.
Looks good. What about waiting a week to get some feedback here and
then ask for a merge of the PR? Anyway, it would not be written in
stone, we can update Sashiko config with new PRs.
>
> --
> paul-moore.com
>
^ permalink raw reply
* [GIT PULL] selinux/selinux-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: selinux, linux-security-module, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
Linus,
A number of SELinux patches for Linux v7.2, almost all of which are
either minor fixes or hardening patches.
- Additional verifications when loading new SELinux policy
Multiple patches by Christian Göttsche to add additional validations to
the code responsible for loading and parsing SELinux policy as it is
loaded into the kernel.
- Avoid nontransitive comparisons comparisons in our sorting code
Done to prevent unexpected sorting results due to overflow. Qualys
documented a similar issue with glibc:
https://www.qualys.com/2024/01/30/qsort.txt
- Consistently use u16 for SELinux security classes
- Move from page allocations to kmalloc() based allocations
Unfortunately one of these patches had to be reverted, but you should
see a fixed version during the next merge window.
- Move from kmalloc_objs() to kzalloc_objs() in the policy load code
- Reorder sel_kill_sb() slightly to match other pseudo filesystems
- Simplify things with QSTR() instead of QSTR_INIT()
- Minor comment typo fixes
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20260615
for you to fetch changes up to 033182baeab63ce96a6eb8aef1a6cd444fcf9519:
selinux: revert use of __getname() in selinux_genfs_get_sid()
(2026-05-29 11:24:37 -0400)
----------------------------------------------------------------
selinux/stable-7.2 PR 20260615
----------------------------------------------------------------
Christian Göttsche (9):
selinux: avoid nontransitive comparison
selinux: use u16 for security classes
selinux: more strict policy parsing
selinux: check length fields in policies
selinux: check type attr map overflows
selinux: reorder policydb_index()
selinux: beef up isvalid checks
selinux: more strict bounds check
selinux: check for simple types
Kalevi Kolttonen (2):
selinux: comment typo fix in selinuxfs.c
selinux: comment spelling fix in ibpkey.c
Mike Rapoport (Microsoft) (2):
selinux: use k[mz]alloc() to allocate temporary buffers
selinux: hooks: use __getname() to allocate path buffer
Paul Moore (1):
selinux: revert use of __getname() in selinux_genfs_get_sid()
Stephen Smalley (2):
selinux: fix sel_kill_sb()
selinux: switch two allocations to use kzalloc_objs()
Thorsten Blum (1):
selinux: use QSTR() instead of QSTR_INIT() in init_sel_fs
security/selinux/ibpkey.c | 2
security/selinux/include/security.h | 1
security/selinux/selinuxfs.c | 27 +-
security/selinux/ss/avtab.c | 49 +++
security/selinux/ss/avtab.h | 13 +
security/selinux/ss/conditional.c | 39 ++-
security/selinux/ss/constraint.h | 1
security/selinux/ss/ebitmap.c | 27 ++
security/selinux/ss/ebitmap.h | 1
security/selinux/ss/hashtab.h | 4
security/selinux/ss/mls.c | 66 +++--
security/selinux/ss/mls.h | 6
security/selinux/ss/policydb.c | 358 ++++++++++++++++++++++------
security/selinux/ss/policydb.h | 56 +++-
security/selinux/ss/services.c | 13 -
security/selinux/ss/symtab.c | 2
security/selinux/ss/symtab.h | 2
17 files changed, 512 insertions(+), 155 deletions(-)
--
paul-moore.com
^ permalink raw reply
* [GIT PULL] lsm/lsm-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
Linus,
A single LSM framework patch to update the security_inode_listsecurity()
hook to be able to leverage the xattr_list_one() helper function. We
wanted to do this for a while, but we needed to fixup the callers in the
NFS code first. With the NFS code changes shipping in Linux v7.0 and
no one complaining, it seemed a good time to complete the shift.
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
tags/lsm-pr-20260615
for you to fetch changes up to f71ece9712b7712df98871eea9aeb60e49ca5239:
security,fs,nfs,net: update security_inode_listsecurity() interface
(2026-05-01 11:29:33 -0400)
----------------------------------------------------------------
lsm/stable-7.2 PR 20260615
----------------------------------------------------------------
Stephen Smalley (1):
security,fs,nfs,net: update security_inode_listsecurity()
interface
fs/nfs/nfs4proc.c | 7 ++-----
fs/xattr.c | 11 +++++++----
include/linux/lsm_hook_defs.h | 4 ++--
include/linux/security.h | 5 +++--
security/security.c | 16 ++++++++--------
security/selinux/hooks.c | 10 +++-------
security/smack/smack_lsm.c | 13 ++++---------
7 files changed, 29 insertions(+), 37 deletions(-)
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Paul Moore @ 2026-06-15 22:03 UTC (permalink / raw)
To: Aaron Tomlin
Cc: tsbogend, jmorris, serge, mingo, juri.lelli, vincent.guittot,
stephen.smalley.work, casey, longman, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <exlgb3dg2kwxgna6gx2qixexvwjjul7z2ya7npal2gz4jjtr7m@h4oxgd74gsbp>
On Mon, Jun 15, 2026 at 11:22 AM Aaron Tomlin <atomlin@atomlin.com> wrote:
> On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> > On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> > >
> > > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > > event if a requested mask intersects with platform-reserved cores).
> > >
> > > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > > hierarchy per tenant, and constrain them using the cpuset controller,
> > > they should not be able to escape, rendering this event impossible.
> >
> > Hi Peter,
> >
> > You raise a very fair point. The cpuset cgroup controller is indeed the
> > kernel's primary vehicle for spatial enforcement, and under normal
> > circumstances, it successfully prevents a tenant from escaping their
> > designated cores.
> >
> > The cpuset controller does govern resource limits, but does not audit
> > intent. When __sched_setaffinity() is invoked, the kernel compares the
> > requested in_mask against the task's allowed cpuset. If there is only a
> > partial intersection, the kernel silently truncates the requested mask to
> > fit the cpuset, without raising any alarm.
> >
> > The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> > affording operators the visibility to detect, audit, and even reject these
> > violations of intent before the kernel silently sanitises the input.
> >
> > This patch does not seek to replace the cpuset controller, but rather to
> > complement it by providing auditing capabilities.
> >
> > > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > > historical blind spot within the API. The existing LSM hook is invoked
> > > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > > pointer. Consequently, the security module is essentially asked, "Should
> > > > Process A be permitted to alter Process B's affinity?" without being
> > > > informed of the proposed affinity itself. Providing in_mask simply
> > > > furnishes the existing hook with the requisite payload to make an informed
> > > > decision.
> > >
> > > It occurs to me that this same argument would require to also pass in
> > > the new sched_attr, no? That way the LSM can inspect the new policy
> > > before it becomes effective.
> >
> > I agree, the underlying logic does indeed extend perfectly to sched_attr.
> >
> > Presently, the LSM is equally oblivious as to whether a process is
> > requesting a benign transition to SCHED_BATCH, or attempting to escalate
> > its privileges by requesting a real-time policy such as SCHED_FIFO with
> > maximum priority. Just as with the CPU mask, providing the sched_attr
> > payload would rectify this parallel blind spot, allowing BPF policies to
> > inspect and mediate scheduling attributes before they become effective.
> >
> > If you are amenable, I should be more than happy to expand the scope of the
> > forthcoming patch to include this. Alternatively, we could address the
> > sched_attr expansion in a separate, subsequent patch. Personally, I would
> > favour the latter approach, but please do let me know your preference.
> >
> > I very much look forward to hearing Paul's thoughts on whether this aligns
> > with the broader LSM vision.
>
> Hi Paul,
>
> I am writing to politely follow up on the discussion above regarding the
> proposed enhancement to the sched_setaffinity LSM hook.
Generally speaking I wait until all dependencies land in Linus' tree.
I've lost a lot of time in the past sorting out issues only to have
one of the dependencies rejected.
> As you will see from the thread, Peter Zijlstra and I have discussed the
> architectural justification for this change. While the cpuset cgroup
> controller effectively handles spatial enforcement, it silently truncates
> requested affinity masks. Passing the raw in_mask to the LSM hook enables
> security modules (such as the BPF LSM) to audit and mediate the actual
> intent of the request before the kernel sanitises the input, a capability
> that cgroups inherently lack.
The issue of resource control comes up from time to time within the
context of LSMs, and my general comment is that we likely need to see
a more comprehensive approach to what access control on resource
limits would look like from a LSM perspective. We've seen a lot of
quick changes to solve very specific problems, but I have yet to see a
good proposal of what it would look like for a more comprehensive
approach.
There is also another issue to consider: none of the in-tree LSMs
currently use these new parameters, raising questions about their
purpose, maintainability, etc. While this is not necessarily a deal
breaker, it does go along with my comment above about taking a more
holistic view of LSM resource controls.
To summarize, I haven't thought about this too much yet because there
are other fires/patches that don't (currently) have the dependency
issues of this patch. I would also feel a lot better if there was an
in-tree user of this parameter and some discussion of how this might
fit into a more holistic approach to controlling resource limits in
the LSM subsystem.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-15 20:13 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260615.zeinurej8oZ9@digikod.net>
On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Hi,
>
> I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> most of them were valuable. It found issues (security or not), but it
> requires to go to https://sashiko.dev to find them, which is too easy to
> forget, and requires additional work from maintainers to copy or point
> to these reviews. I sent a PR (currently in draft) to enable email
> replies from Sashiko to the Linux Security Module mailing list (most
> patches are already reviewed anyway):
> https://github.com/sashiko-dev/sashiko/pull/278
>
> Making such reviews broadly available can improve the quality of patches
> we receive without much noise, helping for all LSM-related code. We can
> fine tune some email-related settings if needed.
>
> If there are any concern or question, this is the right time to start a
> discussion.
I recently enabled Sashiko for the SELinux list to trial it there
first, with the goal of eventually bringing this topic up for the rest
of the LSM folks on the LSM list.
While I think Sashiko's review comments are generally okay, you should
have contacted the LSM mailing list folks *before* submitting a PR
that would cause an automated bot to send email to the LSM list (this
applies to all automated emails, not just LLM reviews). Please hold
the PR until you have given people a chance to comment on the issue.
Personally, I'm okay with it.
--
paul-moore.com
^ permalink raw reply
* [PATCH] security: clarify task_prctl hook documentation
From: Bill Roberts @ 2026-06-15 20:03 UTC (permalink / raw)
To: Paul Moore, James Morris, Serge E. Hallyn
Cc: casey, Bill Roberts, linux-security-module, linux-kernel
The task_prctl hook comment incorrectly described the hook as checking
whether a prctl operation is allowed. In reality, the hook exists for
LSMs to handle LSM-specific prctl operations.
Update the function description and kernel-doc comment to reflect the
actual behavior. The old wording appears to have been copied from other
permission-check hooks despite differing semantics.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---
security/security.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/security.c b/security/security.c
index 4e999f023651..96e6ef088801 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
}
/**
- * security_task_prctl() - Check if a prctl op is allowed
+ * security_task_prctl() - Handle an LSM specific prctl call
* @option: operation
* @arg2: argument
* @arg3: argument
* @arg4: argument
* @arg5: argument
*
- * Check permission before performing a process control operation on the
- * current process.
+ * Handle lsm specific prctl operations.
*
* Return: Return -ENOSYS if no-one wanted to handle this op, any other value
* to cause prctl() to return immediately with that value.
--
2.54.0
^ permalink raw reply related
* Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-15 15:37 UTC (permalink / raw)
To: linux-security-module; +Cc: sashiko, Roman Gushchin, Günther Noack
Hi,
I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
most of them were valuable. It found issues (security or not), but it
requires to go to https://sashiko.dev to find them, which is too easy to
forget, and requires additional work from maintainers to copy or point
to these reviews. I sent a PR (currently in draft) to enable email
replies from Sashiko to the Linux Security Module mailing list (most
patches are already reviewed anyway):
https://github.com/sashiko-dev/sashiko/pull/278
Making such reviews broadly available can improve the quality of patches
we receive without much noise, helping for all LSM-related code. We can
fine tune some email-related settings if needed.
If there are any concern or question, this is the right time to start a
discussion.
Regards,
Mickaël
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Aaron Tomlin @ 2026-06-15 15:22 UTC (permalink / raw)
To: paul
Cc: tsbogend, paul, jmorris, serge, mingo, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, longman, tj, hannes,
mkoutny, chenridong, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, kprateek.nayak, omosnace, kees, neelx, sean, chjohnst,
steve, mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <6hqq5oxvlcpmjvyns42dy2vtfvvixy7q4xyyjrrn46jrvsx5ar@gkmjsteqlpzd>
On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> >
> > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > event if a requested mask intersects with platform-reserved cores).
> >
> > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > hierarchy per tenant, and constrain them using the cpuset controller,
> > they should not be able to escape, rendering this event impossible.
>
> Hi Peter,
>
> You raise a very fair point. The cpuset cgroup controller is indeed the
> kernel's primary vehicle for spatial enforcement, and under normal
> circumstances, it successfully prevents a tenant from escaping their
> designated cores.
>
> The cpuset controller does govern resource limits, but does not audit
> intent. When __sched_setaffinity() is invoked, the kernel compares the
> requested in_mask against the task's allowed cpuset. If there is only a
> partial intersection, the kernel silently truncates the requested mask to
> fit the cpuset, without raising any alarm.
>
> The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> affording operators the visibility to detect, audit, and even reject these
> violations of intent before the kernel silently sanitises the input.
>
> This patch does not seek to replace the cpuset controller, but rather to
> complement it by providing auditing capabilities.
>
> > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > historical blind spot within the API. The existing LSM hook is invoked
> > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > pointer. Consequently, the security module is essentially asked, "Should
> > > Process A be permitted to alter Process B's affinity?" without being
> > > informed of the proposed affinity itself. Providing in_mask simply
> > > furnishes the existing hook with the requisite payload to make an informed
> > > decision.
> >
> > It occurs to me that this same argument would require to also pass in
> > the new sched_attr, no? That way the LSM can inspect the new policy
> > before it becomes effective.
>
> I agree, the underlying logic does indeed extend perfectly to sched_attr.
>
> Presently, the LSM is equally oblivious as to whether a process is
> requesting a benign transition to SCHED_BATCH, or attempting to escalate
> its privileges by requesting a real-time policy such as SCHED_FIFO with
> maximum priority. Just as with the CPU mask, providing the sched_attr
> payload would rectify this parallel blind spot, allowing BPF policies to
> inspect and mediate scheduling attributes before they become effective.
>
> If you are amenable, I should be more than happy to expand the scope of the
> forthcoming patch to include this. Alternatively, we could address the
> sched_attr expansion in a separate, subsequent patch. Personally, I would
> favour the latter approach, but please do let me know your preference.
>
> I very much look forward to hearing Paul's thoughts on whether this aligns
> with the broader LSM vision.
Hi Paul,
I am writing to politely follow up on the discussion above regarding the
proposed enhancement to the sched_setaffinity LSM hook.
As you will see from the thread, Peter Zijlstra and I have discussed the
architectural justification for this change. While the cpuset cgroup
controller effectively handles spatial enforcement, it silently truncates
requested affinity masks. Passing the raw in_mask to the LSM hook enables
security modules (such as the BPF LSM) to audit and mediate the actual
intent of the request before the kernel sanitises the input, a capability
that cgroups inherently lack.
Furthermore, Peter rightly observed that this reasoning extends naturally
to sched_attr. Presently, the LSM cannot inspect whether a process is
requesting a benign scheduling policy or attempting to escalate to a
real-time priority. I am entirely amenable to addressing this parallel
blind spot, preferably in a subsequent patch.
Before I proceed any further, I would be most grateful for your perspective
as the Security sub-system maintainer. Do you feel this expansion is
acceptable?
As a brief administrative aside, please note that Thomas Bogendoerfer has
already queued the MIPS-specific changes related to this work into the
mips-next tree [1][2].
I look forward to hearing your thoughts.
[1]: https://lore.kernel.org/lkml/psb6pxogv2dlknps4p3sh6rt2h7xuuxkoif6ock5vxfz2jimec@txa6iy65crtb/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=98e37db4a34d3af3fb2f4648295c25b5e40b20e3
Kind regards,
--
Aaron Tomlin
^ 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