* Re: LSM: Whiteout chardev creation sidesteps mknod hook
From: Miklos Szeredi @ 2026-04-14 14:07 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Christian Brauner, Serge Hallyn,
Amir Goldstein, Paul Moore, linux-security-module
In-Reply-To: <20260414.gailoogieGh0@digikod.net>
On Tue, 14 Apr 2026 at 15:42, Mickaël Salaün <mic@digikod.net> wrote:
> BTW, I don't understand why only the renameat2(2) syscall can
> (indirectly) create this file type; why not also unlink(2) or rmdir(2)?
The reason is that the same effect is possible with first creating the
whiteout in the work directory with mknod, then renaming it over the
target. Since the work directory is needed anyway, this spares
filesystems from having to implement yet another overlayfs specific
operation.
Thanks,
Miklos
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Support socket access-control
From: Mickaël Salaün @ 2026-04-14 14:27 UTC (permalink / raw)
To: Mikhail Ivanov
Cc: gnoack, willemdebruijn.kernel, matthieu, linux-security-module,
netdev, netfilter-devel, yusongping, artem.kuzin,
konstantin.meskhidze
In-Reply-To: <ca9b74f3-ce72-1d7f-c922-be1b276b69a8@huawei-partners.com>
On Mon, Apr 13, 2026 at 08:11:48PM +0300, Mikhail Ivanov wrote:
> On 4/8/2026 1:26 PM, Mickaël Salaün wrote:
> > Hi Mikhail,
>
> Hi!
>
> >
> > On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
> > > Hello! This is v4 RFC patch dedicated to socket protocols restriction.
> > >
> > > It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
> > > kernel version.
> > >
> > > Objective
> > > =========
> > > Extend Landlock with a mechanism to restrict any set of protocols in
> > > a sandboxed process.
> > >
> > > Closes: https://github.com/landlock-lsm/linux/issues/6
> > >
> > > Motivation
> > > ==========
> > > Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
> > > fine-grained control of actions for a specific protocol. Any action or
> > > protocol that is not supported by this rule can not be controlled. As a
> > > result, protocols for which fine-grained control is not supported can be
> > > used in a sandboxed system and lead to vulnerabilities or unexpected
> > > behavior.
> > >
> > > Controlling the protocols used will allow to use only those that are
> > > necessary for the system and/or which have fine-grained Landlock control
> > > through others types of rules (e.g. TCP bind/connect control with
> > > `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
> > > `LANDLOCK_RULE_PATH_BENEATH`).
> > >
> > > Consider following examples:
> > > * Server may want to use only TCP sockets for which there is fine-grained
> > > control of bind(2) and connect(2) actions [1].
> > > * System that does not need a network or that may want to disable network
> > > for security reasons (e.g. [2]) can achieve this by restricting the use
> > > of all possible protocols.
> > >
> > > [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
> > > [2] https://cr.yp.to/unix/disablenetwork.html
> > >
> > > Implementation
> > > ==============
> > > This patchset adds control over the protocols used by implementing a
> > > restriction of socket creation. This is possible thanks to the new type
> > > of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
> > > sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
> > > corresponds to user space sockets creation. The key in this rule
> > > corresponds to communication protocol signature from socket(2) syscall.
> >
> > FYI, I sent a new patch series that adds a handled_perm field to
> > rulesets:
> > https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
> > See also the rationale:
> > https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
> >
> > I think that would work well with the socket creation permission. WDYT?
>
> Agreed. AFAICS restrictions of protocols used for communication (eg.TCP)
> will complement restriction of network namespace which sandboxed process
> is pinned by LANDLOCK_PERM_NAMESPACE_ENTER permission.
I mean that socket creation restriction should use the same handled_perm
interface e.g. add a LANDLOCK_PERM_SOCKET_CREATE right with related
LANDLOCK_RULE_SOCKET rule type.
With the first RFC for handled_perm, the related rules (e.g. struct
landlock_socket_attr) don't have an allowed_access field but an
allowed_perm one instead. The related permission would then be
LANDLOCK_PERM_SOCKET_CREATE. WDYT?
>
> >
> > Do you think you'll be able to continue this work or would you like me
> > or Günther to complete the remaining last bits (while of course keeping
> > you as the main author)?
>
> Sorry for the delay. I will finish and send patch series ASAP.
This new version should then be on top of the Landlock namespace and
capability patchset to reuse the handled_perm interface. I plan to send
a new version by the end of the month, but this should not change the
handled_perm interface.
>
> >
> >
> > >
> > > The right to create a socket is checked in the LSM hook which is called
> > > in the __sock_create method. The following user space operations are
> > > subject to this check: socket(2), socketpair(2), io_uring(7).
> > >
> > > `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
> > > performed by accept(2), because created socket is used for messaging
> > > between already existing endpoints.
> > >
> > > Design discussion
> > > ===================
> > > 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
> > >
> > > SCTP socket can be connected to a multiple endpoints (one-to-many
> > > relation). Calling setsockopt(2) on such socket with option
> > > `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
> > > UDP socket. This detach is currently restrictable.
> > >
> > > Same applies for the socketpair(2) syscall. It was noted that denying
> > > usage of socketpair(2) in sandboxed environment may be not meaninful [1].
> > >
> > > Currently both operations use general socket interface to create sockets.
> > > Therefore it's not possible to distinguish between socket(2) and those
> > > operations inside security_socket_create LSM hook which is currently
> > > used for protocols restriction. Providing such separation may require
> > > changes in socket layer (eg. in __sock_create) interface which may not be
> > > acceptable.
> > >
> > > [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
> > >
> > > Code coverage
> > > =============
> > > Code coverage(gcov) report with the launch of all the landlock selftests:
> > > * security/landlock:
> > > lines......: 94.0% (1200 of 1276 lines)
> > > functions..: 95.0% (134 of 141 functions)
> > >
> > > * security/landlock/socket.c:
> > > lines......: 100.0% (56 of 56 lines)
> > > functions..: 100.0% (5 of 5 functions)
> > >
> > > Currently landlock-test-tools fails on mini.kernel_socket test due to lack
> > > of SMC protocol support.
> > >
> > > General changes v3->v4
> > > ======================
> > > * Implementation
> > > * Adds protocol field to landlock_socket_attr.
> > > * Adds protocol masks support via wildcards values in
> > > landlock_socket_attr.
> > > * Changes LSM hook used from socket_post_create to socket_create.
> > > * Changes protocol ranges acceptable by socket rules.
> > > * Adds audit support.
> > > * Changes ABI version to 8.
> > > * Tests
> > > * Adds 5 new tests:
> > > * mini.rule_with_wildcard, protocol_wildcard.access,
> > > mini.ruleset_with_wildcards_overlap:
> > > verify rulesets containing rules with wildcard values.
> > > * tcp_protocol.alias_restriction: verify that Landlock doesn't
> > > perform protocol mappings.
> > > * audit.socket_create: tests audit denial logging.
> > > * Squashes tests corresponding to Landlock rule adding to a single commit.
> > > * Documentation
> > > * Refactors Documentation/userspace-api/landlock.rst.
> > > * Commits
> > > * Rebases on mic-next.
> > > * Refactors commits.
> > >
> > > Previous versions
> > > =================
> > > v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
> > > v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
> > > v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
> > >
> > > Mikhail Ivanov (19):
> > > landlock: Support socket access-control
> > > selftests/landlock: Test creating a ruleset with unknown access
> > > selftests/landlock: Test adding a socket rule
> > > selftests/landlock: Testing adding rule with wildcard value
> > > selftests/landlock: Test acceptable ranges of socket rule key
> > > landlock: Add hook on socket creation
> > > selftests/landlock: Test basic socket restriction
> > > selftests/landlock: Test network stack error code consistency
> > > selftests/landlock: Test overlapped rulesets with rules of protocol
> > > ranges
> > > selftests/landlock: Test that kernel space sockets are not restricted
> > > selftests/landlock: Test protocol mappings
> > > selftests/landlock: Test socketpair(2) restriction
> > > selftests/landlock: Test SCTP peeloff restriction
> > > selftests/landlock: Test that accept(2) is not restricted
> > > lsm: Support logging socket common data
> > > landlock: Log socket creation denials
> > > selftests/landlock: Test socket creation denial log for audit
> > > samples/landlock: Support socket protocol restrictions
> > > landlock: Document socket rule type support
> > >
> > > Documentation/userspace-api/landlock.rst | 48 +-
> > > include/linux/lsm_audit.h | 8 +
> > > include/uapi/linux/landlock.h | 60 +-
> > > samples/landlock/sandboxer.c | 118 +-
> > > security/landlock/Makefile | 2 +-
> > > security/landlock/access.h | 3 +
> > > security/landlock/audit.c | 12 +
> > > security/landlock/audit.h | 1 +
> > > security/landlock/limits.h | 4 +
> > > security/landlock/ruleset.c | 37 +-
> > > security/landlock/ruleset.h | 46 +-
> > > security/landlock/setup.c | 2 +
> > > security/landlock/socket.c | 198 +++
> > > security/landlock/socket.h | 20 +
> > > security/landlock/syscalls.c | 61 +-
> > > security/lsm_audit.c | 4 +
> > > tools/testing/selftests/landlock/base_test.c | 2 +-
> > > tools/testing/selftests/landlock/common.h | 14 +
> > > tools/testing/selftests/landlock/config | 47 +
> > > tools/testing/selftests/landlock/net_test.c | 11 -
> > > .../selftests/landlock/protocols_define.h | 169 +++
> > > .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
> > > 22 files changed, 1990 insertions(+), 46 deletions(-)
> > > create mode 100644 security/landlock/socket.c
> > > create mode 100644 security/landlock/socket.h
> > > create mode 100644 tools/testing/selftests/landlock/protocols_define.h
> > > create mode 100644 tools/testing/selftests/landlock/socket_test.c
> > >
> > >
> > > base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
> > > --
> > > 2.34.1
> > >
> > >
>
^ permalink raw reply
* RE: [syzbot] Monthly lsm report (Apr 2026)
From: Roberto Sassu @ 2026-04-14 15:42 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
syzkaller-bugs@googlegroups.com, syzbot
In-Reply-To: <CAHC9VhTO4z1oPnNK748oTU6H7FcnxL2yzbuqkEKAfsrDV2Rcig@mail.gmail.com>
> From: Paul Moore <paul@paul-moore.com>
> Sent: Tuesday, April 14, 2026 3:59 PM
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> >
> https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> >
> https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
> > <3> 31 Yes INFO: task hung in ima_file_free (4)
> >
> > https://syzkaller.appspot.com/bug?extid=8036326eebe7d0140944
>
> Mimi, Roberto,
>
> If I recall correctly, we've discussed the process measurement issue before,
> and I thought it was being resolved. What is the current status on a fix?
>
> I don't recall discussing the ima_file_free() issue, but it looks like the syzbot
> reports go back to 2024; is there a fix under development for that?
I looked at some of the reports. My impression (can be wrong) is that the
syzbot report involves us also when a filesystem gets stuck.
For example, if you see:
https://syzkaller.appspot.com/text?tag=CrashReport&x=160ddb02580000
PID 6887 cannot progress because iint->mutex is likely held by PID 6895.
The last function I see in PID 6895 is io_schedule() which suggests me
that there is an I/O wait that could not be satisfied. PID 6888 cannot progress
as well because is waiting for jfs_get_block(), but PID 6895 is past that
(possibly holding the needed lock).
Sure, it is possible that there is a lock inversion that I missed, but I didn't
find it yet.
Roberto
> Thanks.
>
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > To disable reminders for individual bugs, reply with the following
> command:
> > #syz set <Ref> no-reminders
> >
> > To change bug's subsystems, reply with:
> > #syz set <Ref> subsystems: new-subsystem
> >
> > You may send multiple commands in a single email message.
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 17:05 UTC (permalink / raw)
To: Jason Gunthorpe, Paul Moore
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module, Casey Schaufler
In-Reply-To: <20260413231920.GS3694781@ziepe.ca>
On 4/13/2026 4:19 PM, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
>> On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>> On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
>>>>> We are not limited to LSM solution, the goal is to intercept commands
>>>>> which are submitted to the FW and "security" bucket sounded right to us.
>>>> Yes, it does sound "security relevant", but without a well defined
>>>> interface/format it is going to be difficult to write a generic LSM to
>>>> have any level of granularity beyond a basic "load firmware"
>>>> permission.
>>> I think to step back a bit, what this is trying to achieve is very
>>> similar to the iptables fwmark/secmark scheme.
>> Points for thinking outside the box a bit, but from what I've seen
>> thus far, it differs from secmark in a few important areas. The
>> secmark concept relies on the admin to configure the network stack to
>> apply secmark labels to network traffic as it flows through the
>> system, the LSM then applies security policy to these packets based on
>> their label. The firmware LSM hooks, at least as I currently
>> understand them, rely on the LSM hook callback to parse the firmware
>> op/request and apply a security policy to the request.
> That was what was proposed because the idea was to combine the
> parse/clasification/decision steps into one eBPF program, but I think
> it can be split up too.
>
>> We've already talked about the first issue, parsing the request, and
>> my suggestion was to make the LSM hook call from within the firmware
>> (the firmware must have some way to call into the kernel/driver code,
>> no?)
> No, that's not workable on so many levels. It is sort of anaologous to
> asking the NIC to call the LSM to apply the secmark while sending the
> packet.
>
> The proper flow has the kernel evaluate the packet/command *before* it
> delivers it to HW, not after.
>
>> so that only the firmware would need to parse the request. If we
>> wanted to adopt a secmark-esque approach, one could develop a second
>> parsing mechanism that would be responsible for assigning a LSM label
>> to the request, and then pass the firmware request to the LSM, but I
>> do worry a bit about the added complexity associated with keeping the
>> parser sync'd with the driver/fw.
> In practice it would be like iptables, the parser would be entirely
> programmed by userspace and there is nothing to keep in sync.
>
>> However, even if we solve the parsing problem, I worry we have
>> another, closely related issue, of having to categorize all of the
>> past, present, and future firmware requests into a set of LSM specific
>> actions.
> Why? secmark doesn't have this issue? The classifer would return the
> same kind of information as secmark, some user provided label that is
> delivered to the LSM policy side.
>
> When I talk about a classifier I mean a user programmable classifer
> like iptables. secmark obviously doesn't raise future looking
> questions (like what if there is httpv3?) nor should this.
Secmark has already failed. As I mentioned before, you can't fit the
label information from more than one LSM in a u32. There's going to have
to be some performance degrading hash-magic invoked to make that happen,
and when I've looked into what it would take I was very unhappy.
>> The past and present requests are just a matter of code,
>> that isn't too worrying, but what do we do about unknown future
>> requests? Beyond simply encoding the request into a operation
>> token/enum/int, what additional information beyond the action type
>> would a LSM need to know to apply a security policy? Would it be
>> reasonable to blindly allow or reject unknown requests? If so, what
>> would break?
> I am proposing something like SECMARK.
>
> Eg from Google:
>
> iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:httpd_packet_t:s0
>
> Which is 'match a packet to see that byte offset XX is 0080 and if so
> tag it with the thing this string describes'
>
> So I'm imagining the same kind of flexability. User provides the
> matching and whatever those strings are. The classifer step is fully
> flexible. No worry about future stuff.
>
> I'm guessing when Casey talks about struct lsm_prop it is related to
> the system_u string?
Yeah, that would be it. Lets say your system supports SELinux and AppArmor.
You'll need to be able to specify an SELinux context, an AppArmor context,
or both. Iptables can't do that because of the limitations of a secmark.
>>> ... Once classified we want this to work with more than SELinux
>>> only, we have a particular interest in the eBPF LSM.
>> One of the design requirements for the LSM framework is that it
>> provides an abstraction layer between the kernel and the underlying
>> security mechanisms implemented by the various LSMs. Some operations
>> will always fall outside the scope of individual LSMs due to their
>> nature, but as a general rule we try to ensure that LSM hooks are
>> useful across multiple LSMs.
> I don't know much about SECMARK but Google is telling me it doesn't
> work with anything but SELinux LSM? We'd just like to avoid this
> pitful and I guess that is why Casey brings up lsm_prop?
Google is wrong. (Imagine that!) Smack uses secmarks. It's one of the
reasons you can't use SELinux and Smack at the same time. There is code
in iptables that implies it only works for SELinux, but it isn't true.
That's why you want an lsm_prop instead of a secid. The limitation of a
secmark is imposed by the IP stack implementation. It would be very
frustrating if you introduced yet another scheme with that limitation.
>>> Following the fwmark example, if there was some programmable in-kernel
>>> function to convert the cmd into a SELinux label would we be able to
>>> enable SELinux following the SECMARK design?
>> As Casey already mentioned, any sort of classifier would need to be
>> able to support multiple LSMs. The only example that comes to mind at
>> the moment is the NetLabel mechanism which translates between
>> on-the-wire CIPSO and CALIPSO labels and multiple LSMs (Smack and
>> SELinux currently).
> Ok, I think they can look into that, it is a good lead
Netlabel has a similar issue to secmarks with its use of secids, and
currently supports only a single CIPSO tag in the IP header, making
multiple concurrent LSM support impossible. If you're defining a new
mechanism you can avoid this limitation.
>>> Would there be an objection if that in-kernel function was using a
>>> system-wide eBPF uploaded with some fwctl uAPI?
>> We'd obviously need to see patches, but there is precedent in
>> separating labeling from enforcement. We've discussed SecMark and
>> NetLabel in the networking space, but technically, the VFS/filesystem
>> xattr implementations could also be considered as a labeling mechanism
>> outside of the LSM.
> Makes sense
>
>>> Finally, would there be an objection to enabling the same function in
>>> eBPF by feeding it the entire command and have it classify and make a
>>> security decision in a single eBPF program?
>> Keeping in mind that from an LSM perspective we need to support
>> multiple implementations, both in terms of language mechanics (eBPF,
>> Rust, C) and security philosophies (Smack, SELinux, AppArmor, etc.),
>> so it would be very unlikely that we would want a specific shortcut or
>> mechanism that would only work for one language or philosophy.
> Okay, it is good to understand the sensitivities
>
>>> Is there some other way to enable eBPF?
>> If one develops a workable LSM hook then I see no reason why one
>> couldn't write a BPF LSM to use that hook; that's what we do today.
> I was thinking that too
>
>> However, it seems like direct reuse of secmark isn't what is needed,
>> or even wanted, you were just using that as an example of separating
>> labeling from enforcement, yes?
> Yes, and looking for a coding example to guide implementing it, and to
> recast this discussion to something more concrete. It is very helpful
> to think of this a lot like deep packet inspection and
> classification.
>
> That the packets are delivered to FW and execute commands is not
> actually that important. IP packets are also delivered to remote CPUs
> and execute commands there too <shrug>
>
> At the end of the day the task is the same - deep packet inspection,
> classification. labeling, policy decision, enforcement.
>
> Thanks,
> Jason
>
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 19:09 UTC (permalink / raw)
To: Casey Schaufler
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module
In-Reply-To: <4cf6b20b-f53b-4b5e-ba03-c7ac01bec0c2@schaufler-ca.com>
On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Netlabel has a similar issue to secmarks with its use of secids, and
> currently supports only a single CIPSO tag in the IP header, making
> multiple concurrent LSM support impossible.
That's not correct.
We've talked about this multiple times Casey. The short version is
that while NetLabel doesn't support multiple simultaneous LSMs at the
moment (mostly due to an issue with outbound traffic), this is not due
to some inherent limitation, it is due to the fact that it wasn't
needed when NetLabel was created, and no one has done the (relatively
minor) work to add support since then.
For those of you who are interested in a more detailed explanation,
here ya go ...
NetLabel passes security attributes between itself and various LSMs
through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
is an abstraction not only for the underlying labeling protocols, e.g.
CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
then translate the attributes into their own label representation.
Outbound traffic is a bit more complicated as it involves changing the
state of either a sock, via netlbl_sock_setattr(), or a packet, via
netlbl_skbuff_setattr(), but in both cases we are once again dealing
with netlbl_lsm_secattr struct, not a LSM specific label. Since the
underlying labeling protocol is configured within the NetLabel
subsystem and outside the individual LSMs, there is no worry about
different LSMs requesting different protocol configurations (that is a
separate system/network management issue). The only concern is that
the on-the-wire representation is the same for each LSM that is using
NetLabel based labeling. While some additional work would be
required, it shouldn't be that hard to add NetLabel/protocol code to
ensure the protocol specific labels are the same, and reject/drop the
packet if not.
Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
require some additional work to convert over to a lsm_prop instead of
a u32/secid, but if you look at the caching code that should be
trivial. It might be as simple as adding a lsm_prop to the
netlbl_lsm_secattr::attr struct since the cache stores a full secattr
and not just a u32/secid.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Support socket access-control
From: Mikhail Ivanov @ 2026-04-14 19:45 UTC (permalink / raw)
To: Mickaël Salaün
Cc: gnoack, willemdebruijn.kernel, matthieu, linux-security-module,
netdev, netfilter-devel, yusongping, artem.kuzin,
konstantin.meskhidze
In-Reply-To: <20260414.thaeki1iigeM@digikod.net>
On 4/14/2026 5:27 PM, Mickaël Salaün wrote:
> On Mon, Apr 13, 2026 at 08:11:48PM +0300, Mikhail Ivanov wrote:
>> On 4/8/2026 1:26 PM, Mickaël Salaün wrote:
>>> Hi Mikhail,
>>
>> Hi!
>>
>>>
>>> On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
>>>> Hello! This is v4 RFC patch dedicated to socket protocols restriction.
>>>>
>>>> It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
>>>> kernel version.
>>>>
>>>> Objective
>>>> =========
>>>> Extend Landlock with a mechanism to restrict any set of protocols in
>>>> a sandboxed process.
>>>>
>>>> Closes: https://github.com/landlock-lsm/linux/issues/6
>>>>
>>>> Motivation
>>>> ==========
>>>> Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
>>>> fine-grained control of actions for a specific protocol. Any action or
>>>> protocol that is not supported by this rule can not be controlled. As a
>>>> result, protocols for which fine-grained control is not supported can be
>>>> used in a sandboxed system and lead to vulnerabilities or unexpected
>>>> behavior.
>>>>
>>>> Controlling the protocols used will allow to use only those that are
>>>> necessary for the system and/or which have fine-grained Landlock control
>>>> through others types of rules (e.g. TCP bind/connect control with
>>>> `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
>>>> `LANDLOCK_RULE_PATH_BENEATH`).
>>>>
>>>> Consider following examples:
>>>> * Server may want to use only TCP sockets for which there is fine-grained
>>>> control of bind(2) and connect(2) actions [1].
>>>> * System that does not need a network or that may want to disable network
>>>> for security reasons (e.g. [2]) can achieve this by restricting the use
>>>> of all possible protocols.
>>>>
>>>> [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
>>>> [2] https://cr.yp.to/unix/disablenetwork.html
>>>>
>>>> Implementation
>>>> ==============
>>>> This patchset adds control over the protocols used by implementing a
>>>> restriction of socket creation. This is possible thanks to the new type
>>>> of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
>>>> sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
>>>> corresponds to user space sockets creation. The key in this rule
>>>> corresponds to communication protocol signature from socket(2) syscall.
>>>
>>> FYI, I sent a new patch series that adds a handled_perm field to
>>> rulesets:
>>> https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
>>> See also the rationale:
>>> https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
>>>
>>> I think that would work well with the socket creation permission. WDYT?
>>
>> Agreed. AFAICS restrictions of protocols used for communication (eg.TCP)
>> will complement restriction of network namespace which sandboxed process
>> is pinned by LANDLOCK_PERM_NAMESPACE_ENTER permission.
>
> I mean that socket creation restriction should use the same handled_perm
> interface e.g. add a LANDLOCK_PERM_SOCKET_CREATE right with related
> LANDLOCK_RULE_SOCKET rule type.
Oh, I see your point.
>
> With the first RFC for handled_perm, the related rules (e.g. struct
> landlock_socket_attr) don't have an allowed_access field but an
> allowed_perm one instead. The related permission would then be
> LANDLOCK_PERM_SOCKET_CREATE. WDYT?
Of course, thats reasonable. We haven't come up with reasonable ideas of
access rights for LANDLOCK_RULE_SOCKET except socket creation, so
current patchset will fit in handled_perm design very well.
>
>>
>>>
>>> Do you think you'll be able to continue this work or would you like me
>>> or Günther to complete the remaining last bits (while of course keeping
>>> you as the main author)?
>>
>> Sorry for the delay. I will finish and send patch series ASAP.
>
> This new version should then be on top of the Landlock namespace and
> capability patchset to reuse the handled_perm interface. I plan to send
> a new version by the end of the month, but this should not change the
> handled_perm interface.
OK. I will send RFC v5 based on current design for the review anyway.
>
>>
>>>
>>>
>>>>
>>>> The right to create a socket is checked in the LSM hook which is called
>>>> in the __sock_create method. The following user space operations are
>>>> subject to this check: socket(2), socketpair(2), io_uring(7).
>>>>
>>>> `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
>>>> performed by accept(2), because created socket is used for messaging
>>>> between already existing endpoints.
>>>>
>>>> Design discussion
>>>> ===================
>>>> 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
>>>>
>>>> SCTP socket can be connected to a multiple endpoints (one-to-many
>>>> relation). Calling setsockopt(2) on such socket with option
>>>> `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
>>>> UDP socket. This detach is currently restrictable.
>>>>
>>>> Same applies for the socketpair(2) syscall. It was noted that denying
>>>> usage of socketpair(2) in sandboxed environment may be not meaninful [1].
>>>>
>>>> Currently both operations use general socket interface to create sockets.
>>>> Therefore it's not possible to distinguish between socket(2) and those
>>>> operations inside security_socket_create LSM hook which is currently
>>>> used for protocols restriction. Providing such separation may require
>>>> changes in socket layer (eg. in __sock_create) interface which may not be
>>>> acceptable.
>>>>
>>>> [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
>>>>
>>>> Code coverage
>>>> =============
>>>> Code coverage(gcov) report with the launch of all the landlock selftests:
>>>> * security/landlock:
>>>> lines......: 94.0% (1200 of 1276 lines)
>>>> functions..: 95.0% (134 of 141 functions)
>>>>
>>>> * security/landlock/socket.c:
>>>> lines......: 100.0% (56 of 56 lines)
>>>> functions..: 100.0% (5 of 5 functions)
>>>>
>>>> Currently landlock-test-tools fails on mini.kernel_socket test due to lack
>>>> of SMC protocol support.
>>>>
>>>> General changes v3->v4
>>>> ======================
>>>> * Implementation
>>>> * Adds protocol field to landlock_socket_attr.
>>>> * Adds protocol masks support via wildcards values in
>>>> landlock_socket_attr.
>>>> * Changes LSM hook used from socket_post_create to socket_create.
>>>> * Changes protocol ranges acceptable by socket rules.
>>>> * Adds audit support.
>>>> * Changes ABI version to 8.
>>>> * Tests
>>>> * Adds 5 new tests:
>>>> * mini.rule_with_wildcard, protocol_wildcard.access,
>>>> mini.ruleset_with_wildcards_overlap:
>>>> verify rulesets containing rules with wildcard values.
>>>> * tcp_protocol.alias_restriction: verify that Landlock doesn't
>>>> perform protocol mappings.
>>>> * audit.socket_create: tests audit denial logging.
>>>> * Squashes tests corresponding to Landlock rule adding to a single commit.
>>>> * Documentation
>>>> * Refactors Documentation/userspace-api/landlock.rst.
>>>> * Commits
>>>> * Rebases on mic-next.
>>>> * Refactors commits.
>>>>
>>>> Previous versions
>>>> =================
>>>> v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
>>>> v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
>>>> v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
>>>>
>>>> Mikhail Ivanov (19):
>>>> landlock: Support socket access-control
>>>> selftests/landlock: Test creating a ruleset with unknown access
>>>> selftests/landlock: Test adding a socket rule
>>>> selftests/landlock: Testing adding rule with wildcard value
>>>> selftests/landlock: Test acceptable ranges of socket rule key
>>>> landlock: Add hook on socket creation
>>>> selftests/landlock: Test basic socket restriction
>>>> selftests/landlock: Test network stack error code consistency
>>>> selftests/landlock: Test overlapped rulesets with rules of protocol
>>>> ranges
>>>> selftests/landlock: Test that kernel space sockets are not restricted
>>>> selftests/landlock: Test protocol mappings
>>>> selftests/landlock: Test socketpair(2) restriction
>>>> selftests/landlock: Test SCTP peeloff restriction
>>>> selftests/landlock: Test that accept(2) is not restricted
>>>> lsm: Support logging socket common data
>>>> landlock: Log socket creation denials
>>>> selftests/landlock: Test socket creation denial log for audit
>>>> samples/landlock: Support socket protocol restrictions
>>>> landlock: Document socket rule type support
>>>>
>>>> Documentation/userspace-api/landlock.rst | 48 +-
>>>> include/linux/lsm_audit.h | 8 +
>>>> include/uapi/linux/landlock.h | 60 +-
>>>> samples/landlock/sandboxer.c | 118 +-
>>>> security/landlock/Makefile | 2 +-
>>>> security/landlock/access.h | 3 +
>>>> security/landlock/audit.c | 12 +
>>>> security/landlock/audit.h | 1 +
>>>> security/landlock/limits.h | 4 +
>>>> security/landlock/ruleset.c | 37 +-
>>>> security/landlock/ruleset.h | 46 +-
>>>> security/landlock/setup.c | 2 +
>>>> security/landlock/socket.c | 198 +++
>>>> security/landlock/socket.h | 20 +
>>>> security/landlock/syscalls.c | 61 +-
>>>> security/lsm_audit.c | 4 +
>>>> tools/testing/selftests/landlock/base_test.c | 2 +-
>>>> tools/testing/selftests/landlock/common.h | 14 +
>>>> tools/testing/selftests/landlock/config | 47 +
>>>> tools/testing/selftests/landlock/net_test.c | 11 -
>>>> .../selftests/landlock/protocols_define.h | 169 +++
>>>> .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
>>>> 22 files changed, 1990 insertions(+), 46 deletions(-)
>>>> create mode 100644 security/landlock/socket.c
>>>> create mode 100644 security/landlock/socket.h
>>>> create mode 100644 tools/testing/selftests/landlock/protocols_define.h
>>>> create mode 100644 tools/testing/selftests/landlock/socket_test.c
>>>>
>>>>
>>>> base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
>>>> --
>>>> 2.34.1
>>>>
>>>>
>>
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 20:09 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module,
Casey Schaufler
In-Reply-To: <CAHC9VhTm9MG-NzdwxtqJA6LZeTEsmUjyy8da2=8KOVxgDtEqWQ@mail.gmail.com>
On 4/14/2026 12:09 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> Netlabel has a similar issue to secmarks with its use of secids, and
>> currently supports only a single CIPSO tag in the IP header, making
>> multiple concurrent LSM support impossible.
> That's not correct.
OK, you're right. However ...
>
> We've talked about this multiple times Casey. The short version is
> that while NetLabel doesn't support multiple simultaneous LSMs at the
> moment (mostly due to an issue with outbound traffic), this is not due
> to some inherent limitation, it is due to the fact that it wasn't
> needed when NetLabel was created, and no one has done the (relatively
> minor) work to add support since then.
>
> For those of you who are interested in a more detailed explanation,
> here ya go ...
>
> NetLabel passes security attributes between itself and various LSMs
> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
> is an abstraction not only for the underlying labeling protocols, e.g.
> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
> then translate the attributes into their own label representation.
>
> Outbound traffic is a bit more complicated as it involves changing the
> state of either a sock, via netlbl_sock_setattr(), or a packet, via
> netlbl_skbuff_setattr(), but in both cases we are once again dealing
> with netlbl_lsm_secattr struct, not a LSM specific label. Since the
> underlying labeling protocol is configured within the NetLabel
> subsystem and outside the individual LSMs, there is no worry about
> different LSMs requesting different protocol configurations (that is a
> separate system/network management issue). The only concern is that
> the on-the-wire representation is the same for each LSM that is using
> NetLabel based labeling. While some additional work would be
> required, it shouldn't be that hard to add NetLabel/protocol code to
> ensure the protocol specific labels are the same, and reject/drop the
> packet if not.
Indeed, we've discussed this, and I had at one point implemented it.
The problem is that for any meaningful access control policies you will
never get the two LSMs to agree on a unified network representation.
SELinux transmits the MLS component of the security context. Smack passes
the text of its context. Unless the Smack label is completely in step with
the MLS component of the SELinux context there is no hope of a common
network representation. If a *very talented* sysadmin could create such a
policy, you would have to wonder why, because Smack would be duplicating
the SELinux MLS policy.
So there's really no value in pursuing that approach.
> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
> require some additional work to convert over to a lsm_prop instead of
> a u32/secid, but if you look at the caching code that should be
> trivial. It might be as simple as adding a lsm_prop to the
> netlbl_lsm_secattr::attr struct since the cache stores a full secattr
> and not just a u32/secid.
Indeed. But with no viable users it seems like a lower priority task.
And to be clear, I have no problem with netlabel as written. Multiple tag
support isn't simple (we did it for Trusted IRIX) and the limited space
available for IP options make it tricky.
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 20:27 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module
In-Reply-To: <20260413231920.GS3694781@ziepe.ca>
On Mon, Apr 13, 2026 at 7:19 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> > On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
> > > > > We are not limited to LSM solution, the goal is to intercept commands
> > > > > which are submitted to the FW and "security" bucket sounded right to us.
> > > >
> > > > Yes, it does sound "security relevant", but without a well defined
> > > > interface/format it is going to be difficult to write a generic LSM to
> > > > have any level of granularity beyond a basic "load firmware"
> > > > permission.
> > >
> > > I think to step back a bit, what this is trying to achieve is very
> > > similar to the iptables fwmark/secmark scheme.
> >
> > Points for thinking outside the box a bit, but from what I've seen
> > thus far, it differs from secmark in a few important areas. The
> > secmark concept relies on the admin to configure the network stack to
> > apply secmark labels to network traffic as it flows through the
> > system, the LSM then applies security policy to these packets based on
> > their label. The firmware LSM hooks, at least as I currently
> > understand them, rely on the LSM hook callback to parse the firmware
> > op/request and apply a security policy to the request.
>
> That was what was proposed because the idea was to combine the
> parse/clasification/decision steps into one eBPF program, but I think
> it can be split up too.
>
> > We've already talked about the first issue, parsing the request, and
> > my suggestion was to make the LSM hook call from within the firmware
> > (the firmware must have some way to call into the kernel/driver code,
> > no?)
>
> No, that's not workable on so many levels. It is sort of anaologous to
> asking the NIC to call the LSM to apply the secmark while sending the
> packet.
From the LSM's perspective it really doesn't matter who calls the LSM
hook as long as the caller can be trusted to handle the access control
verdict properly.
> The proper flow has the kernel evaluate the packet/command *before* it
> delivers it to HW, not after.
From what I can see that's an artificial constraint since we've
already chosen to trust the device. After all, if we don't trust the
device, why are we talking to it?
> > so that only the firmware would need to parse the request. If we
> > wanted to adopt a secmark-esque approach, one could develop a second
> > parsing mechanism that would be responsible for assigning a LSM label
> > to the request, and then pass the firmware request to the LSM, but I
> > do worry a bit about the added complexity associated with keeping the
> > parser sync'd with the driver/fw.
>
> In practice it would be like iptables, the parser would be entirely
> programmed by userspace and there is nothing to keep in sync.
You've mentioned a few times now that the firmware/request will vary
across not only devices, but firmware revisions too, this implies
there will need to be some effort to keep whatever parser you develop
(BPF, userspace config, etc.) in sync with the parser built into the
firmware. Or am I misunderstanding something?
> > However, even if we solve the parsing problem, I worry we have
> > another, closely related issue, of having to categorize all of the
> > past, present, and future firmware requests into a set of LSM specific
> > actions.
>
> Why? secmark doesn't have this issue? The classifer would return the
> same kind of information as secmark, some user provided label that is
> delivered to the LSM policy side.
I think there is a misunderstanding in either how secmark works or how
the LSMs use secmark labels when enforcing their security policy.
The secmark label is set on a packet to represent the network
properties of a packet. While the rules governing how a packet's
secmark is set and the semantic meaning of that secmark label is going
to be LSM and solution specific, secmark labels represent the
properties of a packet and not the operation, e.g.
send/receive/forward/etc., being requested at a given access control
point. The access control point itself represents the requested
operation. This is possible because the number of networking
operations on a given packet is well defined and fairly limited; at a
high level the packet is either being sent from the node, received by
the node, or is passing through the node.
As I understand the firmware controls being proposed here, encoded
within the firmware request blob is the operation being requested.
While we've discussed possible solutions on how to parse the request
blob to determine the operation, we haven't really discussed how to
represent the requested operation to the LSMs. I'm assuming there
isn't a well defined set of operations, and like the request format
itself, the set of valid operations will vary from device and firmware
revision. I hope you can understand both how this differs from
secmark and that it is a challenge that really hasn't been addressed
in the proposals we've discussed.
At a very high level the access control decision for firmware/device
requests depends on whether the LSM wants to allow process A to do B
to device C. The identity/credentials associated with process A are
easy to understand, we have plenty of examples both inside and outside
of the LSM on how to do that. The device identity/attributes
associated with device C can be a bit trickier, but once again we have
plenty of examples to draw from, and we can even fall back to a
generic "kernel" id/attribute if the LSM chooses not to distinguish
entities below the userspace/kernel boundary. I think the hardest
issue with the firmware request hooks is going to be determining what
operation is being requested, the "B", portion of access request
tuple. If we can create a well defined set of operations and leave it
to the parser to characterize the operation we've potentially got a
solution, but if the operation is truly going to be arbitrary then we
have a real problem. How do you craft a meaningful access control
policy when you don't understand what is being requested?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Paul Moore @ 2026-04-14 20:44 UTC (permalink / raw)
To: Casey Schaufler
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module
In-Reply-To: <53a532e8-5981-49b4-896e-0bf5021ff78b@schaufler-ca.com>
On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 4/14/2026 12:09 PM, Paul Moore wrote:
> > On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
...
> > For those of you who are interested in a more detailed explanation,
> > here ya go ...
> >
> > NetLabel passes security attributes between itself and various LSMs
> > through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
> > is an abstraction not only for the underlying labeling protocols, e.g.
> > CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
> > NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
> > then translate the attributes into their own label representation.
> >
> > Outbound traffic is a bit more complicated as it involves changing the
> > state of either a sock, via netlbl_sock_setattr(), or a packet, via
> > netlbl_skbuff_setattr(), but in both cases we are once again dealing
> > with netlbl_lsm_secattr struct, not a LSM specific label. Since the
> > underlying labeling protocol is configured within the NetLabel
> > subsystem and outside the individual LSMs, there is no worry about
> > different LSMs requesting different protocol configurations (that is a
> > separate system/network management issue). The only concern is that
> > the on-the-wire representation is the same for each LSM that is using
> > NetLabel based labeling. While some additional work would be
> > required, it shouldn't be that hard to add NetLabel/protocol code to
> > ensure the protocol specific labels are the same, and reject/drop the
> > packet if not.
>
> Indeed, we've discussed this, and I had at one point implemented it.
> The problem is that for any meaningful access control policies you will
> never get the two LSMs to agree on a unified network representation.
That is also not correct. In the early days when SELinux was first
being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used
to interoperate between the systems and it did so quite well despite
the SELinux TE/MLS policy being quite different than the CMW MLS
policies. Yes, there were aspects of the SELinux policy that made
this easier - it had a MLS component after all - but they were still
*very* different policies.
> SELinux transmits the MLS component of the security context. Smack passes
> the text of its context.
Arguably the NetLabel/CIPSO interoperability challenge between SELinux
and Smack is due more to differences in how Smack encodes its security
labels into MLS attributes than from any inherent interop limitation.
In fact, I thought the "cipso2" Smack interface was intended to
resolve this by allowing admins to control how a Smack/CIPSO
translation so that Smack could interop with MLS systems, is that not
the case?
> Unless the Smack label is completely in step with
> the MLS component of the SELinux context there is no hope of a common
> network representation. If a *very talented* sysadmin could create such a
> policy, you would have to wonder why, because Smack would be duplicating
> the SELinux MLS policy.
Interoperability wouldn't be a problem if everyone the "right" systems :D
> > Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
> > require some additional work to convert over to a lsm_prop instead of
> > a u32/secid, but if you look at the caching code that should be
> > trivial. It might be as simple as adding a lsm_prop to the
> > netlbl_lsm_secattr::attr struct since the cache stores a full secattr
> > and not just a u32/secid.
>
> Indeed. But with no viable users it seems like a lower priority task.
You need to be very careful about those "viable users" claims ...
> And to be clear, I have no problem with netlabel as written. Multiple tag
> support isn't simple (we did it for Trusted IRIX) and the limited space
> available for IP options make it tricky.
That's an entirely different problem from the LSM and protocol
abstractions, but yeah.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Casey Schaufler @ 2026-04-14 22:42 UTC (permalink / raw)
To: Paul Moore
Cc: Jason Gunthorpe, Leon Romanovsky, Roberto Sassu, KP Singh,
Matt Bobrowski, Alexei Starovoitov, Daniel Borkmann,
John Fastabend, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, Saeed Mahameed, Itay Avraham,
Dave Jiang, Jonathan Cameron, bpf, linux-kernel, linux-kselftest,
linux-rdma, Chiara Meiohas, Maher Sanalla, linux-security-module,
Casey Schaufler
In-Reply-To: <CAHC9VhRoaECt03Rs-ZyoGhW2_qZkA_1weTYYjiXc41Yf5U8A_g@mail.gmail.com>
On 4/14/2026 1:44 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 4/14/2026 12:09 PM, Paul Moore wrote:
>>> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> For those of you who are interested in a more detailed explanation,
>>> here ya go ...
>>>
>>> NetLabel passes security attributes between itself and various LSMs
>>> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct
>>> is an abstraction not only for the underlying labeling protocols, e.g.
>>> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into
>>> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and
>>> then translate the attributes into their own label representation.
>>>
>>> Outbound traffic is a bit more complicated as it involves changing the
>>> state of either a sock, via netlbl_sock_setattr(), or a packet, via
>>> netlbl_skbuff_setattr(), but in both cases we are once again dealing
>>> with netlbl_lsm_secattr struct, not a LSM specific label. Since the
>>> underlying labeling protocol is configured within the NetLabel
>>> subsystem and outside the individual LSMs, there is no worry about
>>> different LSMs requesting different protocol configurations (that is a
>>> separate system/network management issue). The only concern is that
>>> the on-the-wire representation is the same for each LSM that is using
>>> NetLabel based labeling. While some additional work would be
>>> required, it shouldn't be that hard to add NetLabel/protocol code to
>>> ensure the protocol specific labels are the same, and reject/drop the
>>> packet if not.
>> Indeed, we've discussed this, and I had at one point implemented it.
>> The problem is that for any meaningful access control policies you will
>> never get the two LSMs to agree on a unified network representation.
> That is also not correct. In the early days when SELinux was first
> being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used
> to interoperate between the systems and it did so quite well despite
> the SELinux TE/MLS policy being quite different than the CMW MLS
> policies. Yes, there were aspects of the SELinux policy that made
> this easier - it had a MLS component after all - but they were still
> *very* different policies.
CMW MLS and SELinux MLS can be mapped. They have the same components.
Comparing a full SELinux context and a Smack label is another beast.
>> SELinux transmits the MLS component of the security context. Smack passes
>> the text of its context.
> Arguably the NetLabel/CIPSO interoperability challenge between SELinux
> and Smack is due more to differences in how Smack encodes its security
> labels into MLS attributes than from any inherent interop limitation.
Yes. That is correct. The big issue I see is that SELinux does not represent
the entire context in the CIPSO header. Thus, you're up against many SELinux
contexts having the same wire representation, where Smack will have a unique
on wire for each context. You'll have many-to-one mapping issues.
> In fact, I thought the "cipso2" Smack interface was intended to
> resolve this by allowing admins to control how a Smack/CIPSO
> translation so that Smack could interop with MLS systems, is that not
> the case?
Indeed. A CMW MLS policy is way simpler than an SELinux policy.
>
>> Unless the Smack label is completely in step with
>> the MLS component of the SELinux context there is no hope of a common
>> network representation. If a *very talented* sysadmin could create such a
>> policy, you would have to wonder why, because Smack would be duplicating
>> the SELinux MLS policy.
> Interoperability wouldn't be a problem if everyone the "right" systems :D
Where would the fun in that be? ;)
>
>>> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would
>>> require some additional work to convert over to a lsm_prop instead of
>>> a u32/secid, but if you look at the caching code that should be
>>> trivial. It might be as simple as adding a lsm_prop to the
>>> netlbl_lsm_secattr::attr struct since the cache stores a full secattr
>>> and not just a u32/secid.
>> Indeed. But with no viable users it seems like a lower priority task.
> You need to be very careful about those "viable users" claims ...
Today there are no users. There are other problems (e.g. mount options)
that have yet to be addressed.
>> And to be clear, I have no problem with netlabel as written. Multiple tag
>> support isn't simple (we did it for Trusted IRIX) and the limited space
>> available for IP options make it tricky.
> That's an entirely different problem from the LSM and protocol
> abstractions, but yeah.
>
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:03 UTC (permalink / raw)
To: Srish Srinivasan
Cc: linux-integrity, keyrings, Nayna Jain, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <05c9a2c3-8077-4a1c-87f8-4e240ee1e5c4@linux.ibm.com>
On Fri, Apr 10, 2026 at 11:03:58PM +0530, Srish Srinivasan wrote:
>
> On 4/9/26 9:37 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
> >
> > Cc: Srish Srinivasan <ssrish@linux.ibm.com>
> > Reported-by: Nayna Jain <nayna@linux.ibm.com>
> > Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
>
> Tested on PKWM and emulated TPM backends.
>
> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
Thank you!
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:05 UTC (permalink / raw)
To: Nayna Jain
Cc: linux-integrity, keyrings, Srish Srinivasan, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <129b137c-be9b-4b01-824f-beec7111377c@linux.ibm.com>
On Sun, Apr 12, 2026 at 02:47:20PM -0400, Nayna Jain wrote:
>
> On 4/9/26 12:07 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
>
> Thanks Jarkko. Additional changes looks good to me. I just realized that the
> kernel command-line parameters document may need to be updated to include
> these parameters.
Good point. I will bake that to my PR version of patch. It's low risk as
per corrateral damage. Thanks for pointing this out.
>
> Apart from that, feel free to add my
>
> Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Thank you! These defines have been a huge itch for me for a while :-)
>
> Thanks & Regards,
>
> - Nayna
>
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Mimi Zohar @ 2026-04-15 2:00 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-2-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Refactor asymmetric_verify for reusability. Have it call
> asymmetric_verify_common with the signature verification key and the
> public_key structure as parameters. sigv3 support for ML-DSA will need to
> check the public key type first to decide how to do the signature
> verification and therefore will have these parameters available for
> calling asymmetric_verify_common.
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Thanks, Stefan.
> ---
> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index 6e68ec3becbd..e29ed73f15cd 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
> return key;
> }
>
> -int asymmetric_verify(struct key *keyring, const char *sig,
> - int siglen, const char *data, int datalen)
> +static int asymmetric_verify_common(const struct key *key,
> + const struct public_key *pk,
> + const char *sig, int siglen,
> + const char *data, int datalen)
> {
> - struct public_key_signature pks;
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> - const struct public_key *pk;
> - struct key *key;
> + struct public_key_signature pks;
> int ret;
>
> - if (siglen <= sizeof(*hdr))
> - return -EBADMSG;
> -
> siglen -= sizeof(*hdr);
Normally kernel-doc is unnecessary for static functions. Here, however, since
only the caller verifies the signature length, there should be a kernel-doc
function definition. It should indicate that all callers must verify the
signature length (siglen) and that the public key (pk) is not NULL, before
calling asymmetric_verify_common().
>
> if (siglen != be16_to_cpu(hdr->sig_size))
> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> if (hdr->hash_algo >= HASH_ALGO__LAST)
> return -ENOPKG;
>
> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> - if (IS_ERR(key))
> - return PTR_ERR(key);
> -
> memset(&pks, 0, sizeof(pks));
>
> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>
> - pk = asymmetric_key_public_key(key);
> pks.pkey_algo = pk->pkey_algo;
> if (!strcmp(pk->pkey_algo, "rsa")) {
> pks.encoding = "pkcs1";
> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> pks.s_size = siglen;
> ret = verify_signature(key, &pks);
> out:
> - key_put(key);
The kernel-doc function definition should also indicate that the caller must
free the key.
> pr_debug("%s() = %d\n", __func__, ret);
> return ret;
> }
>
> +int asymmetric_verify(struct key *keyring, const char *sig,
> + int siglen, const char *data, int datalen)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + const struct public_key *pk;
> + struct key *key;
> + int ret;
> +
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
> + pk = asymmetric_key_public_key(key);
Please add a test here making sure pk is not null.
thanks,
Mimi
> +
> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
> +
> + key_put(key);
> +
> + return ret;
> +}
> +
> /*
> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
> * @type: xattr type [enum evm_ima_xattr_type]
^ permalink raw reply
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Mimi Zohar @ 2026-04-15 2:01 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-3-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Add support for sigv3 signature verification using ML-DSA in pure mode.
> When a sigv3 signature is verified, first check whether the key to use
> for verification is an ML-DSA key and therefore uses a hashless signature
> verification scheme. The hashless signature verification method uses the
> ima_file_id structure directly for signature verification rather than
> its digest.
>
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
Thanks, Stefan.
> ---
> v2: Set hash_algo in public_key_signature to "none"
> ---
> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
> 1 file changed, 79 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index e29ed73f15cd..c80cb2b117a6 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
> return rc;
> }
>
> +/*
kernel-doc starts with "/**".
> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
> + * @key: The key to use for signature verification
> + * @pk: The associated public key
> + * @encoding: The encoding the key type uses
> + * @sig: The signature
> + * @siglen: The length of the xattr signature
> + * @algo: The hash algorithm
> + * @digest: The file digest
> + *
> + * Create an ima_file_id structure and use it for signature verification
> + * directly. This can be used for ML-DSA in pure mode for example.
Like the comments on 1/2, please add a comment here indicating that all callers
must verify the signature length (siglen) and the public key (pk) is not NULL,
before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
must free the key.
> + */
> +static int asymmetric_verify_v3_hashless(struct key *key,
> + const struct public_key *pk,
> + const char *encoding,
> + const char *sig, int siglen,
> + u8 algo,
> + const u8 *digest)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + struct ima_file_id file_id = {
> + .hash_type = hdr->type,
> + .hash_algorithm = algo,
> + };
> + size_t digest_size = hash_digest_size[algo];
Defer initializing the digest_size and .m_size, below, until after checking the
hash algorithm is valid.
> + struct public_key_signature pks = {
> + .m = (u8 *)&file_id,
> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
> + .s = hdr->sig,
> + .s_size = siglen - sizeof(*hdr),
> + .pkey_algo = pk->pkey_algo,
> + .hash_algo = "none",
> + .encoding = encoding,
> + };
> + int ret;
> +
> + if (hdr->type != IMA_VERITY_DIGSIG &&
> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
> + return -EINVAL;
> +
> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
> + return -EBADMSG;
> +
> + memcpy(file_id.hash, digest, digest_size);
First check the hash algorithm is valid, before using digest_size.
> +
> + ret = verify_signature(key, &pks);
> + pr_debug("%s() = %d\n", __func__, ret);
> + return ret;
> +}
> +
> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
> const char *data, int datalen, u8 algo)
> {
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> struct ima_max_digest_data hash;
> + const struct public_key *pk;
> + struct key *key;
> int rc;
>
> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> - if (rc)
> - return -EINVAL;
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
>
> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
> - hash.hdr.length);
> + pk = asymmetric_key_public_key(key);
Please add a test to check that 'pk' isn't null.
> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
> + sig, siglen, algo, data);
> + } else {
> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> + if (rc) {
> + rc = -EINVAL;
> + goto err_exit;
> + }
> +
> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
> + hash.hdr.length);
> + }
> +
> +err_exit:
Normally a label named 'err*' would be preceded by a return. Here, the label
"err_exit" is always called, not only when there is an error. Please rename the
label to something more appropriate - out, cleanup, etc.
> + key_put(key);
> +
> + return rc;
> }
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH] trusted-keys: move pr_fmt out of trusted-type.h
From: Jarkko Sakkinen @ 2026-04-15 2:44 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Marco Felsch, Josh Snyder, James Bottomley, Mimi Zohar,
David Howells, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20e9f021-f6b3-4e19-9e1b-93b1e00eb803@pengutronix.de>
On Mon, Apr 13, 2026 at 01:03:30PM +0200, Ahmad Fatoum wrote:
> Hi,
>
> On 4/13/26 1:01 PM, Marco Felsch wrote:
> > Hi Josh,
> >
> > On 26-04-11, Josh Snyder wrote:
> >> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> >> prefix into every translation unit that transitively includes
> >> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
> >>
> >> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
> >>
> >> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> >> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> >> addition, so the regression has been live from the moment the header
> >> gained its own pr_fmt definition.
> >>
> >> Move the pr_fmt definition into the trusted-keys source files that
> >> actually want the prefix.
> >>
> >> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> >> Assisted-by: Claude:claude-opus-4-6
> >> Signed-off-by: Josh Snyder <josh@code406.com>
> >> ---
> >> include/keys/trusted-type.h | 6 ------
> >> security/keys/trusted-keys/trusted_caam.c | 2 ++
> >> security/keys/trusted-keys/trusted_core.c | 2 ++
> >> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> >> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
> >> 7 files changed, 12 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> >> index 03527162613f7..54da1f174aeab 100644
> >> --- a/include/keys/trusted-type.h
> >> +++ b/include/keys/trusted-type.h
> >> @@ -11,12 +11,6 @@
> >> #include <linux/rcupdate.h>
> >> #include <linux/tpm.h>
> >>
> >> -#ifdef pr_fmt
> >> -#undef pr_fmt
> >> -#endif
> >> -
> >> -#define pr_fmt(fmt) "trusted_key: " fmt
> >> -
> >> #define MIN_KEY_SIZE 32
> >> #define MAX_KEY_SIZE 128
> >> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> >> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> >> index 601943ce0d60f..a31fd89c0e5c5 100644
> >> --- a/security/keys/trusted-keys/trusted_caam.c
> >> +++ b/security/keys/trusted-keys/trusted_caam.c
> >> @@ -4,6 +4,8 @@
> >> * Copyright 2025 NXP
> >> */
> >>
> >> +#define pr_fmt(fmt) "trusted_key: " fmt
> >
> > Can we adapt this patch further to include the trusted-key type as well?
> > E.g. 'trusted_key-caam'.
>
> Agreed, if we move it into the individual files, we can use the occasion
> to make it a bit more descriptive.
>
> I would suggest "trusted_key: caam: ", so the prefix stays the same.
>
> Cheers,
> Ahmad
+1
BR, Jarkko
^ permalink raw reply
* Re: [syzbot] Monthly lsm report (Apr 2026)
From: Jarkko Sakkinen @ 2026-04-15 2:51 UTC (permalink / raw)
To: Paul Moore
Cc: David Howells, linux-kernel, linux-security-module,
syzkaller-bugs, syzbot
In-Reply-To: <CAHC9VhS2AaRwAQw1hNcpuGdFSOL7Li9PavKtU7eW-w8eMOFuKA@mail.gmail.com>
On Tue, Apr 14, 2026 at 10:02:13AM -0400, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> > https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> > https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
>
> Jarkko, David,
>
> Do we have a fix for the keyring_clear() issue, or is it not a real problem?
I'll take analyzing this to my todo list for next week (post first PR).
BR, Jarkko
^ permalink raw reply
* [PATCH] ima: Use KEXEC_SIG_FORCE for rejecting unsigned kexec images
From: Chi Wang @ 2026-04-15 10:23 UTC (permalink / raw)
To: zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg
Cc: paul, jmorris, serge, linux-integrity, linux-security-module,
linux-kernel, Chi Wang
From: Chi Wang <wangchi@kylinos.cn>
Following the split of KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE,
only KEXEC_SIG_FORCE indicates that unsigned kernel images must be rejected.
KEXEC_SIG alone enables signature verification but permits unsigned images,
so it should not trigger the IMA appraisal denial for kexec_load.
Update the condition in ima_load_data() to check for KEXEC_SIG_FORCE
instead of KEXEC_SIG.
Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
Signed-off-by: Chi Wang <wangchi@kylinos.cn>
---
security/integrity/ima/ima_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 1d6229b156fb..ec70e78ab8cd 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -953,7 +953,7 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
switch (id) {
case LOADING_KEXEC_IMAGE:
- if (IS_ENABLED(CONFIG_KEXEC_SIG)
+ if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)
&& arch_ima_get_secureboot()) {
pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
return -EACCES;
--
2.25.1
^ permalink raw reply related
* [PATCH v4] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 11:12 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Nayna Jain, Srish Srinivasan, Jonathan Corbet,
Shuah Khan, James Bottomley, Mimi Zohar, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, Ahmad Fatoum,
Pengutronix Kernel Team, Andrew Morton, Borislav Petkov (AMD),
Randy Dunlap, Dave Hansen, Pawan Gupta, Feng Tang, Dapeng Mi,
Kees Cook, Marco Elver, Li RongQing, Paul E. McKenney,
Thomas Gleixner, Bjorn Helgaas, linux-doc, linux-kernel, keyrings,
linux-security-module
TPM_DEBUG, and other similar flags, are a non-standard way to specify a
feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
keys, and use it to replace these ad-hoc feature flags.
Given that trusted keys debug dumps can contain sensitive data, harden the
feature as follows:
1. In the Kconfig description postulate that pr_debug() statements must be
used.
2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
3. Require trusted.debug=1 on the kernel command line (default: 0) to
activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
Traces, when actually needed, can be easily enabled by providing
trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
Reported-by: Nayna Jain <nayna@linux.ibm.com>
Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
v4:
- Added kernel parameter documentation.t
- Added tags from Srishand and Nayna.
- Sanity check round. This version will be applied unless there is
something specific to address.
v3:
- Add kernel-command line option for enabling the traces.
- Add safety information to the Kconfig entry.
v2:
- Implement for all trusted keys backends.
- Add HAVE_TRUSTED_KEYS_DEBUG as it is a good practice despite full
coverage.
---
.../admin-guide/kernel-parameters.txt | 16 +++++++
include/keys/trusted-type.h | 21 +++++----
security/keys/trusted-keys/Kconfig | 23 ++++++++++
security/keys/trusted-keys/trusted_caam.c | 7 ++-
security/keys/trusted-keys/trusted_core.c | 6 +++
security/keys/trusted-keys/trusted_tpm1.c | 44 +++++++++++--------
6 files changed, 87 insertions(+), 30 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2ce1f4975c1..f1515668c8ab 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7917,6 +7917,22 @@ Kernel parameters
first trust source as a backend which is initialized
successfully during iteration.
+ trusted.debug= [KEYS]
+ Format: <bool>
+ Enable trusted keys debug traces at runtime when
+ CONFIG_TRUSTED_KEYS_DEBUG=y.
+
+ To make the traces visible after enabling the option,
+ use trusted.dyndbg='+p' as needed. By convention,
+ the subsystem uses pr_debug() for these traces.
+
+ SAFETY: The traces can leak sensitive data, so be
+ cautious before enabling this. They remain inactive
+ unless this parameter is set this option to a true
+ value.
+
+ Default: false
+
trusted.rng= [KEYS]
Format: <string>
The RNG used to generate key material for trusted keys.
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 03527162613f..9f9940482da4 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -83,18 +83,21 @@ struct trusted_key_source {
extern struct key_type key_type_trusted;
-#define TRUSTED_DEBUG 0
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
+extern bool trusted_debug;
-#if TRUSTED_DEBUG
static inline void dump_payload(struct trusted_key_payload *p)
{
- pr_info("key_len %d\n", p->key_len);
- print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
- 16, 1, p->key, p->key_len, 0);
- pr_info("bloblen %d\n", p->blob_len);
- print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
- 16, 1, p->blob, p->blob_len, 0);
- pr_info("migratable %d\n", p->migratable);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("key_len %d\n", p->key_len);
+ print_hex_dump_debug("key ", DUMP_PREFIX_NONE,
+ 16, 1, p->key, p->key_len, 0);
+ pr_debug("bloblen %d\n", p->blob_len);
+ print_hex_dump_debug("blob ", DUMP_PREFIX_NONE,
+ 16, 1, p->blob, p->blob_len, 0);
+ pr_debug("migratable %d\n", p->migratable);
}
#else
static inline void dump_payload(struct trusted_key_payload *p)
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index 9e00482d886a..e5a4a53aeab2 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -1,10 +1,29 @@
config HAVE_TRUSTED_KEYS
bool
+config HAVE_TRUSTED_KEYS_DEBUG
+ bool
+
+config TRUSTED_KEYS_DEBUG
+ bool "Debug trusted keys"
+ depends on HAVE_TRUSTED_KEYS_DEBUG
+ default n
+ help
+ Trusted key backends and core code that support debug traces can
+ opt-in that feature here. Traces must only use debug level output, as
+ sensitive data may pass by. In the kernel-command line traces can be
+ enabled via trusted.dyndbg='+p'.
+
+ SAFETY: Debug dumps are inactive at runtime until trusted.debug is set
+ to a true value on the kernel command-line. Use at your utmost
+ consideration when enabling this feature on a production build. The
+ general advice is not to do this.
+
config TRUSTED_KEYS_TPM
bool "TPM-based trusted keys"
depends on TCG_TPM >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select CRYPTO_HASH_INFO
select CRYPTO_LIB_SHA1
select CRYPTO_LIB_UTILS
@@ -23,6 +42,7 @@ config TRUSTED_KEYS_TEE
bool "TEE-based trusted keys"
depends on TEE >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of the Trusted Execution Environment (TEE) as trusted
@@ -33,6 +53,7 @@ config TRUSTED_KEYS_CAAM
depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of NXP's Cryptographic Accelerator and Assurance Module
@@ -42,6 +63,7 @@ config TRUSTED_KEYS_DCP
bool "DCP-based trusted keys"
depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
@@ -50,6 +72,7 @@ config TRUSTED_KEYS_PKWM
bool "PKWM-based trusted keys"
depends on PSERIES_PLPKS >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of IBM PowerVM Key Wrapping Module (PKWM) as a trusted key backend.
diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
index 601943ce0d60..6a33dbf2a7f5 100644
--- a/security/keys/trusted-keys/trusted_caam.c
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -28,10 +28,13 @@ static const match_table_t key_tokens = {
{opt_err, NULL}
};
-#ifdef CAAM_DEBUG
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
static inline void dump_options(const struct caam_pkey_info *pkey_info)
{
- pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("key encryption algo %d\n", pkey_info->key_enc_algo);
}
#else
static inline void dump_options(const struct caam_pkey_info *pkey_info)
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0b142d941cd2..6aed17bee09d 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -31,6 +31,12 @@ static char *trusted_rng = "default";
module_param_named(rng, trusted_rng, charp, 0);
MODULE_PARM_DESC(rng, "Select trusted key RNG");
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
+bool trusted_debug;
+module_param_named(debug, trusted_debug, bool, 0);
+MODULE_PARM_DESC(debug, "Enable trusted keys debug traces (default: 0)");
+#endif
+
static char *trusted_key_source;
module_param_named(source, trusted_key_source, charp, 0);
MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam, dcp or pkwm)");
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 6ea728f1eae6..13513819991e 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -46,38 +46,44 @@ enum {
SRK_keytype = 4
};
-#define TPM_DEBUG 0
-
-#if TPM_DEBUG
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
static inline void dump_options(struct trusted_key_options *o)
{
- pr_info("sealing key type %d\n", o->keytype);
- pr_info("sealing key handle %0X\n", o->keyhandle);
- pr_info("pcrlock %d\n", o->pcrlock);
- pr_info("pcrinfo %d\n", o->pcrinfo_len);
- print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
- 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("sealing key type %d\n", o->keytype);
+ pr_debug("sealing key handle %0X\n", o->keyhandle);
+ pr_debug("pcrlock %d\n", o->pcrlock);
+ pr_debug("pcrinfo %d\n", o->pcrinfo_len);
+ print_hex_dump_debug("pcrinfo ", DUMP_PREFIX_NONE,
+ 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
}
static inline void dump_sess(struct osapsess *s)
{
- print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
- 16, 1, &s->handle, 4, 0);
- pr_info("secret:\n");
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
- 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
- pr_info("trusted-key: enonce:\n");
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
- 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
+ if (!trusted_debug)
+ return;
+
+ print_hex_dump_debug("trusted-key: handle ", DUMP_PREFIX_NONE,
+ 16, 1, &s->handle, 4, 0);
+ pr_debug("secret:\n");
+ print_hex_dump_debug("", DUMP_PREFIX_NONE,
+ 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
+ pr_debug("trusted-key: enonce:\n");
+ print_hex_dump_debug("", DUMP_PREFIX_NONE,
+ 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
}
static inline void dump_tpm_buf(unsigned char *buf)
{
int len;
- pr_info("\ntpm buffer\n");
+ if (!trusted_debug)
+ return;
+ pr_debug("\ntpm buffer\n");
len = LOAD32(buf, TPM_SIZE_OFFSET);
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
+ print_hex_dump_debug("", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
}
#else
static inline void dump_options(struct trusted_key_options *o)
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 0/4] Firmware LSM hook
From: Jason Gunthorpe @ 2026-04-15 13:47 UTC (permalink / raw)
To: Paul Moore
Cc: Leon Romanovsky, Roberto Sassu, KP Singh, Matt Bobrowski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
Saeed Mahameed, Itay Avraham, Dave Jiang, Jonathan Cameron, bpf,
linux-kernel, linux-kselftest, linux-rdma, Chiara Meiohas,
Maher Sanalla, linux-security-module
In-Reply-To: <CAHC9VhTLamfe4C81ZNRVT=H32x+KLxSqH3o0eBfrHsWAgAqxCA@mail.gmail.com>
On Tue, Apr 14, 2026 at 04:27:58PM -0400, Paul Moore wrote:
> On Mon, Apr 13, 2026 at 7:19 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> > > On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
> > > > > > We are not limited to LSM solution, the goal is to intercept commands
> > > > > > which are submitted to the FW and "security" bucket sounded right to us.
> > > > >
> > > > > Yes, it does sound "security relevant", but without a well defined
> > > > > interface/format it is going to be difficult to write a generic LSM to
> > > > > have any level of granularity beyond a basic "load firmware"
> > > > > permission.
> > > >
> > > > I think to step back a bit, what this is trying to achieve is very
> > > > similar to the iptables fwmark/secmark scheme.
> > >
> > > Points for thinking outside the box a bit, but from what I've seen
> > > thus far, it differs from secmark in a few important areas. The
> > > secmark concept relies on the admin to configure the network stack to
> > > apply secmark labels to network traffic as it flows through the
> > > system, the LSM then applies security policy to these packets based on
> > > their label. The firmware LSM hooks, at least as I currently
> > > understand them, rely on the LSM hook callback to parse the firmware
> > > op/request and apply a security policy to the request.
> >
> > That was what was proposed because the idea was to combine the
> > parse/clasification/decision steps into one eBPF program, but I think
> > it can be split up too.
> >
> > > We've already talked about the first issue, parsing the request, and
> > > my suggestion was to make the LSM hook call from within the firmware
> > > (the firmware must have some way to call into the kernel/driver code,
> > > no?)
> >
> > No, that's not workable on so many levels. It is sort of anaologous to
> > asking the NIC to call the LSM to apply the secmark while sending the
> > packet.
>
> From the LSM's perspective it really doesn't matter who calls the LSM
> hook as long as the caller can be trusted to handle the access control
> verdict properly.
The NIC doesn't know anything more than the kernel to call the LSM
hook. It can't magically generate the label the admin wants to use any
better than the kernel can.
Just like you could never get everyone to agree on a fixed set of
labels for network packets we could never get agreemnt on a fixed set
of labels for command packets either.
> > > so that only the firmware would need to parse the request. If we
> > > wanted to adopt a secmark-esque approach, one could develop a second
> > > parsing mechanism that would be responsible for assigning a LSM label
> > > to the request, and then pass the firmware request to the LSM, but I
> > > do worry a bit about the added complexity associated with keeping the
> > > parser sync'd with the driver/fw.
> >
> > In practice it would be like iptables, the parser would be entirely
> > programmed by userspace and there is nothing to keep in sync.
>
> You've mentioned a few times now that the firmware/request will vary
> across not only devices, but firmware revisions too,
I never said firmware revisions, part of the requirement is strong ABI
compatability in these packets.
> this implies there will need to be some effort to keep whatever
> parser you develop (BPF, userspace config, etc.) in sync with the
> parser built into the firmware. Or am I misunderstanding something?
I would not use the word "sync". It is very similar to deep packet
inspection, if you want to look inside, say, RPC messages carried
within HTTP then you have to keep up to date. How onerous that is
depends on what the admin's labeling goals are.
> > > However, even if we solve the parsing problem, I worry we have
> > > another, closely related issue, of having to categorize all of the
> > > past, present, and future firmware requests into a set of LSM specific
> > > actions.
> >
> > Why? secmark doesn't have this issue? The classifer would return the
> > same kind of information as secmark, some user provided label that is
> > delivered to the LSM policy side.
>
> I think there is a misunderstanding in either how secmark works or how
> the LSMs use secmark labels when enforcing their security policy.
>
> The secmark label is set on a packet to represent the network
> properties of a packet. While the rules governing how a packet's
> secmark is set and the semantic meaning of that secmark label is going
> to be LSM and solution specific,
"network properties" are a bit vauge. I can use iptables to inspect
the packet quite completely. It has protocol modules that can do very
detailed inspection. I can use general things like -m string to apply
a secmark to packets containing specific data for example.
From my perspective iptables runs a complicated scheme to evaluate the
full content of the packet and on match applies a secmark.
You can already create a hacky labeling scheme that would tell the
difference between HTTP PUT and HTT GET sessions for example.
At this point it is not just "network properties" but you are
inspecting a RPC and evaluating what operation a remote CPU will
perform.
Even just simple port inspection in most cases is often classifiying
RPCs on the network "Any HTTP RPC" "Any DNS RPC", etc.
> secmark labels represent the properties of a packet and not the
> operation, e.g. send/receive/forward/etc., being requested at a
> given access control point.
Yes, still aligned.
> The access control point itself represents the requested
> operation. This is possible because the number of networking
> operations on a given packet is well defined and fairly limited; at a
> high level the packet is either being sent from the node, received by
> the node, or is passing through the node.
I think we have the same split, fwctl send/recive analog is also very
limited.
> As I understand the firmware controls being proposed here, encoded
> within the firmware request blob is the operation being requested.
I am not proposing that kind of interpretation, I want to stay in the
secmark model.
When the packet blob is sent into the kernel at the uAPI boundary
(send_msg, send, write, FWCTL_CMD_RPC, etc) that is your access
control point.
Deep inspection on the packet blob determines the secmark.
LSM takes the secmark and determines if the access control point
accept/rejects.
In both cases deep inspection will allow the admin to create labels
detailed to the RPC that is described in the packet. Eg
labels like "HTTP GET", "HTTP PUT", "FWCTL CREATE OBJ X", etc.
In both cases these are packets containing RPC messages some remote
CPU will excute.
> While we've discussed possible solutions on how to parse the request
> blob to determine the operation, we haven't really discussed how to
> represent the requested operation to the LSMs.
I don't understand this? The secmark example I pulled up is this:
iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx system_u:object_r:httpd_packet_t:s0
The "represent the requested operation" is the string
"system_u:object_r:httpd_packet_t:s0", which is entirely admin
defined, right?
The analog here is some
'fwctl iptables' -match 'byte[10]=0x20' -selctx system_u:object_r:fwctl_mlx5_create_pd_t:s0
Again, all admin defined?
> I'm assuming there isn't a well defined set of operations, and like
> the request format itself, the set of valid operations will vary
> from device and firmware revision. I hope you can understand both
> how this differs from secmark and that it is a challenge that really
> hasn't been addressed in the proposals we've discussed.
I still don't see the difference from iptables. IPSEC, SIP, DNS, HTTP,
etc are all protocols with the same lack of any commonality.
> At a very high level the access control decision for firmware/device
> requests depends on whether the LSM wants to allow process A to do B
> to device C. The identity/credentials associated with process A are
> easy to understand, we have plenty of examples both inside and outside
> of the LSM on how to do that. The device identity/attributes
> associated with device C can be a bit trickier, but once again we have
> plenty of examples to draw from, and we can even fall back to a
> generic "kernel" id/attribute if the LSM chooses not to distinguish
> entities below the userspace/kernel boundary.
I think I would feed that into the classifier as well. Like iptables
can have a netdev argument to only match against specific devices, we
can have the same logical thing.
> I think the hardest issue with the firmware request hooks is going
> to be determining what operation is being requested, the "B",
> portion of access request tuple. If we can create a well defined
> set of operations and leave it to the parser to characterize the
> operation we've potentially got a solution, but if the operation is
> truly going to be arbitrary then we have a real problem. How do you
> craft a meaningful access control policy when you don't understand
> what is being requested?
Same as for networking. Admin understands, admin defines, kernel is
just a programmable classifier.
Jason
^ permalink raw reply
* Re: [syzbot] Monthly lsm report (Apr 2026)
From: Jarkko Sakkinen @ 2026-04-15 16:35 UTC (permalink / raw)
To: Paul Moore
Cc: David Howells, linux-kernel, linux-security-module,
syzkaller-bugs, syzbot
In-Reply-To: <CAHC9VhS2AaRwAQw1hNcpuGdFSOL7Li9PavKtU7eW-w8eMOFuKA@mail.gmail.com>
On Tue, Apr 14, 2026 at 10:02:13AM -0400, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 2:48 AM syzbot
> <syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com> wrote:
> >
> > Hello lsm maintainers/developers,
> >
> > This is a 31-day syzbot report for the lsm subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/lsm
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 3 issues are still open and 45 have already been fixed.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 95 Yes INFO: task hung in process_measurement (3)
> > https://syzkaller.appspot.com/bug?extid=cb9e66807bcb882cd0c5
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> > https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
>
> Jarkko, David,
>
> Do we have a fix for the keyring_clear() issue, or is it not a real problem?
I'm actually doing something to this already: trying to write a
simplified reproducer. But yeah most likely still will take up until
some point next week.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] ima: Use KEXEC_SIG_FORCE for rejecting unsigned kexec images
From: Mimi Zohar @ 2026-04-15 19:22 UTC (permalink / raw)
To: Chi Wang, roberto.sassu, dmitry.kasatkin, eric.snowberg
Cc: paul, jmorris, serge, linux-integrity, linux-security-module,
linux-kernel, Chi Wang
In-Reply-To: <20260415102319.431379-1-wangchi05@163.com>
On Wed, 2026-04-15 at 18:23 +0800, Chi Wang wrote:
> From: Chi Wang <wangchi@kylinos.cn>
>
> Following the split of KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE,
> only KEXEC_SIG_FORCE indicates that unsigned kernel images must be rejected.
> KEXEC_SIG alone enables signature verification but permits unsigned images,
> so it should not trigger the IMA appraisal denial for kexec_load.
>
> Update the condition in ima_load_data() to check for KEXEC_SIG_FORCE
> instead of KEXEC_SIG.
>
> Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
>
> Signed-off-by: Chi Wang <wangchi@kylinos.cn>
It isn't enough to check whether CONFIG_KEXEC_SIG_FORCE is configured, since it
is possible to require the kexec kernel image to be signed at runtime. Based on
the IMA policy, IMA will call set_kexec_sig_enforced() to require the kexec
kernel image to be signed.
Mimi
> ---
> security/integrity/ima/ima_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 1d6229b156fb..ec70e78ab8cd 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -953,7 +953,7 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
>
> switch (id) {
> case LOADING_KEXEC_IMAGE:
> - if (IS_ENABLED(CONFIG_KEXEC_SIG)
> + if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)
> && arch_ima_get_secureboot()) {
> pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
> return -EACCES;
> --
> 2.25.1
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Stefan Berger @ 2026-04-15 20:15 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <0375ccecdfb77286dff7f40af5ddbd20f7d6e0fa.camel@linux.ibm.com>
On 4/14/26 10:00 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Refactor asymmetric_verify for reusability. Have it call
>> asymmetric_verify_common with the signature verification key and the
>> public_key structure as parameters. sigv3 support for ML-DSA will need to
>> check the public key type first to decide how to do the signature
>> verification and therefore will have these parameters available for
>> calling asymmetric_verify_common.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
> Thanks, Stefan.
>
>> ---
>> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
>> 1 file changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index 6e68ec3becbd..e29ed73f15cd 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
>> return key;
>> }
>>
>> -int asymmetric_verify(struct key *keyring, const char *sig,
>> - int siglen, const char *data, int datalen)
>> +static int asymmetric_verify_common(const struct key *key,
>> + const struct public_key *pk,
>> + const char *sig, int siglen,
>> + const char *data, int datalen)
>> {
>> - struct public_key_signature pks;
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> - const struct public_key *pk;
>> - struct key *key;
>> + struct public_key_signature pks;
>> int ret;
>>
>> - if (siglen <= sizeof(*hdr))
>> - return -EBADMSG;
>> -
>> siglen -= sizeof(*hdr);
>
> Normally kernel-doc is unnecessary for static functions. Here, however, since
> only the caller verifies the signature length, there should be a kernel-doc
> function definition. It should indicate that all callers must verify the
> signature length (siglen) and that the public key (pk) is not NULL, before
> calling asymmetric_verify_common().
Will add.
>
>>
>> if (siglen != be16_to_cpu(hdr->sig_size))
>> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> if (hdr->hash_algo >= HASH_ALGO__LAST)
>> return -ENOPKG;
>>
>> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> - if (IS_ERR(key))
>> - return PTR_ERR(key);
>> -
>> memset(&pks, 0, sizeof(pks));
>>
>> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>>
>> - pk = asymmetric_key_public_key(key);
>> pks.pkey_algo = pk->pkey_algo;
>> if (!strcmp(pk->pkey_algo, "rsa")) {
>> pks.encoding = "pkcs1";
>> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> pks.s_size = siglen;
>> ret = verify_signature(key, &pks);
>> out:
>> - key_put(key);
>
> The kernel-doc function definition should also indicate that the caller must
> free the key.
Ok, I will add it. However, symmetric_verify_common cannot free the key
since it is passed as const(!) struct key *key...
>
>> pr_debug("%s() = %d\n", __func__, ret);
>> return ret;
>> }
>>
>> +int asymmetric_verify(struct key *keyring, const char *sig,
>> + int siglen, const char *data, int datalen)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + const struct public_key *pk;
>> + struct key *key;
>> + int ret;
>> +
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test here making sure pk is not null.
As a separate patch for backporting?
Return -ENOKEY in case we hit a NULL pointer?
>
> thanks,
>
> Mimi
>
>> +
>> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
>> +
>> + key_put(key);
>> +
>> + return ret;
>> +}
>> +
>> /*
>> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
>> * @type: xattr type [enum evm_ima_xattr_type]
>
^ permalink raw reply
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Stefan Berger @ 2026-04-15 20:32 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <be3fdb81a322ab96e356e165b737c46f00c12cc3.camel@linux.ibm.com>
On 4/14/26 10:01 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Add support for sigv3 signature verification using ML-DSA in pure mode.
>> When a sigv3 signature is verified, first check whether the key to use
>> for verification is an ML-DSA key and therefore uses a hashless signature
>> verification scheme. The hashless signature verification method uses the
>> ima_file_id structure directly for signature verification rather than
>> its digest.
>>
>> Suggested-by: Eric Biggers <ebiggers@kernel.org>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>>
>
> Thanks, Stefan.
>> ---
>> v2: Set hash_algo in public_key_signature to "none"
>> ---
>> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
>> 1 file changed, 79 insertions(+), 5 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index e29ed73f15cd..c80cb2b117a6 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
>> return rc;
>> }
>>
>> +/*
>
> kernel-doc starts with "/**".
I followed the pattern of documentation of a static function that you
just moved:
/*
* calc_file_id_hash - calculate the hash of the ima_file_id struct data
* @type: xattr type [enum evm_ima_xattr_type]
>
>> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
>> + * @key: The key to use for signature verification
>> + * @pk: The associated public key
>> + * @encoding: The encoding the key type uses
>> + * @sig: The signature
>> + * @siglen: The length of the xattr signature
>> + * @algo: The hash algorithm
>> + * @digest: The file digest
>> + *
>> + * Create an ima_file_id structure and use it for signature verification
>> + * directly. This can be used for ML-DSA in pure mode for example.
>
> Like the comments on 1/2, please add a comment here indicating that all callers
> must verify the signature length (siglen) and the public key (pk) is not NULL,
> before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
> must free the key.
>
>> + */
>> +static int asymmetric_verify_v3_hashless(struct key *key,
>> + const struct public_key *pk,
>> + const char *encoding,
>> + const char *sig, int siglen,
>> + u8 algo,
>> + const u8 *digest)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + struct ima_file_id file_id = {
>> + .hash_type = hdr->type,
>> + .hash_algorithm = algo,
>> + };
>> + size_t digest_size = hash_digest_size[algo];
>
> Defer initializing the digest_size and .m_size, below, until after checking the
> hash algorithm is valid.
This function is called by asymmetric_verify. asymmetric_verify calls
calc_file_id_hash, which doesn't check algo for valid range, either. I
suppose it's an untrusted value at this point (IMA never checked it's
value for valid range?) an we should check it in asymmetric_verify then
to cover both cases? Or you want to check it individually?
>
>> + struct public_key_signature pks = {
>> + .m = (u8 *)&file_id,
>> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
>> + .s = hdr->sig,
>> + .s_size = siglen - sizeof(*hdr),
>> + .pkey_algo = pk->pkey_algo,
>> + .hash_algo = "none",
>> + .encoding = encoding,
>> + };
>> + int ret;
>> +
>> + if (hdr->type != IMA_VERITY_DIGSIG &&
>> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
>> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
>> + return -EINVAL;
>> +
>> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
>> + return -EBADMSG;
>> +
>> + memcpy(file_id.hash, digest, digest_size);
>
> First check the hash algorithm is valid, before using digest_size.
>
>> +
>> + ret = verify_signature(key, &pks);
>> + pr_debug("%s() = %d\n", __func__, ret);
>> + return ret;
>> +}
>> +
>> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
>> const char *data, int datalen, u8 algo)
>> {
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> struct ima_max_digest_data hash;
>> + const struct public_key *pk;
>> + struct key *key;
>> int rc;
>>
>> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> - if (rc)
>> - return -EINVAL;
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>>
>> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
>> - hash.hdr.length);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test to check that 'pk' isn't null.
>
>> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
>> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
>> + sig, siglen, algo, data);
>> + } else {
>> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> + if (rc) {
>> + rc = -EINVAL;
>> + goto err_exit;
>> + }
>> +
>> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
>> + hash.hdr.length);
>> + }
>> +
>> +err_exit:
>
> Normally a label named 'err*' would be preceded by a return. Here, the label
> "err_exit" is always called, not only when there is an error. Please rename the
> label to something more appropriate - out, cleanup, etc.
Ok, will call it 'out'.
>
>> + key_put(key);
>> +
>> + return rc;
>> }
>
> thanks,
>
> Mimi
>
^ permalink raw reply
* [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Josh Snyder @ 2026-04-15 20:40 UTC (permalink / raw)
To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg
Cc: linux-integrity, keyrings, linux-kernel, linux-security-module,
Josh Snyder
Defining pr_fmt in a widely-included header leaks the "trusted_key: "
prefix into every translation unit that transitively includes
<keys/trusted-type.h>. dm-crypt, for example, ends up printing
trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
("dm crypt: support using trusted keys"), which predates the pr_fmt
addition, so the regression has been live from the moment the header
gained its own pr_fmt definition.
Move the pr_fmt definition into the trusted-keys source files that
actually want the prefix, with specific prefixes for each key type.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Josh Snyder <josh@code406.com>
---
Changes in v2:
- specific pr_fmt based on trusted key type
---
| 6 ------
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
7 files changed, 12 insertions(+), 6 deletions(-)
--git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 03527162613f7..54da1f174aeab 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -11,12 +11,6 @@
#include <linux/rcupdate.h>
#include <linux/tpm.h>
-#ifdef pr_fmt
-#undef pr_fmt
-#endif
-
-#define pr_fmt(fmt) "trusted_key: " fmt
-
#define MIN_KEY_SIZE 32
#define MAX_KEY_SIZE 128
#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
--git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
index 601943ce0d60f..71c173bb2f727 100644
--- a/security/keys/trusted-keys/trusted_caam.c
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -4,6 +4,8 @@
* Copyright 2025 NXP
*/
+#define pr_fmt(fmt) "trusted_key: caam: " fmt
+
#include <keys/trusted_caam.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0b142d941cd2e..159af9dcfc774 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: " fmt
+
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <keys/trusted_tee.h>
--git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
index 7b6eb655df0cb..41a23e2f30891 100644
--- a/security/keys/trusted-keys/trusted_dcp.c
+++ b/security/keys/trusted-keys/trusted_dcp.c
@@ -3,6 +3,8 @@
* Copyright (C) 2021 sigma star gmbh
*/
+#define pr_fmt(fmt) "trusted_key: dcp: " fmt
+
#include <crypto/aead.h>
#include <crypto/aes.h>
#include <crypto/algapi.h>
--git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
index bf42c6679245a..108db105b639f 100644
--- a/security/keys/trusted-keys/trusted_pkwm.c
+++ b/security/keys/trusted-keys/trusted_pkwm.c
@@ -3,6 +3,8 @@
* Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
*/
+#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
+
#include <keys/trusted_pkwm.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 6ea728f1eae6f..207be849796ed 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
+
#include <crypto/hash_info.h>
#include <crypto/sha1.h>
#include <crypto/utils.h>
--git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 6340823f8b53c..2a540b1af0b33 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -4,6 +4,8 @@
* Copyright (C) 2014 Intel Corporation
*/
+#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
+
#include <linux/asn1_encoder.h>
#include <linux/oid_registry.h>
#include <linux/string.h>
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-trusted-key-header-a544a4f149d2
Best regards,
--
Josh
^ permalink raw reply related
* Re: [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Marco Felsch @ 2026-04-15 20:50 UTC (permalink / raw)
To: Josh Snyder
Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20260415-trusted-key-header-v2-1-5244f9ef0d09@code406.com>
On 26-04-15, Josh Snyder wrote:
> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> prefix into every translation unit that transitively includes
> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
>
> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
>
> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> addition, so the regression has been live from the moment the header
> gained its own pr_fmt definition.
>
> Move the pr_fmt definition into the trusted-keys source files that
> actually want the prefix, with specific prefixes for each key type.
>
> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Josh Snyder <josh@code406.com>
> ---
> Changes in v2:
> - specific pr_fmt based on trusted key type
> ---
> include/keys/trusted-type.h | 6 ------
> security/keys/trusted-keys/trusted_caam.c | 2 ++
> security/keys/trusted-keys/trusted_core.c | 2 ++
> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
You missed the trusted_tee.c, sorry for not spotting this earlier.
Regards,
Marco
> 7 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 03527162613f7..54da1f174aeab 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -11,12 +11,6 @@
> #include <linux/rcupdate.h>
> #include <linux/tpm.h>
>
> -#ifdef pr_fmt
> -#undef pr_fmt
> -#endif
> -
> -#define pr_fmt(fmt) "trusted_key: " fmt
> -
> #define MIN_KEY_SIZE 32
> #define MAX_KEY_SIZE 128
> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60f..71c173bb2f727 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -4,6 +4,8 @@
> * Copyright 2025 NXP
> */
>
> +#define pr_fmt(fmt) "trusted_key: caam: " fmt
> +
> #include <keys/trusted_caam.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 0b142d941cd2e..159af9dcfc774 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: " fmt
> +
> #include <keys/user-type.h>
> #include <keys/trusted-type.h>
> #include <keys/trusted_tee.h>
> diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
> index 7b6eb655df0cb..41a23e2f30891 100644
> --- a/security/keys/trusted-keys/trusted_dcp.c
> +++ b/security/keys/trusted-keys/trusted_dcp.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2021 sigma star gmbh
> */
>
> +#define pr_fmt(fmt) "trusted_key: dcp: " fmt
> +
> #include <crypto/aead.h>
> #include <crypto/aes.h>
> #include <crypto/algapi.h>
> diff --git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
> index bf42c6679245a..108db105b639f 100644
> --- a/security/keys/trusted-keys/trusted_pkwm.c
> +++ b/security/keys/trusted-keys/trusted_pkwm.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
> */
>
> +#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
> +
> #include <keys/trusted_pkwm.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 6ea728f1eae6f..207be849796ed 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
> +
> #include <crypto/hash_info.h>
> #include <crypto/sha1.h>
> #include <crypto/utils.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index 6340823f8b53c..2a540b1af0b33 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -4,6 +4,8 @@
> * Copyright (C) 2014 Intel Corporation
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
> +
> #include <linux/asn1_encoder.h>
> #include <linux/oid_registry.h>
> #include <linux/string.h>
>
> ---
> base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
> change-id: 20260411-trusted-key-header-a544a4f149d2
>
> Best regards,
> --
> Josh
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ 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