* Re: [PATCH v4 06/35] cleanup: Basic compatibility with context analysis
From: Marco Elver @ 2025-12-15 15:53 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Boqun Feng, Ingo Molnar, Will Deacon, David S. Miller,
Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu
In-Reply-To: <aUAPbFJSv0alh_ix@elver.google.com>
On Mon, 15 Dec 2025 at 14:38, Marco Elver <elver@google.com> wrote:
>
> On Fri, Dec 12, 2025 at 12:09PM +0100, Peter Zijlstra wrote:
> > On Fri, Dec 12, 2025 at 11:15:29AM +0100, Marco Elver wrote:
> > > On Fri, 12 Dec 2025 at 10:43, Peter Zijlstra <peterz@infradead.org> wrote:
> > > [..]
> > > > > Correct. We're trading false negatives over false positives at this
> > > > > point, just to get things to compile cleanly.
> > > >
> > > > Right, and this all 'works' right up to the point someone sticks a
> > > > must_not_hold somewhere.
> > > >
> > > > > > > Better support for Linux's scoped guard design could be added in
> > > > > > > future if deemed critical.
> > > > > >
> > > > > > I would think so, per the above I don't think this is 'right'.
> > > > >
> > > > > It's not sound, but we'll avoid false positives for the time being.
> > > > > Maybe we can wrangle the jigsaw of macros to let it correctly acquire
> > > > > and then release (via a 2nd cleanup function), it might be as simple
> > > > > as marking the 'constructor' with the right __acquires(..), and then
> > > > > have a 2nd __attribute__((cleanup)) variable that just does a no-op
> > > > > release via __release(..) so we get the already supported pattern
> > > > > above.
> > > >
> > > > Right, like I mentioned in my previous email; it would be lovely if at
> > > > the very least __always_inline would get a *very* early pass such that
> > > > the above could be resolved without inter-procedural bits. I really
> > > > don't consider an __always_inline as another procedure.
> > > >
> > > > Because as I already noted yesterday, cleanup is now all
> > > > __always_inline, and as such *should* all end up in the one function.
> > > >
> > > > But yes, if we can get a magical mash-up of __cleanup and __release (let
> > > > it be knows as __release_on_cleanup ?) that might also work I suppose.
> > > > But I vastly prefer __always_inline actually 'working' ;-)
> > >
> > > The truth is that __always_inline working in this way is currently
> > > infeasible. Clang and LLVM's architecture simply disallow this today:
> > > the semantic analysis that -Wthread-safety does happens over the AST,
> > > whereas always_inline is processed by early passes in the middle-end
> > > already within LLVM's pipeline, well after semantic analysis. There's
> > > a complexity budget limit for semantic analysis (type checking,
> > > warnings, assorted other errors), and path-sensitive &
> > > intra-procedural analysis over the plain AST is outside that budget.
> > > Which is why tools like clang-analyzer exist (symbolic execution),
> > > where it's possible to afford that complexity since that's not
> > > something that runs for a normal compile.
> > >
> > > I think I've pushed the current version of Clang's -Wthread-safety
> > > already far beyond what folks were thinking is possible (a variant of
> > > alias analysis), but even my healthy disregard for the impossible
> > > tells me that making path-sensitive intra-procedural analysis even if
> > > just for __always_inline functions is quite possibly a fool's errand.
> >
> > Well, I had to propose it. Gotta push the envelope :-)
> >
> > > So either we get it to work with what we have, or give up.
> >
> > So I think as is, we can start. But I really do want the cleanup thing
> > sorted, even if just with that __release_on_cleanup mashup or so.
>
> Working on rebasing this to v6.19-rc1 and saw this new scoped seqlock
> abstraction. For that one I was able to make it work like I thought we
> could (below). Some awkwardness is required to make it work in
> for-loops, which only let you define variables with the same type.
>
> For <linux/cleanup.h> it needs some more thought due to extra levels of
> indirection.
For cleanup.h, the problem is that to instantiate we use
"guard(class)(args..)". If it had been designed as "guard(class,
args...)", i.e. just use __VA_ARGS__ explicitly instead of the
implicit 'args...', it might have been possible to add a second
cleanup variable to do the same (with some additional magic to extract
the first arg if one exists). Unfortunately, the use of the current
guard()() idiom has become so pervasive that this is a bigger
refactor. I'm going to leave cleanup.h as-is for now, if we think we
want to give this a go in the current state.
One observation from the rebase: Generally synchronization primitives
do not change much and the annotations are relatively stable, but e.g.
RCU & sched (latter is optional and depends on the sched-enablement
patch) receive disproportionally more changes, and while new
annotations required for v6.19-rc1 were trivial, it does require
compiling with a Clang version that does produce the warnings to
notice.
While Clang 22-dev is being tested on CI, I doubt maintainers already
use it, so it's possible we'll see some late warnings due to missing
annotations when things hit -next. This might be an acceptable churn
cost, if we think the outcome is worthwhile. Things should get better
when Clang 22 is released properly, but until then things might be a
little bumpy if there are large changes across the core
synchronization primitives.
Thanks,
-- Marco
^ permalink raw reply
* [PATCH] loadpin: Implement custom proc_handler for enforce
From: Joel Granados @ 2025-12-15 15:43 UTC (permalink / raw)
To: Kees Cook, Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-security-module, linux-kernel, Joel Granados
The new proc_handler_loadpin returns -EINVAL when is_loadpin_writable is
false and the kernel var (enforce) is being written. Move
loadpin_sysctl_table to .rodata (by const qualifying it) as there is no
need to change the value of the extra1 entry.
Signed-off-by: Joel Granados <joel.granados@kernel.org>
---
Const qualifying ctl tables is part of the hardening effort in the linux
kernel.
---
security/loadpin/loadpin.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 273ffbd6defe1324d6688dec5f9fe6c9401283ed..f049c81b82a78265b6ae358bb2a814265cec9f16 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -53,18 +53,29 @@ static bool deny_reading_verity_digests;
#endif
#ifdef CONFIG_SYSCTL
-static struct ctl_table loadpin_sysctl_table[] = {
+static bool is_loadpin_writable;
+
+static int proc_handler_loadpin(const struct ctl_table *table, int dir,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ if (!is_loadpin_writable && SYSCTL_USER_TO_KERN(dir))
+ return -EINVAL;
+ return proc_dointvec_minmax(table, dir, buffer, lenp, ppos);
+}
+
+static const struct ctl_table loadpin_sysctl_table[] = {
{
.procname = "enforce",
.data = &enforce,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ONE,
+ .proc_handler = proc_handler_loadpin,
+ .extra1 = SYSCTL_ZERO,
.extra2 = SYSCTL_ONE,
},
};
+
static void set_sysctl(bool is_writable)
{
/*
@@ -72,9 +83,9 @@ static void set_sysctl(bool is_writable)
* device, allow sysctl to change modes for testing.
*/
if (is_writable)
- loadpin_sysctl_table[0].extra1 = SYSCTL_ZERO;
+ is_loadpin_writable = true;
else
- loadpin_sysctl_table[0].extra1 = SYSCTL_ONE;
+ is_loadpin_writable = false;
}
#else
static inline void set_sysctl(bool is_writable) { }
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251215-jag-const_loadpin-761f052f76c4
Best regards,
--
Joel Granados <joel.granados@kernel.org>
^ permalink raw reply related
* Re: [PATCH] fuse: fix conversion of fuse_reverse_inval_entry() to start_removing()
From: Christian Brauner @ 2025-12-15 14:19 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Al Viro, Amir Goldstein, NeilBrown, Val Packett, Jan Kara,
linux-fsdevel, Jeff Layton, Chris Mason, David Sterba,
David Howells, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Tyler Hicks, Chuck Lever, Olga Kornievskaia,
Dai Ngo, Namjae Jeon, Steve French, Sergey Senozhatsky,
Carlos Maiolino, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Stephen Smalley, Ondrej Mosnacek, Mateusz Guzik,
Lorenzo Stoakes, Stefan Berger, Darrick J. Wong, linux-kernel,
netfs, ecryptfs, linux-nfs, linux-unionfs, linux-cifs, linux-xfs,
linux-security-module, selinux
In-Reply-To: <20251205-unmoralisch-jahrtausend-cca02ad0e4fa@brauner>
On Fri, Dec 05, 2025 at 02:09:41PM +0100, Christian Brauner wrote:
> On Mon, Dec 01, 2025 at 03:03:08PM +0100, Miklos Szeredi wrote:
> > On Mon, 1 Dec 2025 at 09:33, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Mon, Dec 01, 2025 at 09:22:54AM +0100, Amir Goldstein wrote:
> > >
> > > > I don't think there is a point in optimizing parallel dir operations
> > > > with FUSE server cache invalidation, but maybe I am missing
> > > > something.
> > >
> > > The interesting part is the expected semantics of operation;
> > > d_invalidate() side definitely doesn't need any of that cruft,
> > > but I would really like to understand what that function
> > > is supposed to do.
> > >
> > > Miklos, could you post a brain dump on that?
> >
> > This function is supposed to invalidate a dentry due to remote changes
> > (FUSE_NOTIFY_INVAL_ENTRY). Originally it was supplied a parent ID and
> > a name and called d_invalidate() on the looked up dentry.
> >
> > Then it grew a variant (FUSE_NOTIFY_DELETE) that was also supplied a
> > child ID, which was matched against the looked up inode. This was
> > commit 451d0f599934 ("FUSE: Notifying the kernel of deletion."),
> > Apparently this worked around the fact that at that time
> > d_invalidate() returned -EBUSY if the target was still in use and
> > didn't unhash the dentry in that case.
> >
> > That was later changed by commit bafc9b754f75 ("vfs: More precise
> > tests in d_invalidate") to unconditionally unhash the target, which
> > effectively made FUSE_NOTIFY_INVAL_ENTRY and FUSE_NOTIFY_DELETE
> > equivalent and the code in question unnecessary.
> >
> > For the future, we could also introduce FUSE_NOTIFY_MOVE, that would
> > differentiate between a delete and a move, while
> > FUSE_NOTIFY_INVAL_ENTRY would continue to be the common (deleted or
> > moved) notification.
> >
> > Attaching untested patch to remove this cruft.
>
> Should we revert the fuse specific bits of c9ba789dad15 ("VFS: introduce
> start_creating_noperm() and start_removing_noperm()") and then apply
> your changes afterwards?
I think we shouldn't have this sitting around indefinitely so it would
be good if we'd get a nod that this is ok or someone sending revert +
fix that I can pick up. :)
^ permalink raw reply
* [PATCH v2 15/17] KEYS: trusted: Make use of tee bus methods
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Sumit Garg, James Bottomley, Jarkko Sakkinen,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn
Cc: linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
security/keys/trusted-keys/trusted_tee.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
index 3cea9a377955..6e465c8bef5e 100644
--- a/security/keys/trusted-keys/trusted_tee.c
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -202,9 +202,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
return 0;
}
-static int trusted_key_probe(struct device *dev)
+static int trusted_key_probe(struct tee_client_device *rng_device)
{
- struct tee_client_device *rng_device = to_tee_client_device(dev);
+ struct device *dev = &rng_device->dev;
int ret;
struct tee_ioctl_open_session_arg sess_arg;
@@ -244,13 +244,11 @@ static int trusted_key_probe(struct device *dev)
return ret;
}
-static int trusted_key_remove(struct device *dev)
+static void trusted_key_remove(struct tee_client_device *dev)
{
unregister_key_type(&key_type_trusted);
tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
tee_client_close_context(pvt_data.ctx);
-
- return 0;
}
static const struct tee_client_device_id trusted_key_id_table[] = {
@@ -261,11 +259,11 @@ static const struct tee_client_device_id trusted_key_id_table[] = {
MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
static struct tee_client_driver trusted_key_driver = {
+ .probe = trusted_key_probe,
+ .remove = trusted_key_remove,
.id_table = trusted_key_id_table,
.driver = {
.name = DRIVER_NAME,
- .probe = trusted_key_probe,
- .remove = trusted_key_remove,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 14/17] KEYS: trusted: Migrate to use tee specific driver registration function
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Sumit Garg, James Bottomley, Jarkko Sakkinen,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn
Cc: linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
The tee subsystem recently got a set of dedicated functions to register
(and unregister) a tee driver. Make use of them. These care for setting the
driver's bus (so the explicit assignment can be dropped) and the driver
owner (which is an improvement this driver benefits from).
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
security/keys/trusted-keys/trusted_tee.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
index aa3d477de6db..3cea9a377955 100644
--- a/security/keys/trusted-keys/trusted_tee.c
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -264,7 +264,6 @@ static struct tee_client_driver trusted_key_driver = {
.id_table = trusted_key_id_table,
.driver = {
.name = DRIVER_NAME,
- .bus = &tee_bus_type,
.probe = trusted_key_probe,
.remove = trusted_key_remove,
},
@@ -272,12 +271,12 @@ static struct tee_client_driver trusted_key_driver = {
static int trusted_tee_init(void)
{
- return driver_register(&trusted_key_driver.driver);
+ return tee_client_driver_register(&trusted_key_driver);
}
static void trusted_tee_exit(void)
{
- driver_unregister(&trusted_key_driver.driver);
+ tee_client_driver_unregister(&trusted_key_driver);
}
struct trusted_key_ops trusted_key_tee_ops = {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Jonathan Corbet, Sumit Garg, Olivia Mackall,
Herbert Xu, Clément Léger, Alexandre Belloni,
Ard Biesheuvel, Maxime Coquelin, Alexandre Torgue, Sumit Garg,
Ilias Apalodimas, Jan Kiszka, Uwe Kleine-König, Sudeep Holla,
Christophe JAILLET, Rafał Miłecki, Michael Chan,
Pavan Chebbi, James Bottomley, Jarkko Sakkinen, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Peter Huewe
Cc: op-tee, linux-kernel, linux-doc, linux-crypto, linux-rtc,
linux-efi, linux-stm32, linux-arm-kernel, Cristian Marussi,
arm-scmi, linux-mips, netdev, linux-integrity, keyrings,
linux-security-module, Jason Gunthorpe
Hello,
the objective of this series is to make tee driver stop using callbacks
in struct device_driver. These were superseded by bus methods in 2006
(commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
methods.")) but nobody cared to convert all subsystems accordingly.
Here the tee drivers are converted. The first commit is somewhat
unrelated, but simplifies the conversion (and the drivers). It
introduces driver registration helpers that care about setting the bus
and owner. (The latter is missing in all drivers, so by using these
helpers the drivers become more correct.)
v1 of this series is available at
https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
Changes since v1:
- rebase to v6.19-rc1 (no conflicts)
- add tags received so far
- fix whitespace issues pointed out by Sumit Garg
- fix shutdown callback to shutdown and not remove
As already noted in v1's cover letter, this series should go in during a
single merge window as there are runtime warnings when the series is
only applied partially. Sumit Garg suggested to apply the whole series
via Jens Wiklander's tree.
If this is done the dependencies in this series are honored, in case the
plan changes: Patches #4 - #17 depend on the first two.
Note this series is only build tested.
Uwe Kleine-König (17):
tee: Add some helpers to reduce boilerplate for tee client drivers
tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
tee: Adapt documentation to cover recent additions
hwrng: optee - Make use of module_tee_client_driver()
hwrng: optee - Make use of tee bus methods
rtc: optee: Migrate to use tee specific driver registration function
rtc: optee: Make use of tee bus methods
efi: stmm: Make use of module_tee_client_driver()
efi: stmm: Make use of tee bus methods
firmware: arm_scmi: optee: Make use of module_tee_client_driver()
firmware: arm_scmi: Make use of tee bus methods
firmware: tee_bnxt: Make use of module_tee_client_driver()
firmware: tee_bnxt: Make use of tee bus methods
KEYS: trusted: Migrate to use tee specific driver registration
function
KEYS: trusted: Make use of tee bus methods
tpm/tpm_ftpm_tee: Make use of tee specific driver registration
tpm/tpm_ftpm_tee: Make use of tee bus methods
Documentation/driver-api/tee.rst | 18 +----
drivers/char/hw_random/optee-rng.c | 26 ++----
drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
drivers/rtc/rtc-optee.c | 27 ++-----
drivers/tee/tee_core.c | 84 ++++++++++++++++++++
include/linux/tee_drv.h | 12 +++
security/keys/trusted-keys/trusted_tee.c | 17 ++--
10 files changed, 164 insertions(+), 138 deletions(-)
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.47.3
^ permalink raw reply
* Re: [PATCH V2 1/1] IMA event log trimming
From: Mimi Zohar @ 2025-12-15 14:02 UTC (permalink / raw)
To: steven chen, linux-integrity
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, corbet, serge,
paul, jmorris, linux-security-module, anirudhve, gregorylumen,
nramas, sushring, linux-doc
In-Reply-To: <20251210235314.3341-2-chenste@linux.microsoft.com>
Hi Steven,
The main difference between this patch and Roberto's version is the length of
time needed for locking the measurement list, which prevents new entries from
being appended to the measurement list. In Roberto's version, the list head is
moved quickly and the lock released. Measuring the total amount of time needed
to trim the measurement list ignores the benefit of his version. I plan on
reviewing both this version and his (hopefully today).
There are a number of other things missing from this patch, which I'll enumerate
when I review it.
On Wed, 2025-12-10 at 15:53 -0800, steven chen wrote:
> This patch is for trimming N entries of the IMA event logs. It will also
> cleaning the hash table if ima_flush_htable is set.
Please refer to "Describe your changes in imperative mood" in the "Describe your
changes" section of Documentation/process/submitting-patches.rst.
>
> It provides a userspace interface ima_trim_log that can be used to input
> number N to let kernel to trim N entries of IMA event logs. When read
> this interface, it returns number of entries trimmed last time.
>
> Signed-off-by: steven chen <chenste@linux.microsoft.com>
--
thanks,
Mimi
^ permalink raw reply
* Re: (subset) [PATCH 00/46] Allow inlining C helpers into Rust when using LTO
From: Mark Brown @ 2025-12-15 13:59 UTC (permalink / raw)
To: rust-for-linux, Alice Ryhl
Cc: linux-kernel, Greg Kroah-Hartman, Dave Ertman, Ira Weiny,
Leon Romanovsky, Peter Zijlstra, Boqun Feng, Elle Rhumsaa,
Carlos Llamas, Yury Norov, Andreas Hindborg, linux-block,
FUJITA Tomonori, Miguel Ojeda, Michael Turquette, Stephen Boyd,
linux-clk, Benno Lossin, Danilo Krummrich, Thomas Gleixner,
Rafael J. Wysocki, Viresh Kumar, linux-pm, Paul Moore,
Serge Hallyn, linux-security-module, Daniel Almeida,
Abdiel Janulgue, Robin Murphy, Lyude Paul, Alexander Viro,
Christian Brauner, Jan Kara, linux-fsdevel, Josh Poimboeuf,
Jason Baron, Steven Rostedt, Ard Biesheuvel, Brendan Higgins,
David Gow, linux-kselftest, Andrew Morton, Liam R. Howlett,
Andrew Ballance, maple-tree, linux-mm, Lorenzo Stoakes,
Uladzislau Rezki, Vitaly Wool, Rob Herring, Saravana Kannan,
devicetree, Bjorn Helgaas, Krzysztof Wilczyński, linux-pci,
Remo Senekowitsch, Paul E. McKenney, rcu, Will Deacon,
Fiona Behrens, Gary Guo, Liam Girdwood, Alexandre Courbot,
Vlastimil Babka, Christoph Lameter, David Rientjes, Ingo Molnar,
Waiman Long, Mitchell Levy, Frederic Weisbecker,
Anna-Maria Behnsen, John Stultz, linux-usb, Tejun Heo,
Lai Jiangshan, Matthew Wilcox, Tamir Duberstein, Rae Moar
In-Reply-To: <20251202-define-rust-helper-v1-0-a2e13cbc17a6@google.com>
On Tue, 02 Dec 2025 19:37:24 +0000, Alice Ryhl wrote:
> This patch series adds __rust_helper to every single rust helper. The
> patches do not depend on each other, so maintainers please go ahead and
> pick up any patches relevant to your subsystem! Or provide your Acked-by
> so that Miguel can pick them up.
>
> These changes were generated by adding __rust_helper and running
> ClangFormat. Unrelated formatting changes were removed manually.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[35/46] rust: regulator: add __rust_helper to helpers
commit: 03d281f384768610bf90697bce9e35d3d596de77
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v4 06/35] cleanup: Basic compatibility with context analysis
From: Marco Elver @ 2025-12-15 13:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Boqun Feng, Ingo Molnar, Will Deacon, David S. Miller,
Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu
In-Reply-To: <20251212110928.GP3911114@noisy.programming.kicks-ass.net>
On Fri, Dec 12, 2025 at 12:09PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 12, 2025 at 11:15:29AM +0100, Marco Elver wrote:
> > On Fri, 12 Dec 2025 at 10:43, Peter Zijlstra <peterz@infradead.org> wrote:
> > [..]
> > > > Correct. We're trading false negatives over false positives at this
> > > > point, just to get things to compile cleanly.
> > >
> > > Right, and this all 'works' right up to the point someone sticks a
> > > must_not_hold somewhere.
> > >
> > > > > > Better support for Linux's scoped guard design could be added in
> > > > > > future if deemed critical.
> > > > >
> > > > > I would think so, per the above I don't think this is 'right'.
> > > >
> > > > It's not sound, but we'll avoid false positives for the time being.
> > > > Maybe we can wrangle the jigsaw of macros to let it correctly acquire
> > > > and then release (via a 2nd cleanup function), it might be as simple
> > > > as marking the 'constructor' with the right __acquires(..), and then
> > > > have a 2nd __attribute__((cleanup)) variable that just does a no-op
> > > > release via __release(..) so we get the already supported pattern
> > > > above.
> > >
> > > Right, like I mentioned in my previous email; it would be lovely if at
> > > the very least __always_inline would get a *very* early pass such that
> > > the above could be resolved without inter-procedural bits. I really
> > > don't consider an __always_inline as another procedure.
> > >
> > > Because as I already noted yesterday, cleanup is now all
> > > __always_inline, and as such *should* all end up in the one function.
> > >
> > > But yes, if we can get a magical mash-up of __cleanup and __release (let
> > > it be knows as __release_on_cleanup ?) that might also work I suppose.
> > > But I vastly prefer __always_inline actually 'working' ;-)
> >
> > The truth is that __always_inline working in this way is currently
> > infeasible. Clang and LLVM's architecture simply disallow this today:
> > the semantic analysis that -Wthread-safety does happens over the AST,
> > whereas always_inline is processed by early passes in the middle-end
> > already within LLVM's pipeline, well after semantic analysis. There's
> > a complexity budget limit for semantic analysis (type checking,
> > warnings, assorted other errors), and path-sensitive &
> > intra-procedural analysis over the plain AST is outside that budget.
> > Which is why tools like clang-analyzer exist (symbolic execution),
> > where it's possible to afford that complexity since that's not
> > something that runs for a normal compile.
> >
> > I think I've pushed the current version of Clang's -Wthread-safety
> > already far beyond what folks were thinking is possible (a variant of
> > alias analysis), but even my healthy disregard for the impossible
> > tells me that making path-sensitive intra-procedural analysis even if
> > just for __always_inline functions is quite possibly a fool's errand.
>
> Well, I had to propose it. Gotta push the envelope :-)
>
> > So either we get it to work with what we have, or give up.
>
> So I think as is, we can start. But I really do want the cleanup thing
> sorted, even if just with that __release_on_cleanup mashup or so.
Working on rebasing this to v6.19-rc1 and saw this new scoped seqlock
abstraction. For that one I was able to make it work like I thought we
could (below). Some awkwardness is required to make it work in
for-loops, which only let you define variables with the same type.
For <linux/cleanup.h> it needs some more thought due to extra levels of
indirection.
------ >8 ------
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index b5563dc83aba..5162962b4b26 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -1249,6 +1249,7 @@ struct ss_tmp {
};
static __always_inline void __scoped_seqlock_cleanup(struct ss_tmp *sst)
+ __no_context_analysis
{
if (sst->lock)
spin_unlock(sst->lock);
@@ -1278,6 +1279,7 @@ extern void __scoped_seqlock_bug(void);
static __always_inline void
__scoped_seqlock_next(struct ss_tmp *sst, seqlock_t *lock, enum ss_state target)
+ __no_context_analysis
{
switch (sst->state) {
case ss_done:
@@ -1320,9 +1322,18 @@ __scoped_seqlock_next(struct ss_tmp *sst, seqlock_t *lock, enum ss_state target)
}
}
+/*
+ * Context analysis helper to release seqlock at the end of the for-scope; the
+ * alias analysis of the compiler will recognize that the pointer @s is is an
+ * alias to @_seqlock passed to read_seqbegin(_seqlock) below.
+ */
+static __always_inline void __scoped_seqlock_cleanup_ctx(struct ss_tmp **s)
+ __releases_shared(*((seqlock_t **)s)) __no_context_analysis {}
+
#define __scoped_seqlock_read(_seqlock, _target, _s) \
for (struct ss_tmp _s __cleanup(__scoped_seqlock_cleanup) = \
- { .state = ss_lockless, .data = read_seqbegin(_seqlock) }; \
+ { .state = ss_lockless, .data = read_seqbegin(_seqlock) }, \
+ *__UNIQUE_ID(ctx) __cleanup(__scoped_seqlock_cleanup_ctx) = (struct ss_tmp *)_seqlock; \
_s.state != ss_done; \
__scoped_seqlock_next(&_s, _seqlock, _target))
diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
index 4612025a1065..3f72b1ab2300 100644
--- a/lib/test_context-analysis.c
+++ b/lib/test_context-analysis.c
@@ -261,6 +261,13 @@ static void __used test_seqlock_writer(struct test_seqlock_data *d)
write_sequnlock_irqrestore(&d->sl, flags);
}
+static void __used test_seqlock_scoped(struct test_seqlock_data *d)
+{
+ scoped_seqlock_read (&d->sl, ss_lockless) {
+ (void)d->counter;
+ }
+}
+
struct test_rwsem_data {
struct rw_semaphore sem;
int counter __guarded_by(&sem);
^ permalink raw reply related
* Re: [RFC][PATCH v2] ima: Add support for staging measurements for deletion and trimming
From: Roberto Sassu @ 2025-12-15 12:41 UTC (permalink / raw)
To: Paul Moore
Cc: corbet, zohar, dmitry.kasatkin, eric.snowberg, jmorris, serge,
linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <CAHC9VhRUQxayj=XcdfbfHka-=N+B8cNk7Grg3QWGOTOz3BKfgw@mail.gmail.com>
On Fri, 2025-12-12 at 21:06 -0500, Paul Moore wrote:
> On Fri, Dec 12, 2025 at 12:19 PM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> >
> > Introduce the ability of staging the entire (or a portion of the) IMA
> > measurement list for deletion. Staging means moving the current content of
> > the measurement list to a separate location, and allowing users to read and
> > delete it. This causes the measurement list to be atomically truncated
> > before new measurements can be added. Staging can be done only once at a
> > time. In the event of kexec(), staging is reverted and staged entries will
> > be carried over to the new kernel.
> >
> > User space is responsible to concatenate the staged IMA measurements list
> > portions following the temporal order in which the operations were done,
> > together with the current measurement list. Then, it can send the collected
> > data to the remote verifiers.
> >
> > Also introduce the ability of trimming N measurements entries from the IMA
> > measurements list, provided that user space has already read them. Trimming
> > combines staging and deletion in one operation.
> >
> > The benefit of these solutions is the ability to free precious kernel
> > memory, in exchange of delegating user space to reconstruct the full
> > measurement list from the chunks. No trust needs to be given to user space,
> > since the integrity of the measurement list is protected by the TPM.
> >
> > By default, staging/trimming the measurements list does not alter the hash
> > table. When staging/trimming are done, IMA is still able to detect
> > collisions on the staged and later deleted measurement entries, by keeping
> > the entry digests (only template data are freed).
> >
> > However, since during the measurements list serialization only the SHA1
> > digest is passed, and since there are no template data to recalculate the
> > other digests from, the hash table is currently not populated with digests
> > from staged/deleted entries after kexec().
> >
> > Introduce the new kernel option ima_flush_htable to decide whether or not
> > the digests of staged measurement entries are flushed from the hash table.
> >
> > Then, introduce ascii_runtime_measurements_staged_<algo> and
> > binary_runtime_measurement_staged_<algo> interfaces to stage/trim/delete
> > the measurements. Use 'echo A > <IMA interface>' and
> > 'echo D > <IMA interface>' to respectively stage and delete the entire
> > measurements list. Use 'echo N > <IMA interface>', with N between 1 and
> > LONG_MAX, to stage the selected portion of the measurements list, and
> > 'echo -N > <IMA interface>' to trim N measurements entries.
>
> In an effort to help preserve the sanity of admins, I might suggest
> avoiding commands that start with a dash/'-'. I'd probably also
> simplify the commands a bit and drop all/'A' since the measurement
> list could change at any time, stick with an explicit number and just
> let the admin go over, e.g. write LONG_MAX, which effectively becomes
> 'A'. I think you could do everything you need with just two commands:
>
> <NUM>: stage <NUM> entries
> D: delete staged entries
If the goal is that the verifier always receives a TPM quote aligned
with the measurements, the remote attestation agent in the target
system has to walk over the measurements to find N.
The difference between the approach I was suggesting and Steven's is
that I calculate N after staging all measurements and store the
exceeding measurements locally until the next attestation request. If
the verifier supports it, the exceeding measurements could be stored
also there.
That means that I don't need to walk in the measurement list to stage,
because I stage the entire list (with list_replace()). I do a walk
after detaching, without interfering with the processes adding new
measurements (hot path).
Steven's approach is to read the measurements list to calculate N and
stage/trim the measurement based on N. As Steven/Gregory pointed out,
at this point you could already trim N because you already have the
measurements list.
However, in this case you have to walk through the measurements list as
an RCU reader in the hot path, calculate N, and walk through the
measurements list again as an RCU writer in the hot path to stage/trim
N. In the next attestation request, you would read the previous
exceeding measurements again.
One major obstacle of my approach, as Gregory pointed out, was that
staged measurements were not carried over during kexec(). While I
thought about coordinating remote attestation requests with kexec() in
a management engine, there can be cases where this is harder to
achieve.
I managed to solve that by introducing a third linked list containing
the measurements to delete, by doing another list replace between
staged and measurements to delete (when the 'D' command is issued),
under the hot path lock. That allowed me to take the hot path lock
during kexec() and prepend the staged measurements before the non-
staged ones (that reminded me that I should properly inform user space
if kexec() consumed staged measurements before the 'D' command was
executed, i.e. it lost the race with kexec()).
The approach to keep the stage N approach would be necessary if
exceeding measurements cannot be stored either locally or at the
verifier side.
For me it would be fine to keep both approaches, but I still see
advantages of the stage all approach.
Thanks
Roberto
> I intentionally left out the trim/'T' command, because I'm not sure it
> is really necessary if you are going to implement the phased
> stage/delete process. Yes, you have to do two operations (stage and
> delete) as opposed to just the trim, but I'd probably take the
> simplicity of just supporting a single approach over the trivial
> necessity of having to do two operations in userspace.
>
> Staging also has the benefit of having a sane way of handling two
> tasks racing to stage the measurement list. I could see cases where
> multiple tasks race to trim the list and end up trimming more than was
> intended since they both hit in sequence.
>
> If you did want to take a trim approach over a stage/delete approach,
> I could see something like this working:
>
> 1. process opens the measurement list
> 2. process reads from the measurement list, keeps the fd open
> 3. process does whatever it wants to preserve the list
> 4. process writes <NUM> to the measurement list, kernel trims <NUM> entries
> 5. process closes fd
>
> ... error handling shouldn't be too bad. The process only writes
> <NUM> to the fd if it has already finished whatever it needs to do to
> preserve the list outside the kernel, think of it as a "commit"
> operation on a transaction. If the fd is closed for some reason
> (error, interruption, killed) before the process writes <NUM> to the
> fd then IMA does nothing - no trim takes place.
>
> Multiple process racing can easily be solved when the log is opened;
> only one open(O_RDWR) is allowed at a time, other racing processes
> will get EBUSY. Yes, one process could block others from trimming by
> holding the fd open for an extended period of time, but I would expect
> that CAP_SYS_ADMIN and root fs perms would be required to open the log
> read/write (not to mention any LSM access rights in place).
>
> I know I mentioned this basic idea to someone at some point, but there
> have been various discussion threads and multiple people over a fairly
> lengthy time that I've lost track of where it was mentioned. If it
> was already discussed on-list and rejected for a good reason you can
> simply ignore the above approach ... although I still think the
> stage/delete API could be simplified as described :)
>
> [UPDATE: as I'm reading Steven's replies it looks like he has proposed
> something very similar to the above]
>
^ permalink raw reply
* Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host
From: Mickaël Salaün @ 2025-12-15 11:27 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Günther Noack, Alyssa Ross, Spectrum OS Development,
linux-security-module, landlock, Ryan B. Sullivan,
Günther Noack
In-Reply-To: <2a681b48-bc6e-4257-8e0f-3b6aff25ac67@gmail.com>
On Mon, Dec 15, 2025 at 03:54:25AM -0500, Demi Marie Obenour wrote:
> On 12/15/25 03:20, Günther Noack wrote:
> > On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
> >> On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
> >>> On 12/13/25 20:39, Alyssa Ross wrote:
> >>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
> >>>>
> >>>>> On 12/13/25 16:42, Alyssa Ross wrote:
> >>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
> >>>>>>
> >>>>>>> On 12/13/25 14:12, Alyssa Ross wrote:
> >>>>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
> >>>>>>>>
> >>>>>>>>> It is quite possible that these Landlock rules are unnecessarily
> >>>>>>>>> permissive, but all of the paths to which read and execute access is
> >>>>>>>>> granted are part of the root filesystem and therefore assumed to be
> >>>>>>>>> public knowledge. Removing access from any of them would only increase
> >>>>>>>>> the risk of accidental breakage in the future, and would not provide any
> >>>>>>>>> security improvements. seccomp *could* provide some improvements, but
> >>>>>>>>> the effort needed is too high for now.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++
> >>>>>>>>> 1 file changed, 8 insertions(+)
> >>>>>>>>
> >>>>>>>> Are you sure this is working as intended? There's no rule allowing
> >>>>>>>> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be
> >>>>>>>> able to access that. Don't you need to set a rule that *restricts*
> >>>>>>>> filesystem access and then add holes? Did you ever see this deny
> >>>>>>>> anything?
> >>>>>>>
> >>>>>>> 'man 1 setpriv' states that '--landlock-access fs' blocks all
> >>>>>>> filesystem access unless a subsequent --landlock-rule permits it.
> >>>>>>> I tried running with no --landlock-rule flags and the execve of
> >>>>>>> xdg-desktop-portal-spectrum-host failed as expected.
> >>>>>>>
> >>>>>>> The socket is passed over stdin, and I'm pretty sure Landlock
> >>>>>>> doesn't restrict using an already-open file descriptor.
> >>>>>>> xdg-desktop-portal-spectrum-host does need to find the path to the
> >>>>>>> socket, but I don't think it ever accesses that path.
> >>>>>>
> >>>>>> I've been looking into this a bit myself, and from what I can tell
> >>>>>> Landlock just doesn't restrict connecting to sockets at all, even if
> >>>>>> they're inside directories that would otherwise be inaccessible. It's
> >>>>>> able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus
> >>>>>> socket even with a maximally restrictive landlock rule. So you were
> >>>>>> right after all, sorry!
> >>>>>
> >>>>> That's not good at all! It's a trivial sandbox escape in so many cases.
> >>>>> For instance, with access to D-Bus I can just call `systemd-run`.
> >>>>>
> >>>>> I'm CCing the Landlock and LSM mailing lists because if you are
> >>>>> correct, then this is a bad security hole.
> >>>>
> >>>> I don't find it that surprising given the way landlock works. "connect"
> >>>> (to a non-abstract AF_UNIX socket) is not an operation there's a
> >>>> landlock action for, and it's not like the other actions care about
> >>>> access to parent directories and the like — I was able to execute a
> >>>> program via a symlink after only giving access to the symlink's target,
> >>>> without any access to the directory containing the symlink or the
> >>>> symlink itself, for example. Landlock, as I understand it, is intended
> >>>> to block a specified set of operations (on particular file hierarchies),
> >>>> rather than to completely prevent access to those hierarchies like
> >>>> permissions or mount namespaces could, so the lack of a way to block
> >>>> connecting to a socket is more of a missing feature than a security
> >>>> hole.
> >>>
> >>> 'man 7 unix' states:
> >>>
> >>> On Linux, connecting to a stream socket object requires write
> >>> permission on that socket; sending a datagram to a datagram socket
> >>> likewise requires write permission on that socket.
> >>>
> >>> Landlock is definitely being inconsistent with DAC here. Also, this
> >>> allows real-world sandbox breakouts. On systemd systems, the simplest
> >>> way to escape is to use systemd-run to execute arbitrary commands.
> >>
> >> The Linux kernel is complex and the link between the VFS and named UNIX
> >> sockets is "special" (see the linked GitHub issue). Landlock doesn't
> >> handle named UNIX sockets yet for the same reason it doesn't handle some
> >> other kind of kernel resources or access rights: someone needs to
> >> implement it (including tests, doc...). There is definitely interest to
> >> add this feature, it has been discussed for some time, but it's not
> >> trivial. It is a work in progress though:
> >> https://github.com/landlock-lsm/linux/issues/36
> >
> > Agreed, this would be the change that would let us restrict connect()
> > on AF_UNIX sockets.
> >
> > Additionally, *in the case that you do not actually need* Unix
> > sockets, the other patch set that would be of interest is the one for
> > restricting the creation of new socket FDs:
> > https://github.com/landlock-lsm/linux/issues/6
> >
> > In this talk in 2014, I explained my mental model around the
> > network-related restrictions:
> > https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030
> >
> > The discussed socket control feature continues to be a central missing
> > piece, as the TCP port restrictions do not make much sense as long as
> > you can still create sockets for other protocol types.
> >
> > Issue #6 that should fix this is still under active development -- an
> > updated version of the patch was posted just last month.
> >
> > To bridge the gap, the same thing can also be emulated with seccomp,
> > but as you noted above as well in this thread, this is harder.
> >
> > –Günther
>
> I'm a bit surprised that this needs to be separate from other access
> controls. To me, it seems like a bit of a misdesign in the core kernel
> (not Landlock).
>
> I would go as far as to state that enabling other filesystem
> restrictions should also restrict AF_UNIX filesystem sockets
> automatically, as that is what users and administrators will expect.
I agree, that would be nice, but it's legacy.
>
> What surprises me somewhat is that Linux does not have any sort of
> unified hook for filesystem path walks. My mental model of Landlock
> is that from a filesystem perspective, the result should be equivalent
> to creating an empty mount namespace, putting a tmpfs on its root,
> and bind-mounting the allowed paths. That this mental model does
> not match reality was quite surprising.
The approach taken by Landlock is to not break user space with kernel
updates, follow an incremental approach, and have a nice compatibility
story. This is why a ruleset is created with a set of well-defined
"handled" access rights and restrictions. Each new handled access right
or restriction must come with an explicit request from user space (e.g.
set new bits in struct landlock_ruleset_attr).
It would have been appealing to start from scratch, drop all access
rights, and then gradually implement access rights, but that would have
make Landlock unusable in most use cases. Instead, we gradually extend
the scope of Landlock with well-defined and well-tested restrictions.
This approach eases the integration of Landlock and when new kernel
features are available, it's easy to update an integration to leverage
the new features. From day one, Landlock has been useful, even if it
doesn't cover all use cases and environments. When sandboxing a program
(or properly securing an OS), most of the time, the difficult part is to
get a good security architecture with proper privilege separation. Once
this is done, it's much easier to gradually improve it.
We should probably improve the Landlock documentation, especially by
extending the warning block with some other relevant syscalls:
https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-15 9:32 UTC (permalink / raw)
To: Sumit Garg
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, Ard Biesheuvel,
Maxime Coquelin, Alexandre Torgue, Sumit Garg, Ilias Apalodimas,
Jan Kiszka, Sudeep Holla, Christophe JAILLET, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <aT--ox375kg2Mzh-@sumit-X1>
[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]
Hello Sumit,
On Mon, Dec 15, 2025 at 04:54:11PM +0900, Sumit Garg wrote:
> On Thu, Dec 11, 2025 at 06:14:54PM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > the objective of this series is to make tee driver stop using callbacks
> > in struct device_driver. These were superseded by bus methods in 2006
> > (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> > methods.")) but nobody cared to convert all subsystems accordingly.
> >
> > Here the tee drivers are converted. The first commit is somewhat
> > unrelated, but simplifies the conversion (and the drivers). It
> > introduces driver registration helpers that care about setting the bus
> > and owner. (The latter is missing in all drivers, so by using these
> > helpers the drivers become more correct.)
> >
> > The patches #4 - #17 depend on the first two, so if they should be
> > applied to their respective subsystem trees these must contain the first
> > two patches first.
>
> Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
> drivers.
Thanks for your feedback. I will prepare a v2 and address your comments
(whitespace issues and wrong callback in the shutdown method).
> > Note that after patch #2 is applied, unconverted drivers provoke a
> > warning in driver_register(), so it would be good for the user
> > experience if the whole series goes in during a single merge window.
>
> +1
>
> I suggest the whole series goes via the Jens tree since there shouldn't
> be any chances for conflict here.
>
> > So
> > I guess an immutable branch containing the frist three patches that can
> > be merged into the other subsystem trees would be sensible.
> >
> > After all patches are applied, tee_bus_type can be made private to
> > drivers/tee as it's not used in other places any more.
> >
>
> Feel free to make the tee_bus_type private as the last patch in the series
> such that any followup driver follows this clean approach.
There is a bit more to do for that than I'm willing to invest. With my
patch series applied `tee_bus_type` is still used in
drivers/tee/optee/device.c and drivers/tee/tee_core.c. Maybe it's
sensible to merge these two files into a single one.
The things I wonder about additionally are:
- if CONFIG_OPTEE=n and CONFIG_TEE=y|m the tee bus is only used for
drivers but not devices.
- optee_register_device() calls device_create_file() on
&optee_device->dev after device_register(&optee_device->dev).
(Attention half-knowledge!) I think device_create_file() should not
be called on an already registered device (or you have to send a
uevent afterwards). This should probably use type attribute groups.
(Or the need_supplicant attribute should be dropped as it isn't very
useful. This would maybe be considered an ABI change however.)
- Why does optee_probe() in drivers/tee/optee/smc_abi.c unregister all
optee devices in its error path (optee_unregister_devices())?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host
From: Demi Marie Obenour @ 2025-12-15 8:54 UTC (permalink / raw)
To: Günther Noack, Mickaël Salaün
Cc: Alyssa Ross, Spectrum OS Development, linux-security-module,
landlock, Ryan B. Sullivan, Günther Noack
In-Reply-To: <20251215.5d7e473daa34@gnoack.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 6574 bytes --]
On 12/15/25 03:20, Günther Noack wrote:
> On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
>> On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
>>> On 12/13/25 20:39, Alyssa Ross wrote:
>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>
>>>>> On 12/13/25 16:42, Alyssa Ross wrote:
>>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>>>
>>>>>>> On 12/13/25 14:12, Alyssa Ross wrote:
>>>>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>>>>>
>>>>>>>>> It is quite possible that these Landlock rules are unnecessarily
>>>>>>>>> permissive, but all of the paths to which read and execute access is
>>>>>>>>> granted are part of the root filesystem and therefore assumed to be
>>>>>>>>> public knowledge. Removing access from any of them would only increase
>>>>>>>>> the risk of accidental breakage in the future, and would not provide any
>>>>>>>>> security improvements. seccomp *could* provide some improvements, but
>>>>>>>>> the effort needed is too high for now.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
>>>>>>>>> ---
>>>>>>>>> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++
>>>>>>>>> 1 file changed, 8 insertions(+)
>>>>>>>>
>>>>>>>> Are you sure this is working as intended? There's no rule allowing
>>>>>>>> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be
>>>>>>>> able to access that. Don't you need to set a rule that *restricts*
>>>>>>>> filesystem access and then add holes? Did you ever see this deny
>>>>>>>> anything?
>>>>>>>
>>>>>>> 'man 1 setpriv' states that '--landlock-access fs' blocks all
>>>>>>> filesystem access unless a subsequent --landlock-rule permits it.
>>>>>>> I tried running with no --landlock-rule flags and the execve of
>>>>>>> xdg-desktop-portal-spectrum-host failed as expected.
>>>>>>>
>>>>>>> The socket is passed over stdin, and I'm pretty sure Landlock
>>>>>>> doesn't restrict using an already-open file descriptor.
>>>>>>> xdg-desktop-portal-spectrum-host does need to find the path to the
>>>>>>> socket, but I don't think it ever accesses that path.
>>>>>>
>>>>>> I've been looking into this a bit myself, and from what I can tell
>>>>>> Landlock just doesn't restrict connecting to sockets at all, even if
>>>>>> they're inside directories that would otherwise be inaccessible. It's
>>>>>> able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus
>>>>>> socket even with a maximally restrictive landlock rule. So you were
>>>>>> right after all, sorry!
>>>>>
>>>>> That's not good at all! It's a trivial sandbox escape in so many cases.
>>>>> For instance, with access to D-Bus I can just call `systemd-run`.
>>>>>
>>>>> I'm CCing the Landlock and LSM mailing lists because if you are
>>>>> correct, then this is a bad security hole.
>>>>
>>>> I don't find it that surprising given the way landlock works. "connect"
>>>> (to a non-abstract AF_UNIX socket) is not an operation there's a
>>>> landlock action for, and it's not like the other actions care about
>>>> access to parent directories and the like — I was able to execute a
>>>> program via a symlink after only giving access to the symlink's target,
>>>> without any access to the directory containing the symlink or the
>>>> symlink itself, for example. Landlock, as I understand it, is intended
>>>> to block a specified set of operations (on particular file hierarchies),
>>>> rather than to completely prevent access to those hierarchies like
>>>> permissions or mount namespaces could, so the lack of a way to block
>>>> connecting to a socket is more of a missing feature than a security
>>>> hole.
>>>
>>> 'man 7 unix' states:
>>>
>>> On Linux, connecting to a stream socket object requires write
>>> permission on that socket; sending a datagram to a datagram socket
>>> likewise requires write permission on that socket.
>>>
>>> Landlock is definitely being inconsistent with DAC here. Also, this
>>> allows real-world sandbox breakouts. On systemd systems, the simplest
>>> way to escape is to use systemd-run to execute arbitrary commands.
>>
>> The Linux kernel is complex and the link between the VFS and named UNIX
>> sockets is "special" (see the linked GitHub issue). Landlock doesn't
>> handle named UNIX sockets yet for the same reason it doesn't handle some
>> other kind of kernel resources or access rights: someone needs to
>> implement it (including tests, doc...). There is definitely interest to
>> add this feature, it has been discussed for some time, but it's not
>> trivial. It is a work in progress though:
>> https://github.com/landlock-lsm/linux/issues/36
>
> Agreed, this would be the change that would let us restrict connect()
> on AF_UNIX sockets.
>
> Additionally, *in the case that you do not actually need* Unix
> sockets, the other patch set that would be of interest is the one for
> restricting the creation of new socket FDs:
> https://github.com/landlock-lsm/linux/issues/6
>
> In this talk in 2014, I explained my mental model around the
> network-related restrictions:
> https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030
>
> The discussed socket control feature continues to be a central missing
> piece, as the TCP port restrictions do not make much sense as long as
> you can still create sockets for other protocol types.
>
> Issue #6 that should fix this is still under active development -- an
> updated version of the patch was posted just last month.
>
> To bridge the gap, the same thing can also be emulated with seccomp,
> but as you noted above as well in this thread, this is harder.
>
> –Günther
I'm a bit surprised that this needs to be separate from other access
controls. To me, it seems like a bit of a misdesign in the core kernel
(not Landlock).
I would go as far as to state that enabling other filesystem
restrictions should also restrict AF_UNIX filesystem sockets
automatically, as that is what users and administrators will expect.
What surprises me somewhat is that Linux does not have any sort of
unified hook for filesystem path walks. My mental model of Landlock
is that from a filesystem perspective, the result should be equivalent
to creating an empty mount namespace, putting a tmpfs on its root,
and bind-mounting the allowed paths. That this mental model does
not match reality was quite surprising.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 8:49 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <60cf8bd2afbad5e930119d73ccf069e95ee4fd9d.camel@HansenPartnership.com>
On Mon, Dec 15, 2025 at 04:55:58PM +0900, James Bottomley wrote:
> On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > > thus its use should be pooled rather than directly used. This
> > > > both reduces latency and improves its predictability.
> > > >
> > > > 2. Linux is better off overall if every subsystem uses the same
> > > > source for the random bistream as the de-facto choice, unless
> > > > *force majeure* reasons point to some other direction.
> > > >
> > > > In the case, of TPM there is no reason for trusted keys to invoke
> > > > TPM directly.
> > >
> > > That assertion isn't correct: you seem to have forgotten we had
> > > this argument six or seven years ago, but even that was a reprise
> > > of an even earlier one. Lore doesn't go back far enough for the
> > > intermediate one on the tpm list, but the original was cc'd to
> > > lkml:
> > >
> > > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> > >
> > > The decision then was to use the same random source as the key
> > > protection. Unfortunately most of the active participants have
> > > moved on from IBM and I don't have their current email addresses,
> > > but the bottom line is there were good reasons to do trusted keys
> > > this way that your assertions above don't overcome. I'm not saying
> > > we shouldn't reconsider the situation, but we need a reasoned
> > > debate rather than simply doing it by fiat.
> >
> > The way I see this is that given that kernel is not running inside
> > TPM, FIPS certification of the RNG does not have any measurable
> > value.
> >
> > Random data generation should happen as part of object creation
> > process i.e. should be fully self-contained process within the TPM in
> > order for FIPS to matter.
>
> In FIPS terms, there's no distinction between keeping the whole
> generation process internal to the TPM and using the FIPS certified rng
> of the TPM to source the contents of a kernel protected key. Both
> provide equally valid, and FIPS certified data.
I understand being "FIPS certified" embedding the premise that kernel
is also FIPS certified, which covers also crypto etc. This is the case
with enterprise kernels.
I have understanding FIPS certification dies at the point when random
data is acquired by a kernel, which is not FIPS certified. It's not
really a safe closure.
Using same code path for RNG universally should actually help with any
certification processes.
>
> > In the case of sealed data objects, this not the case.
>
> FIPS is concerned with origins and provenance, so it most certainly is
> the case even for trusted keys. However, if the Kernel RNG is fips
> certified (as can happen with certain FIPS modules) it is the case that
> either the Kernel or TPM RNG would satisfy the FIPS requirement. The
> question for trusted key users is really do they always want the TPM
> FIPS RNG or should we allow mixing with the kernel RNG even in the non-
> FIPS case.
I don't disagree on benefits of FIPS certification.
>
> Perhaps, rather than getting hung up on FIPS sources and to facilitate
> debating the bedrock requirements, we could turn this around and ask
> what the use case you have for using the in-kernel RNG is?
Generally removing any non-mandatory TPM traffic is a feasible idea.
This was just something low-hanging fruit that I spotted while working
on larger patch set.
BR, Jarkko
>
> Regards,
>
> James
>
>
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] host/roots: Sandbox xdg-desktop-portal-spectrum-host
From: Günther Noack @ 2025-12-15 8:20 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Demi Marie Obenour, Alyssa Ross, Spectrum OS Development,
linux-security-module, landlock, Ryan B. Sullivan,
Günther Noack
In-Reply-To: <20251214.aiW5oc2izaxa@digikod.net>
On Sun, Dec 14, 2025 at 08:50:45PM +0100, Mickaël Salaün wrote:
> On Sat, Dec 13, 2025 at 11:49:11PM -0500, Demi Marie Obenour wrote:
> > On 12/13/25 20:39, Alyssa Ross wrote:
> > > Demi Marie Obenour <demiobenour@gmail.com> writes:
> > >
> > >> On 12/13/25 16:42, Alyssa Ross wrote:
> > >>> Demi Marie Obenour <demiobenour@gmail.com> writes:
> > >>>
> > >>>> On 12/13/25 14:12, Alyssa Ross wrote:
> > >>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
> > >>>>>
> > >>>>>> It is quite possible that these Landlock rules are unnecessarily
> > >>>>>> permissive, but all of the paths to which read and execute access is
> > >>>>>> granted are part of the root filesystem and therefore assumed to be
> > >>>>>> public knowledge. Removing access from any of them would only increase
> > >>>>>> the risk of accidental breakage in the future, and would not provide any
> > >>>>>> security improvements. seccomp *could* provide some improvements, but
> > >>>>>> the effort needed is too high for now.
> > >>>>>>
> > >>>>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> > >>>>>> ---
> > >>>>>> .../template/data/service/xdg-desktop-portal-spectrum-host/run | 8 ++++++++
> > >>>>>> 1 file changed, 8 insertions(+)
> > >>>>>
> > >>>>> Are you sure this is working as intended? There's no rule allowing
> > >>>>> access to Cloud Hypervisor's VSOCK socket, and yet it still seems to be
> > >>>>> able to access that. Don't you need to set a rule that *restricts*
> > >>>>> filesystem access and then add holes? Did you ever see this deny
> > >>>>> anything?
> > >>>>
> > >>>> 'man 1 setpriv' states that '--landlock-access fs' blocks all
> > >>>> filesystem access unless a subsequent --landlock-rule permits it.
> > >>>> I tried running with no --landlock-rule flags and the execve of
> > >>>> xdg-desktop-portal-spectrum-host failed as expected.
> > >>>>
> > >>>> The socket is passed over stdin, and I'm pretty sure Landlock
> > >>>> doesn't restrict using an already-open file descriptor.
> > >>>> xdg-desktop-portal-spectrum-host does need to find the path to the
> > >>>> socket, but I don't think it ever accesses that path.
> > >>>
> > >>> I've been looking into this a bit myself, and from what I can tell
> > >>> Landlock just doesn't restrict connecting to sockets at all, even if
> > >>> they're inside directories that would otherwise be inaccessible. It's
> > >>> able to connect to both Cloud Hypervisor's VSOCK socket and the D-Bus
> > >>> socket even with a maximally restrictive landlock rule. So you were
> > >>> right after all, sorry!
> > >>
> > >> That's not good at all! It's a trivial sandbox escape in so many cases.
> > >> For instance, with access to D-Bus I can just call `systemd-run`.
> > >>
> > >> I'm CCing the Landlock and LSM mailing lists because if you are
> > >> correct, then this is a bad security hole.
> > >
> > > I don't find it that surprising given the way landlock works. "connect"
> > > (to a non-abstract AF_UNIX socket) is not an operation there's a
> > > landlock action for, and it's not like the other actions care about
> > > access to parent directories and the like — I was able to execute a
> > > program via a symlink after only giving access to the symlink's target,
> > > without any access to the directory containing the symlink or the
> > > symlink itself, for example. Landlock, as I understand it, is intended
> > > to block a specified set of operations (on particular file hierarchies),
> > > rather than to completely prevent access to those hierarchies like
> > > permissions or mount namespaces could, so the lack of a way to block
> > > connecting to a socket is more of a missing feature than a security
> > > hole.
> >
> > 'man 7 unix' states:
> >
> > On Linux, connecting to a stream socket object requires write
> > permission on that socket; sending a datagram to a datagram socket
> > likewise requires write permission on that socket.
> >
> > Landlock is definitely being inconsistent with DAC here. Also, this
> > allows real-world sandbox breakouts. On systemd systems, the simplest
> > way to escape is to use systemd-run to execute arbitrary commands.
>
> The Linux kernel is complex and the link between the VFS and named UNIX
> sockets is "special" (see the linked GitHub issue). Landlock doesn't
> handle named UNIX sockets yet for the same reason it doesn't handle some
> other kind of kernel resources or access rights: someone needs to
> implement it (including tests, doc...). There is definitely interest to
> add this feature, it has been discussed for some time, but it's not
> trivial. It is a work in progress though:
> https://github.com/landlock-lsm/linux/issues/36
Agreed, this would be the change that would let us restrict connect()
on AF_UNIX sockets.
Additionally, *in the case that you do not actually need* Unix
sockets, the other patch set that would be of interest is the one for
restricting the creation of new socket FDs:
https://github.com/landlock-lsm/linux/issues/6
In this talk in 2014, I explained my mental model around the
network-related restrictions:
https://youtu.be/K2onopkMhuM?si=LCObEX6HhGdzPnks&t=2030
The discussed socket control feature continues to be a central missing
piece, as the TCP port restrictions do not make much sense as long as
you can still create sockets for other protocol types.
Issue #6 that should fix this is still under active development -- an
updated version of the patch was posted just last month.
To bridge the gap, the same thing can also be emulated with seccomp,
but as you noted above as well in this thread, this is harder.
–Günther
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: James Bottomley @ 2025-12-15 7:55 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <aT-uHgyYw3XhFasi@kernel.org>
On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > thus its use should be pooled rather than directly used. This
> > > both reduces latency and improves its predictability.
> > >
> > > 2. Linux is better off overall if every subsystem uses the same
> > > source for the random bistream as the de-facto choice, unless
> > > *force majeure* reasons point to some other direction.
> > >
> > > In the case, of TPM there is no reason for trusted keys to invoke
> > > TPM directly.
> >
> > That assertion isn't correct: you seem to have forgotten we had
> > this argument six or seven years ago, but even that was a reprise
> > of an even earlier one. Lore doesn't go back far enough for the
> > intermediate one on the tpm list, but the original was cc'd to
> > lkml:
> >
> > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> >
> > The decision then was to use the same random source as the key
> > protection. Unfortunately most of the active participants have
> > moved on from IBM and I don't have their current email addresses,
> > but the bottom line is there were good reasons to do trusted keys
> > this way that your assertions above don't overcome. I'm not saying
> > we shouldn't reconsider the situation, but we need a reasoned
> > debate rather than simply doing it by fiat.
>
> The way I see this is that given that kernel is not running inside
> TPM, FIPS certification of the RNG does not have any measurable
> value.
>
> Random data generation should happen as part of object creation
> process i.e. should be fully self-contained process within the TPM in
> order for FIPS to matter.
In FIPS terms, there's no distinction between keeping the whole
generation process internal to the TPM and using the FIPS certified rng
of the TPM to source the contents of a kernel protected key. Both
provide equally valid, and FIPS certified data.
> In the case of sealed data objects, this not the case.
FIPS is concerned with origins and provenance, so it most certainly is
the case even for trusted keys. However, if the Kernel RNG is fips
certified (as can happen with certain FIPS modules) it is the case that
either the Kernel or TPM RNG would satisfy the FIPS requirement. The
question for trusted key users is really do they always want the TPM
FIPS RNG or should we allow mixing with the kernel RNG even in the non-
FIPS case.
Perhaps, rather than getting hung up on FIPS sources and to facilitate
debating the bedrock requirements, we could turn this around and ask
what the use case you have for using the in-kernel RNG is?
Regards,
James
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Sumit Garg @ 2025-12-15 7:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, Ard Biesheuvel,
Maxime Coquelin, Alexandre Torgue, Sumit Garg, Ilias Apalodimas,
Jan Kiszka, Sudeep Holla, Christophe JAILLET, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <cover.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:14:54PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> the objective of this series is to make tee driver stop using callbacks
> in struct device_driver. These were superseded by bus methods in 2006
> (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> methods.")) but nobody cared to convert all subsystems accordingly.
>
> Here the tee drivers are converted. The first commit is somewhat
> unrelated, but simplifies the conversion (and the drivers). It
> introduces driver registration helpers that care about setting the bus
> and owner. (The latter is missing in all drivers, so by using these
> helpers the drivers become more correct.)
>
> The patches #4 - #17 depend on the first two, so if they should be
> applied to their respective subsystem trees these must contain the first
> two patches first.
Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
drivers.
>
> Note that after patch #2 is applied, unconverted drivers provoke a
> warning in driver_register(), so it would be good for the user
> experience if the whole series goes in during a single merge window.
+1
I suggest the whole series goes via the Jens tree since there shouldn't
be any chances for conflict here.
> So
> I guess an immutable branch containing the frist three patches that can
> be merged into the other subsystem trees would be sensible.
>
> After all patches are applied, tee_bus_type can be made private to
> drivers/tee as it's not used in other places any more.
>
Feel free to make the tee_bus_type private as the last patch in the series
such that any followup driver follows this clean approach.
-Sumit
> Best regards
> Uwe
>
> Uwe Kleine-König (17):
> tee: Add some helpers to reduce boilerplate for tee client drivers
> tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> tee: Adapt documentation to cover recent additions
> hwrng: optee - Make use of module_tee_client_driver()
> hwrng: optee - Make use of tee bus methods
> rtc: optee: Migrate to use tee specific driver registration function
> rtc: optee: Make use of tee bus methods
> efi: stmm: Make use of module_tee_client_driver()
> efi: stmm: Make use of tee bus methods
> firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> firmware: arm_scmi: Make use of tee bus methods
> firmware: tee_bnxt: Make use of module_tee_client_driver()
> firmware: tee_bnxt: Make use of tee bus methods
> KEYS: trusted: Migrate to use tee specific driver registration
> function
> KEYS: trusted: Make use of tee bus methods
> tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> tpm/tpm_ftpm_tee: Make use of tee bus methods
>
> Documentation/driver-api/tee.rst | 18 +----
> drivers/char/hw_random/optee-rng.c | 26 ++----
> drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
> drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
> drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
> drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
> drivers/rtc/rtc-optee.c | 27 ++-----
> drivers/tee/tee_core.c | 84 ++++++++++++++++++++
> include/linux/tee_drv.h | 12 +++
> security/keys/trusted-keys/trusted_tee.c | 17 ++--
> 10 files changed, 164 insertions(+), 138 deletions(-)
>
>
> base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
> --
> 2.47.3
>
^ permalink raw reply
* Re: A formal request for process clarifications.
From: Linus Torvalds @ 2025-12-15 7:38 UTC (permalink / raw)
To: Dr. Greg; +Cc: linux-security-module, corbet
In-Reply-To: <20251215070838.GA7209@wind.enjellic.com>
On Mon, 15 Dec 2025 at 19:13, Dr. Greg <greg@enjellic.com> wrote:
>
> Three years ago our team had submitted for review our TSEM LSM that
> provides a framework for generic security modeling,
If you can't convince the LSM people to take your code, you sure can't
convince me.
I already think we have too many of those pointless things. There's a
fine line between diversity and "too much confusion because everybody
thinks they know best". And the linux security modules passed that
line years ago.
So my suggestion is to standardize on normal existing security models
instead of thinking that you can do better by making yet another one.
Or at least work with the existing people instead of trying to bypass
them and ignoring what they tell you.
Yes, I know that security people always think they know best, and they
all disagree with each other, which is why we already have tons of
security modules. Ask ten people what model is the right one, and you
get fifteen different answers.
I'm not in the least interested in becoming some kind of arbiter or
voice of sanity in this.
Linus
^ permalink raw reply
* Re: [PATCH v1 15/17] KEYS: trusted: Make use of tee bus methods
From: Sumit Garg @ 2025-12-15 7:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, James Bottomley, Jarkko Sakkinen, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn, op-tee,
linux-integrity, keyrings, linux-security-module, linux-kernel
In-Reply-To: <aab4c00b7e89abce7bcd8241c47f3398fb7227f8.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:15:09PM +0100, Uwe Kleine-König wrote:
> The tee bus got dedicated callbacks for probe and remove.
> Make use of these. This fixes a runtime warning about the driver needing
> to be converted to the bus methods.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> security/keys/trusted-keys/trusted_tee.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
>
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> index 3cea9a377955..6e465c8bef5e 100644
> --- a/security/keys/trusted-keys/trusted_tee.c
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -202,9 +202,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> return 0;
> }
>
> -static int trusted_key_probe(struct device *dev)
> +static int trusted_key_probe(struct tee_client_device *rng_device)
> {
> - struct tee_client_device *rng_device = to_tee_client_device(dev);
> + struct device *dev = &rng_device->dev;
> int ret;
> struct tee_ioctl_open_session_arg sess_arg;
>
> @@ -244,13 +244,11 @@ static int trusted_key_probe(struct device *dev)
> return ret;
> }
>
> -static int trusted_key_remove(struct device *dev)
> +static void trusted_key_remove(struct tee_client_device *dev)
> {
> unregister_key_type(&key_type_trusted);
> tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> tee_client_close_context(pvt_data.ctx);
> -
> - return 0;
> }
>
> static const struct tee_client_device_id trusted_key_id_table[] = {
> @@ -261,11 +259,11 @@ static const struct tee_client_device_id trusted_key_id_table[] = {
> MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
>
> static struct tee_client_driver trusted_key_driver = {
> + .probe = trusted_key_probe,
> + .remove = trusted_key_remove,
> .id_table = trusted_key_id_table,
> .driver = {
> .name = DRIVER_NAME,
> - .probe = trusted_key_probe,
> - .remove = trusted_key_remove,
> },
> };
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v1 14/17] KEYS: trusted: Migrate to use tee specific driver registration function
From: Sumit Garg @ 2025-12-15 7:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, James Bottomley, Jarkko Sakkinen, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn, op-tee,
linux-integrity, keyrings, linux-security-module, linux-kernel
In-Reply-To: <0b3ce259fa26e59ef24a91ca070e2b08feeede82.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:15:08PM +0100, Uwe Kleine-König wrote:
> The tee subsystem recently got a set of dedicated functions to register
> (and unregister) a tee driver. Make use of them. These care for setting the
> driver's bus (so the explicit assignment can be dropped) and the driver
> owner (which is an improvement this driver benefits from).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> security/keys/trusted-keys/trusted_tee.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
>
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> index aa3d477de6db..3cea9a377955 100644
> --- a/security/keys/trusted-keys/trusted_tee.c
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -264,7 +264,6 @@ static struct tee_client_driver trusted_key_driver = {
> .id_table = trusted_key_id_table,
> .driver = {
> .name = DRIVER_NAME,
> - .bus = &tee_bus_type,
> .probe = trusted_key_probe,
> .remove = trusted_key_remove,
> },
> @@ -272,12 +271,12 @@ static struct tee_client_driver trusted_key_driver = {
>
> static int trusted_tee_init(void)
> {
> - return driver_register(&trusted_key_driver.driver);
> + return tee_client_driver_register(&trusted_key_driver);
> }
>
> static void trusted_tee_exit(void)
> {
> - driver_unregister(&trusted_key_driver.driver);
> + tee_client_driver_unregister(&trusted_key_driver);
> }
>
> struct trusted_key_ops trusted_key_tee_ops = {
> --
> 2.47.3
>
^ permalink raw reply
* A formal request for process clarifications.
From: Dr. Greg @ 2025-12-15 7:08 UTC (permalink / raw)
To: linux-security-module; +Cc: torvalds, corbet
Good morning, I hope the week has started well for everyone.
When Paul Moore took over as the security/LSM sub-system maintainer,
three years ago, he indicated a desire to be very prescriptive with
respect to the practices that should be followed for the sub-system,
particularly for the introduction of new LSM's.
The following URL documents the requirements for the introduction of a
new LSM:
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsms
We believe that LWN covered the discussion around this document as well.
The following discussion on whether or not the Linux kernel provides
proper support for modern Event Detection and Response Systems (EDR or
EDRS) suggests the need to clarify these recommendations:
https://lore.kernel.org/linux-security-module/CABZOZnS4im-wNK4jtGKvp3YT9hPobA503rgiptutOF8rZEwt_w@mail.gmail.com
In that thread Timur Chernykh noted a possible desire to port the
Apple security API to the kernel, which would presumably be a large
body of virgin code.
Three years ago our team had submitted for review our TSEM LSM that
provides a framework for generic security modeling, particularly to
support machine learning and direct functional modeling of security
behavior.
We haven't been able to receive any substantive review of TSEM over
that period of time.
Casey Schaufler has been vocal in his criticism of how we introduced
what is a virgin LSM implementation. Most particularly with the fact
that we chose to include, as a single patch, a header file that
contains the structure and enumeration definitions that are referenced
by all of the compilation units that make up TSEM.
He indicates that an LSM submission, should 'tell a story' by bringing
in the structure definitions with the code that uses those structures.
We can offer multiple examples of the challenges we see with doing
this if that would be helpful but will not do so at this time.
We had requested guidance from Paul on how a new submission should be
properly structured, since he is the ultimate judge and jury on a
submission, but he declined to provide guidance.
Given the current security climate, particularly with what is widely
cited as the potential impact of machine learning and AI on security
architectures and practices, there will undoubtedly be new LSM's
coming forward. It would seem in the best interests of everyone
involved, reviewers and submitters, that specific guidance should be
codified in the 'new-lsms' document of how a virgin body of code
should be introduced.
Optimally this should include links to previous submissions that the
security maintainers believe codify the desired method of story
telling.
Given the importance of security in today's environment we are
prepared to pursue this through the TAB if necessary.
We will look forward to comments from the community on this issue.
Have a good week.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 6:43 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <64e3e4e0a92848fd3b02a213c754f096d2026463.camel@HansenPartnership.com>
On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus
> > its
> > use should be pooled rather than directly used. This both reduces
> > latency and improves its predictability.
> >
> > 2. Linux is better off overall if every subsystem uses the same
> > source for
> > the random bistream as the de-facto choice, unless *force majeure*
> > reasons point to some other direction.
> >
> > In the case, of TPM there is no reason for trusted keys to invoke TPM
> > directly.
>
> That assertion isn't correct: you seem to have forgotten we had this
> argument six or seven years ago, but even that was a reprise of an even
> earlier one. Lore doesn't go back far enough for the intermediate one
> on the tpm list, but the original was cc'd to lkml:
>
> https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
>
> The decision then was to use the same random source as the key
> protection. Unfortunately most of the active participants have moved
> on from IBM and I don't have their current email addresses, but the
> bottom line is there were good reasons to do trusted keys this way that
> your assertions above don't overcome. I'm not saying we shouldn't
> reconsider the situation, but we need a reasoned debate rather than
> simply doing it by fiat.
The way I see this is that given that kernel is not running inside TPM,
FIPS certification of the RNG does not have any measurable value.
Random data generation should happen as part of object creation process
i.e. should be fully self-contained process within the TPM in order for
FIPS to matter.
In the case of sealed data objects, this not the case.
>
> Regards,
>
> James
>
BR, Jarkko
^ permalink raw reply
* Re: An opinion about Linux security
From: Dr. Greg @ 2025-12-15 4:55 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Timur Chernykh, torvalds, linux-security-module
In-Reply-To: <950ac630-c75e-4d4c-ac70-5e4b0e397989@schaufler-ca.com>
On Fri, Dec 12, 2025 at 03:43:07PM -0800, Casey Schaufler wrote:
Good morning Casey, pleasant as always to hear from you.
> On 12/11/2025 9:45 PM, Dr. Greg wrote:
> > On Wed, Dec 10, 2025 at 03:15:39AM +0300, Timur Chernykh wrote:
> >
> > Good morning Timur, I hope this note finds your week having gone well.
> >
> >> Hello Linus,
> >>
> >> I'm writing to ask for your opinion. What do you think about Linux's
> >> current readiness for security-focused commercial products? I'm
> >> particularly interested in several areas.
> > I don't expect you will receive an answer.
> >
> > Based on his previous comments and long standing position on this
> > issue, I believe it can be fairly stated that he looks at the LSM as
> > an unnecessary evil.
> >
> > So in his absence, some 'in loco parentis' reflections on the issues
> > you raise.
> >
> > I've been advised, more than once, that in this day and age, no one is
> > interested in reading more than a two sentence paragraph, so a short
> > response to your issues here and a bit more detail for anyone who
> > wants to read more, at the end.
> >
> > There is active art available to address the shortcomings you outline
> > in your post below. Our TSEM LSM was designed to service the
> > realitities of the modern security environment and where it is going.
> > In a manner that doesn't provide any restrictions on how 'security'
> > can be implemented.
> >
> > We've done four releases over three years and we believe an unbiased
> > observer would conclude they have received no substantive technical
> > review that would support interest in upstream integration.
> Stop. Really, I mean it. I put significant effort into trying to teach
> you how to submit a patch set that could be reviewed. You ignored it.
> I can't speak to what an "unbiased observer" would conclude because
> your behavior has certainly left me with bias. Rather than writing
> full length novels about why you submitted patches the way you've
> done it you might consider heeding the advice. Grrr.
No, we are not going to stop, see immediately below.
> > The challenge is that the security gatekeepers view LSM submissions
> > through a lens of whether or not the LSM implements security
> > consistent with what they believe is security.
>
> While there is some truth to that, we're really quite flexible.
> What we need to see is that there is some sort of security model,
> and that the proposed code implements it. We also need to be able
> to examine the proposed code to see that it implements the model.
> You have rejected all suggestions about how to make your proposal
> reviewable.
No we didn't.
I've managed engineers before, I've never found a successful strategy
to be:
"Go off and do what I told you to do".
Without some kind of explanation and dialogue.
The Linux community has a process problem with the LSM and the
security sub-system that needs to be addressed. Personally, I now
have the cycles to address it.
We assume that if Timur elects to port the Apple security API (Timur's
ESF implementation) into the kernel, he will face the same issue that
concerns us.
When Paul Moore came on-board three years ago as the security
maintainer, he was immediately VERY prescriptive with respect to
establishing policies and guidelines that he wanted followed for LSM
submissions.
We see that he sent those guidelines to Timur in case he was
interested in submitting ESF as a new LSM. Here is the link for those
who haven't seen it.
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsms
What those guidelines are missing are prescriptive practices for
bringing a major body of virgin code into the security review process.
As we did with TSEM, and presumably Timur will have to do with ESF, if
he moves forward with that initiative.
For the benefit of those following this conversation and to close the
record in this thread from our perspective, as tedious as that might
be.
From an architectural perspective, TSEM consists of a series of
compilation units, each dedicated to a specific functional role needed
to support the LSM. We used a single include file that holds all of
the enumerations and structure definitions that are referenced by
every compilation unit.
We chose a submssion model of introducing this include file as a
single patch in the series, after a complete sub-system documentation
patch. Introduction of virgin sub-systems isn't really common but this
strategy was consistent with what we had previously observed.
In addition, we believe that Knuth was quoted at one time about an
understanding of a program flows from an understanding of its data
structures.
You reviewed about half of one compilation unit and said you didn't
have time for anymore. For the record, we made the changes that you
requested and responded to your other concerns for that unit.
Your primary issue, which you have repeated often, as you did here,
was with the fact that we had a single header file in the patch series
with all of the LSM global definitions. You indicated that the patch
series should be broken up in order to 'tell a story' by including the
structure and enumeration definitions with the code.
Fair enough, you are a valued voice in the Linux security community,
but your right pinky finger is not on the RETURN key that sends
security sub-system pull requests to Linus, Paul Moore's is.
If anyone chooses to review the new LSM guidelines, they will note
that it never makes mention of the fact that a patch series should
'tell a story' and/or how that should be done.
So, before we committed a ton of development time into what could very
well end up being a tag team match to try and please two maintainers,
we reached out to Paul for advice on how he would like to see a virgin
patch series structured.
His response was that TSEM had significant issues, the least of which
was the organization of the patch series. We repeatedly asked him to
detail what those problems were, as by his own admission he had only
read the documentation and not offered any review comments on the code
itself.
The only thing we received was that, in certain security behavior
modeling configurations enabled by TSEM, the security response would
be asynchronous from the event or events that triggered it.
We attempted to pursue further dialogue surrounding this. The last
response, at least a year ago now, was that he didn't think he needed
to respond to us because of our 'tone'. If anyone hasn't noticed, our
'tone' is driven by the fact that we tend to not be easily bul*ted.
So, in the interest of furthering Linux security development while at
the same time promoting homeostatic harmony in the community, we will
be sending out a request to the security list to formally address this
issue with new LSM's.
It obviously doesn't make sense to waste your or other people's time
addressing the other issues you have below, other than to agree that
we disagree on where security is headed and how Linux needs to
respond.
> > Those views are
> > inconsistent with the realities of the modern security market,
>
> Oh, stop it. Look at how many LSMs have been added over the past
> few years. Sandboxing and application controlled security are
> "modern" security concepts that were unheard of when the LSM was
> introduced. As I said before, security is a dynamic technology.
> If it were not, we'd have a Bell & LaPadula kernel config option
> instead of an LSM infrastructure.
>
> > a
> > market that that is now predicated on detection rather than
> > enforcement. A trend that will only accelerate with advancements in
> > machine learning and AI.
>
> Without the underlying access controls detection is rather pointless.
>
> > It is worth noting that the history of the technology industry is
> > littered with examples of technology incumbents usually missing
> > disruptive innovation.
>
> The technology industry is not unique on this. Acme Buggy Whips, inc.
>
> > This restriction on suitability is actually inconsistent with Linus'
> > stated position on how Linux sub-systems can be used, as expressed in
> > his comment in the following post.
> >
> > https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/
> >
> > So the problem is not technical, it is a political eco-system problem.
> >
> > So, big picture, that is the challenge facing resolution of your
> > concerns.
> >
> > Apologies to everyone about the paragraph/sentence overflow and any
> > afront to sensibilities.
> >
> > More detail below if anyone is interested.
> >
> >> First, in today's 3rd-party (out-of-tree) EDR development EDR
> >> being the most common commercial class of security products eBPF
> >> has effectively become the main option. Yet eBPF is extremely
> >> restrictive. It is not possible to write fully expressive real-time
> >> analysis code: the verifier is overly strict, non-deterministic
> >> loops are not allowed, and older kernels lack BTF support. These
> >> issues create real limitations.
> >>
> >> Second, the removal of the out-of-tree LSM API in the 4.x kernel
> >> series caused significant problems for many AV/EDR vendors. I was
> >> unable to find an explanation in the mailing lists that convincingly
> >> justified that decision.
> >>
> >> The next closest mechanism, fanotify, was a genuine improvement.
> >> However, it does not allow an AV/EDR vendor to protect the integrity
> >> of its own product. Is Linux truly expecting modern AV/EDR solutions
> >> to rely on fanotify alone?
> >>
> >> My main question is: what are the future plans? Linux provides very
> >> few APIs for security and dynamic analysis. eBPF is still immature,
> >> fanotify is insufficient, and driver workarounds that bypass kernel
> >> restrictions are risky they introduce both stability and security
> >> problems. At the same time, properly implemented in-tree LSMs are not
> >> inherently dangerous and remain the safer, supported path for
> >> extending security functionality. Without safe, supported interfaces,
> >> however, commercial products struggle to be competitive. At the
> >> moment, macOS with its Endpoint Security Framework is significantly
> >> ahead.
> >>
> >> Yes, the kernel includes multiple in-tree LSM modules, but in
> >> practice SELinux does not simplify operations it often complicates
> >> them, despite its long-standing presence. Many of the other LSMs are
> >> rarely used in production. As an EDR developer, I seldom encounter
> >> them, and when I do, they usually provide little practical
> >> value. Across numerous real-world server intrusions, none of these
> >> LSM modules have meaningfully prevented attacks, despite many years
> >> of kernel development.
> >>
> >> Perhaps it is time for Linux to focus on more than a theoretical model
> >> of security.
> > The heart of the political eco-system challenge is best expressed by a
> > quote from Kyle Moffett, in which he stated that security should only
> > be developed and implemented by experts. Unfortunately that view is
> > inconsistent with the current state of the technology industry.
>
> Glad to hear I'm not an expert! - Not!
>
> > Classical security practititioners will defend complex subject/object
> > architectures with: "Google uses SeLinux for Android security".
>
> Yea gads. Subject/Object is about as simple as it gets. Look at Smack.
>
> > Our response to that is that the world doesn't have a security problem
> > because Google lacks sufficient resources to implement anything it
> > desires to implement, regardless of the development and maintenance
> > input costs.
> >
> > Unfortunately, that luxury is inconsistent with the rest of the
> > software development world that doesn't enjoy a 3.8 trillion dollar
> > market capitalization.
> >
> > The world simply lacks enough experts to make the 'security only by
> > experts' model work.
> >
> > Today, the fastest way to a product is to grab Linux and a development
> > team and write software for hardware that is now completely
> > commoditized. Everyone knows that security is not one of the
> > fundamental project predicates in this model.
> >
> > Both NIST and DHS/CISA are officially on record as indicating that
> > security needs to start with and be baked in through the development
> > process. One of the objectives of TSEM was to provide a framework for
> > enabling this concept for the implementation of analysis and mandatory
> > behavior controls for software workloads.
> >
> > A second fundamental problem is that the world has moved, in large
> > part, to containerized execution workloads. The Linux LSM, in its
> > current form, doesn't effectively support the application of workload
> > specific security policies.
> >
> > Further complicating this issue is the fact that LSM 'stacking'
> > requires reasoning as to what a final security policy will be when
> > multiple different security architectures/policies get to decide on
> > the outcome of a security event/hook. The concept of least surprise
> > would suggest the need for stacking to have idempotency, in other
> > words, the order in which LSM event consumers are called shouldn't
> > influence the effective policy, but this is generally acknowledged as
> > not being the case with 'stacking'.
>
> Any other approach, and they have been considered, fails miserably
> and introduces a host of complications. Not to mention performance
> de-optimization.
>
> > So we designed TSEM to provide an alternative, not a replacement, but
> > an alternative to how developers and system administrators can develop
> > and apply security policy, including integrity controls.
> >
> > TSEM is an LSM that implements containerized security infrastructure
> > rather than security policy. It is designed around the concept of a
> > security orchestrator that can execute security isolated workloads and
> > receive the LSM events and their parameters from that workload and
> > process them in any manner it wishes.
>
> I shan't repeat the objections that have been raised, but I will
> point out that you have done nothing to address them.
>
> > For example: A Docker/Kubernetes container can be run and all of the
> > security events by that workload exported up into an OpenSearch or
> > ElasticSearch instance for anomaly detection and analysis.
> >
> > So an EDR implemented on top of this has visibility into all of the
> > security events and their characteristics that are deemed security
> > relevant by the kernel developers.
> >
> > One of the pushbacks is that this can lead to asynchronous security
> > decisions, but as you note, that is the model that the commercial
> > security industry and the consumers of its products has embraced,
> > particularly in light of the advancements coming out of the AI
> > industry, detection rather than enforcement.
> >
> > If synchronous enforcement is required TSEM provides that as well,
> > including the use of standard kernel modules to implement analysis and
> > response to the LSM hooks. Internally we have implemented other LSM's
> > such as Tomoyo and IMA as loadable modules that can support multiple
> > and independent workload policies.
> >
> > If you or other EDR vendors are interested, we would be more than
> > happy to engage in conversations as to how to improve the capabilities
> > of this type of architecture, as an alternative to what is currently
> > available in Linux, which as you note, has significant limitations.
> >
> >> Everything above reflects only my personal opinion. I would greatly
> >> appreciate your response and any criticism you may have.
> > As I mentioned at the outset, you are unlikely to hear anything.
> >
> > For the necessary Linux infrastructure improvements to emerge we
> > believe there is the need to develop and engage a community effort
> > that independently pursues the advancements that are necessary,
> > particularly those that enable Linux to implement first class AI based
> > security controls.
> >
> > We believe that only this will result in sufficient 'market pull' at the
> > distribution level to help shape upstreaming decisions.
> >
> > Absent that, it is likely that Linux will continue to implement what
> > has failed to work in the past in the hope that it will somehow work
> > in the future.
>
> Wow. calling Linux a failure is a bit of a stretch, don't you think?
>
> > Comments and criticism welcome, we have had plenty of experience with
> > the latter.... :-)
>
> We've been over these issues many times. Go back and make some changes to
> your approach.
>
> >> Best regards,
> >> Timur Chernykh
> > Best wishes for the success of your work and a pleasant holiday season.
> >
> > As always,
> > Dr. Greg
> >
> > The Quixote Project - Flailing at the Travails of Cybersecurity
> > https://github.com/Quixote-Project
> >
Best wishes for a productive week and a pleasant holiday season.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
^ permalink raw reply
* Re: [PATCH v5 1/6] landlock: Implement LANDLOCK_ADD_RULE_NO_INHERIT
From: Tingmao Wang @ 2025-12-14 22:53 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, Günther Noack, Jan Kara,
Abhinav Saxena, linux-security-module
In-Reply-To: <20251214170548.408142-2-utilityemal77@gmail.com>
On 12/14/25 17:05, Justin Suess wrote:
> [...]
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index d4f47d20361a..6ab3e7bd1c81 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -127,10 +127,39 @@ struct landlock_ruleset_attr {
> * allowed_access in the passed in rule_attr. When this flag is
> * present, the caller is also allowed to pass in an empty
> * allowed_access.
> + * %LANDLOCK_ADD_RULE_NO_INHERIT
> + * When set on a rule being added to a ruleset, this flag disables the
> + * inheritance of access rights and flags from parent objects.
> + *
> + * This flag currently applies only to filesystem rules. Adding it to
> + * non-filesystem rules will return -EINVAL, unless future extensions
> + * of Landlock define other hierarchical object types.
> + *
> + * By default, Landlock filesystem rules inherit allowed accesses from
> + * ancestor directories: if a parent directory grants certain rights,
> + * those rights also apply to its children. A rule marked with
> + * LANDLOCK_ADD_RULE_NO_INHERIT stops this propagation at the directory
> + * covered by the rule. Descendants of that directory continue to inherit
> + * normally unless they also have rules using this flag.
> + *
> + * If a regular file is marked with this flag, it will not inherit any
> + * access rights from its parent directories; only the accesses explicitly
> + * allowed by the rule will apply to that file.
> + *
> + * This flag also enforces parent-directory restrictions: rename, rmdir,
> + * link, and other operations that would change the directory's immediate
> + * parent subtree are denied up to the VFS root. This prevents
> + * sandboxed processes from manipulating the filesystem hierarchy to evade
> + * restrictions (e.g., via sandbox-restart attacks).
> + *
> + * In addition, this flag blocks the inheritance of rule-layer flags
tbh I feel that it's less confusing to just say "rule flags" (instead of
"rule-layer flags").
> + * (such as the quiet flag) from parent directories to the object covered
> + * by this rule.
> */
>
> /* clang-format off */
> #define LANDLOCK_ADD_RULE_QUIET (1U << 0)
> +#define LANDLOCK_ADD_RULE_NO_INHERIT (1U << 1)
> /* clang-format on */
>
> /**
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index 0b589263ea42..8d8623ea857f 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -317,6 +317,37 @@ static struct landlock_object *get_inode_object(struct inode *const inode)
> LANDLOCK_ACCESS_FS_IOCTL_DEV)
> /* clang-format on */
>
> +enum landlock_walk_result {
> + LANDLOCK_WALK_CONTINUE,
> + LANDLOCK_WALK_STOP_REAL_ROOT,
> + LANDLOCK_WALK_MOUNT_ROOT,
> +};
> +
> +static enum landlock_walk_result landlock_walk_path_up(struct path *const path)
> +{
> + while (path->dentry == path->mnt->mnt_root) {
> + if (!follow_up(path))
> + return LANDLOCK_WALK_STOP_REAL_ROOT;
> + }
> +
> + if (unlikely(IS_ROOT(path->dentry))) {
> + if (likely(path->mnt->mnt_flags & MNT_INTERNAL))
> + return LANDLOCK_WALK_MOUNT_ROOT;
imo, LANDLOCK_WALK_MOUNT_ROOT is a somewhat confusing name for this,
especially in the context that if we see this in
is_access_to_paths_allowed() we allow access unconditionally.
Would LANDLOCK_WALK_INTERNAL be a better name here?
> + dput(path->dentry);
> + path->dentry = dget(path->mnt->mnt_root);
> + return LANDLOCK_WALK_CONTINUE;
> + }
> +
> + struct dentry *const parent = dget_parent(path->dentry);
> +
> + dput(path->dentry);
> + path->dentry = parent;
> + return LANDLOCK_WALK_CONTINUE;
> +}
> +
> +static const struct landlock_rule *find_rule(const struct landlock_ruleset *const domain,
> + const struct dentry *const dentry);
> +
> /*
> * @path: Should have been checked by get_path_from_fd().
> */
> @@ -344,6 +375,48 @@ int landlock_append_fs_rule(struct landlock_ruleset *const ruleset,
> return PTR_ERR(id.key.object);
> mutex_lock(&ruleset->lock);
> err = landlock_insert_rule(ruleset, id, access_rights, flags);
> + if (err || !(flags & LANDLOCK_ADD_RULE_NO_INHERIT))
> + goto out_unlock;
> +
> + /* Create ancestor rules and set has_no_inherit_descendant flags */
> + struct path walker = *path;
> +
> + path_get(&walker);
> + while (landlock_walk_path_up(&walker) != LANDLOCK_WALK_STOP_REAL_ROOT) {
Why not landlock_walk_path_up(&walker) == LANDLOCK_WALK_CONTINUE here?
I'm not sure if it's actually possible to end up with an infinite loop by
ignoring LANDLOCK_WALK_MOUNT_ROOT (i.e. not sure if "internal" mounts can
have disconnected dentries), but it seems safer to write to loop in a way
such that if that happens, we exit.
> + struct landlock_rule *ancestor_rule;
> +
> + if (WARN_ON_ONCE(!walker.dentry || d_is_negative(walker.dentry))) {
> + err = -EIO;
> + break;
> + }
> +
> + ancestor_rule = (struct landlock_rule *)find_rule(ruleset, walker.dentry);
> + if (!ancestor_rule) {
> + struct landlock_id ancestor_id = {
> + .type = LANDLOCK_KEY_INODE,
> + .key.object = get_inode_object(d_backing_inode(walker.dentry)),
> + };
> +
> + if (IS_ERR(ancestor_id.key.object)) {
> + err = PTR_ERR(ancestor_id.key.object);
> + break;
> + }
> + err = landlock_insert_rule(ruleset, ancestor_id, 0, 0);
> + landlock_put_object(ancestor_id.key.object);
> + if (err)
> + break;
> +
> + ancestor_rule = (struct landlock_rule *)
> + find_rule(ruleset, walker.dentry);
> + }
> + if (WARN_ON_ONCE(!ancestor_rule || ancestor_rule->num_layers != 1)) {
> + err = -EIO;
> + break;
> + }
> + ancestor_rule->layers[0].flags.has_no_inherit_descendant = true;
> + }
> + path_put(&walker);
> +out_unlock:
> mutex_unlock(&ruleset->lock);
> /*
> * No need to check for an error because landlock_insert_rule()
> @@ -772,8 +845,10 @@ static bool is_access_to_paths_allowed(
> _layer_masks_child2[LANDLOCK_NUM_ACCESS_FS];
> layer_mask_t(*layer_masks_child1)[LANDLOCK_NUM_ACCESS_FS] = NULL,
> (*layer_masks_child2)[LANDLOCK_NUM_ACCESS_FS] = NULL;
> - struct collected_rule_flags *rule_flags_parent1 = &log_request_parent1->rule_flags;
> - struct collected_rule_flags *rule_flags_parent2 = &log_request_parent2->rule_flags;
> + struct collected_rule_flags *rule_flags_parent1 =
> + &log_request_parent1->rule_flags;
> + struct collected_rule_flags *rule_flags_parent2 =
> + log_request_parent2 ? &log_request_parent2->rule_flags : NULL;
Good point, I think the original was still safe because it would not be
used by landlock_unmask_layers anyway, but this is better. I will take
this in the next version, thanks!
>
> if (!access_request_parent1 && !access_request_parent2)
> return true;
> @@ -784,7 +859,7 @@ static bool is_access_to_paths_allowed(
> if (is_nouser_or_private(path->dentry))
> return true;
>
> - if (WARN_ON_ONCE(!layer_masks_parent1))
> + if (WARN_ON_ONCE(!layer_masks_parent1 || !log_request_parent1))
> return false;
>
> allowed_parent1 = is_layer_masks_allowed(layer_masks_parent1);
> @@ -851,6 +926,7 @@ static bool is_access_to_paths_allowed(
> */
> while (true) {
> const struct landlock_rule *rule;
> + enum landlock_walk_result walk_res;
>
> /*
> * If at least all accesses allowed on the destination are
> @@ -910,46 +986,14 @@ static bool is_access_to_paths_allowed(
> if (allowed_parent1 && allowed_parent2)
> break;
>
> -jump_up:
> - if (walker_path.dentry == walker_path.mnt->mnt_root) {
> - if (follow_up(&walker_path)) {
> - /* Ignores hidden mount points. */
> - goto jump_up;
> - } else {
> - /*
> - * Stops at the real root. Denies access
> - * because not all layers have granted access.
> - */
> - break;
> - }
> - }
> -
> - if (unlikely(IS_ROOT(walker_path.dentry))) {
> - if (likely(walker_path.mnt->mnt_flags & MNT_INTERNAL)) {
> - /*
> - * Stops and allows access when reaching disconnected root
> - * directories that are part of internal filesystems (e.g. nsfs,
> - * which is reachable through /proc/<pid>/ns/<namespace>).
> - */
> - allowed_parent1 = true;
> - allowed_parent2 = true;
> - break;
> - }
> -
> - /*
> - * We reached a disconnected root directory from a bind mount.
> - * Let's continue the walk with the mount point we missed.
> - */
I think we might want to preserve these comments.
> - dput(walker_path.dentry);
> - walker_path.dentry = walker_path.mnt->mnt_root;
> - dget(walker_path.dentry);
> - } else {
> - struct dentry *const parent_dentry =
> - dget_parent(walker_path.dentry);
> -
> - dput(walker_path.dentry);
> - walker_path.dentry = parent_dentry;
> + walk_res = landlock_walk_path_up(&walker_path);
> + if (walk_res == LANDLOCK_WALK_MOUNT_ROOT) {
> + allowed_parent1 = true;
> + allowed_parent2 = true;
> + break;
> }
> + if (walk_res != LANDLOCK_WALK_CONTINUE)
> + break;
> }
> path_put(&walker_path);
>
> @@ -963,7 +1007,7 @@ static bool is_access_to_paths_allowed(
> ARRAY_SIZE(*layer_masks_parent1);
> }
>
> - if (!allowed_parent2) {
> + if (!allowed_parent2 && log_request_parent2) {
> log_request_parent2->type = LANDLOCK_REQUEST_FS_ACCESS;
> log_request_parent2->audit.type = LSM_AUDIT_DATA_PATH;
> log_request_parent2->audit.u.path = *path;
> @@ -1037,8 +1081,8 @@ static access_mask_t maybe_remove(const struct dentry *const dentry)
> * collect_domain_accesses - Walk through a file path and collect accesses
> *
> * @domain: Domain to check against.
> - * @mnt_root: Last directory to check.
> - * @dir: Directory to start the walk from.
> + * @mnt_root: Last path element to check.
> + * @dir: Directory path to start the walk from.
> * @layer_masks_dom: Where to store the collected accesses.
> *
> * This helper is useful to begin a path walk from the @dir directory to a
> @@ -1060,29 +1104,31 @@ static access_mask_t maybe_remove(const struct dentry *const dentry)
> */
> static bool collect_domain_accesses(
> const struct landlock_ruleset *const domain,
> - const struct dentry *const mnt_root, struct dentry *dir,
> + const struct path *const mnt_root, const struct path *const dir,
> layer_mask_t (*const layer_masks_dom)[LANDLOCK_NUM_ACCESS_FS],
> struct collected_rule_flags *const rule_flags)
> {
This function only walks up to the mountpoint of dir. If dir is changed
from a *dentry to a *path, wouldn't mnt_root be redundant? Since
mnt_root->dentry is always going to be dir->mnt->mnt_root. This also
means that they can't accidentally not be the same.
> unsigned long access_dom;
> bool ret = false;
> + struct path walker;
>
> if (WARN_ON_ONCE(!domain || !mnt_root || !dir || !layer_masks_dom))
> return true;
> - if (is_nouser_or_private(dir))
> + if (is_nouser_or_private(dir->dentry))
> return true;
>
> access_dom = landlock_init_layer_masks(domain, LANDLOCK_MASK_ACCESS_FS,
> layer_masks_dom,
> LANDLOCK_KEY_INODE);
>
> - dget(dir);
> + walker = *dir;
> + path_get(&walker);
> while (true) {
> - struct dentry *parent_dentry;
> + enum landlock_walk_result walk_res;
>
> /* Gets all layers allowing all domain accesses. */
> if (landlock_unmask_layers(
> - find_rule(domain, dir), access_dom, layer_masks_dom,
> + find_rule(domain, walker.dentry), access_dom, layer_masks_dom,
> ARRAY_SIZE(*layer_masks_dom), rule_flags)) {
> /*
> * Stops when all handled accesses are allowed by at
> @@ -1091,22 +1137,69 @@ static bool collect_domain_accesses(
> ret = true;
> break;
> }
> -
> - /*
> - * Stops at the mount point or the filesystem root for a disconnected
> - * directory.
> - */
> - if (dir == mnt_root || unlikely(IS_ROOT(dir)))
> + if (walker.dentry == mnt_root->dentry && walker.mnt == mnt_root->mnt)
> + break;
> + walk_res = landlock_walk_path_up(&walker);
> + if (walk_res != LANDLOCK_WALK_CONTINUE)
> break;
> -
> - parent_dentry = dget_parent(dir);
> - dput(dir);
> - dir = parent_dentry;
> }
> - dput(dir);
> + path_put(&walker);
> return ret;
> }
>
> +/**
> + * deny_no_inherit_topology_change - deny topology changes on sealed paths
> + * @subject: Subject performing the operation (contains the domain).
> + * @path: Path whose dentry is the target of the topology modification.
> + *
> + * Checks whether any domain layers are sealed against topology changes at
> + * @path. If so, emit an audit record and return -EACCES. Otherwise return 0.
> + */
> +static int deny_no_inherit_topology_change(const struct landlock_cred_security
> + *subject,
> + const struct path *const path)
Since you're not using path->mnt here (except for a NULL check), would it
be easier to just pass the dentry instead? In that case you wouldn't have
to do an inline initializer in current_check_refer_path / hook_path_*
below as well.
> +{
> + layer_mask_t sealed_layers = 0;
> + layer_mask_t override_layers = 0;
> + const struct landlock_rule *rule;
> + u32 layer_index;
> + unsigned long audit_layer_index;
> +
> + if (WARN_ON_ONCE(!subject || !path || !path->dentry || !path->mnt ||
> + d_is_negative(path->dentry)))
> + return 0;
> +
> + rule = find_rule(subject->domain, path->dentry);
> + if (!rule)
> + return 0;
> +
> + for (layer_index = 0; layer_index < rule->num_layers; layer_index++) {
> + const struct landlock_layer *layer = &rule->layers[layer_index];
> + layer_mask_t layer_bit = BIT_ULL(layer->level - 1);
> +
> + if (layer->flags.no_inherit ||
> + layer->flags.has_no_inherit_descendant)
> + sealed_layers |= layer_bit;
> + else
> + override_layers |= layer_bit;
> + }
> +
> + sealed_layers &= ~override_layers;
> + if (!sealed_layers)
> + return 0;
> +
> + audit_layer_index = __ffs((unsigned long)sealed_layers);
> + landlock_log_denial(subject, &(struct landlock_request) {
> + .type = LANDLOCK_REQUEST_FS_CHANGE_TOPOLOGY,
> + .audit = {
> + .type = LSM_AUDIT_DATA_DENTRY,
> + .u.dentry = path->dentry,
> + },
> + .layer_plus_one = audit_layer_index + 1,
> + });
> + return -EACCES;
> +}
> +
> /**
> * current_check_refer_path - Check if a rename or link action is allowed
> *
> @@ -1191,6 +1284,21 @@ static int current_check_refer_path(struct dentry *const old_dentry,
> access_request_parent2 =
> get_mode_access(d_backing_inode(old_dentry)->i_mode);
> if (removable) {
> + int err = deny_no_inherit_topology_change(subject,
> + &(struct path)
> + { .mnt = new_dir->mnt,
> + .dentry = old_dentry });
> +
> + if (err)
> + return err;
> + if (exchange) {
> + err = deny_no_inherit_topology_change(subject,
> + &(struct path)
> + { .mnt = new_dir->mnt,
> + .dentry = new_dentry });
> + if (err)
> + return err;
> + }
> access_request_parent1 |= maybe_remove(old_dentry);
> access_request_parent2 |= maybe_remove(new_dentry);
> }
> @@ -1232,12 +1340,15 @@ static int current_check_refer_path(struct dentry *const old_dentry,
> old_dentry->d_parent;
>
> /* new_dir->dentry is equal to new_dentry->d_parent */
> - allow_parent1 = collect_domain_accesses(subject->domain, mnt_dir.dentry,
> - old_parent,
> + allow_parent1 = collect_domain_accesses(subject->domain,
> + &mnt_dir,
> + &(struct path){ .mnt = new_dir->mnt,
> + .dentry = old_parent },
> &layer_masks_parent1,
> &request1.rule_flags);
> - allow_parent2 = collect_domain_accesses(subject->domain, mnt_dir.dentry,
> - new_dir->dentry,
> + allow_parent2 = collect_domain_accesses(subject->domain, &mnt_dir,
> + &(struct path){ .mnt = new_dir->mnt,
> + .dentry = new_dir->dentry },
> &layer_masks_parent2,
> &request2.rule_flags);
>
> @@ -1583,12 +1694,37 @@ static int hook_path_symlink(const struct path *const dir,
> static int hook_path_unlink(const struct path *const dir,
> struct dentry *const dentry)
> {
> + const struct landlock_cred_security *const subject =
> + landlock_get_applicable_subject(current_cred(), any_fs, NULL);
> + int err;
> +
> + if (subject) {
> + err = deny_no_inherit_topology_change(subject,
> + &(struct path)
> + { .mnt = dir->mnt,
> + .dentry = dentry });
> + if (err)
> + return err;
> + }
> return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_FILE);
> }
>
> static int hook_path_rmdir(const struct path *const dir,
> struct dentry *const dentry)
> {
> + const struct landlock_cred_security *const subject =
> + landlock_get_applicable_subject(current_cred(), any_fs, NULL);
> + int err;
> +
> + if (subject) {
> + err = deny_no_inherit_topology_change(subject,
> + &(struct path)
> + { .mnt = dir->mnt,
> + .dentry = dentry });
> + if (err)
> + return err;
> + }
> +
> return current_check_access_path(dir, LANDLOCK_ACCESS_FS_REMOVE_DIR);
> }
>
> [...]
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: James Bottomley @ 2025-12-14 22:18 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-integrity
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM,
open list
In-Reply-To: <20251214213236.339586-1-jarkko@kernel.org>
On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus
> its
> use should be pooled rather than directly used. This both reduces
> latency and improves its predictability.
>
> 2. Linux is better off overall if every subsystem uses the same
> source for
> the random bistream as the de-facto choice, unless *force majeure*
> reasons point to some other direction.
>
> In the case, of TPM there is no reason for trusted keys to invoke TPM
> directly.
That assertion isn't correct: you seem to have forgotten we had this
argument six or seven years ago, but even that was a reprise of an even
earlier one. Lore doesn't go back far enough for the intermediate one
on the tpm list, but the original was cc'd to lkml:
https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
The decision then was to use the same random source as the key
protection. Unfortunately most of the active participants have moved
on from IBM and I don't have their current email addresses, but the
bottom line is there were good reasons to do trusted keys this way that
your assertions above don't overcome. I'm not saying we shouldn't
reconsider the situation, but we need a reasoned debate rather than
simply doing it by fiat.
Regards,
James
^ 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