* Re: [PATCH v4 03/17] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG
From: Nicolas Schier @ 2026-02-06 8:25 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-3-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:47PM +0100, Thomas Weißschuh wrote:
> When configuration settings are disabled the guarded functions are
> defined as empty stubs, so the check is unnecessary.
> The specific configuration option for set_module_sig_enforced() is
> about to change and removing the checks avoids some later churn.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> security/integrity/ima/ima_efi.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 04/17] module: Make mod_verify_sig() static
From: Nicolas Schier @ 2026-02-06 8:25 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-4-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:48PM +0100, Thomas Weißschuh wrote:
> It is not used outside of signing.c.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> kernel/module/internal.h | 1 -
> kernel/module/signing.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Nicolas Schier @ 2026-02-06 8:30 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-5-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:49PM +0100, Thomas Weißschuh wrote:
> Switching the types will make some later changes cleaner.
> size_t is also the semantically correct type for this field.
>
> As both 'size_t' and 'unsigned int' are always the same size, this
> should be risk-free.
include/uapi/asm-generic/posix_types.h states:
| * Most 32 bit architectures use "unsigned int" size_t,
| * and all 64 bit architectures use "unsigned long" size_t.
Is that statement wrong? Or did I mix up the context?
Kind regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Thomas Weißschuh @ 2026-02-06 8:34 UTC (permalink / raw)
To: David Howells
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Nicolas Schier,
Daniel Gomez, Aaron Tomlin, Christophe Leroy (CS GROUP),
Nicolas Schier, Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <2919071.1770365933@warthog.procyon.org.uk>
On 2026-02-06 08:18:53+0000, David Howells wrote:
> Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> > As both 'size_t' and 'unsigned int' are always the same size, this
> > should be risk-free.
>
> Did you mean 'unsigned long'?
Indeed, I'll fix it for the next revision.
Thomas
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Thomas Weißschuh @ 2026-02-06 8:38 UTC (permalink / raw)
To: Nicolas Schier, Nathan Chancellor, Arnd Bergmann,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Paul Moore, James Morris, Serge E. Hallyn, Jonathan Corbet,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Naveen N Rao, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Daniel Gomez, Aaron Tomlin,
Christophe Leroy (CS GROUP), Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <aYWmkEzjvo9RrzI9@levanger>
On 2026-02-06 09:30:08+0100, Nicolas Schier wrote:
> On Tue, Jan 13, 2026 at 01:28:49PM +0100, Thomas Weißschuh wrote:
> > Switching the types will make some later changes cleaner.
> > size_t is also the semantically correct type for this field.
> >
> > As both 'size_t' and 'unsigned int' are always the same size, this
> > should be risk-free.
>
> include/uapi/asm-generic/posix_types.h states:
> | * Most 32 bit architectures use "unsigned int" size_t,
> | * and all 64 bit architectures use "unsigned long" size_t.
>
> Is that statement wrong? Or did I mix up the context?
That statement is correct. But as both 'unsigned int' and 'unsigned
long' are 32-bit wide on 32-bit Linux platforms they are compatible.
Thomas
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Nicolas Schier @ 2026-02-06 8:55 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <8fd4914d-5cff-4030-822c-98c8e76d0e60@t-8ch.de>
On Fri, Feb 06, 2026 at 09:38:07AM +0100, Thomas Weißschuh wrote:
> On 2026-02-06 09:30:08+0100, Nicolas Schier wrote:
> > On Tue, Jan 13, 2026 at 01:28:49PM +0100, Thomas Weißschuh wrote:
> > > Switching the types will make some later changes cleaner.
> > > size_t is also the semantically correct type for this field.
> > >
> > > As both 'size_t' and 'unsigned int' are always the same size, this
> > > should be risk-free.
> >
> > include/uapi/asm-generic/posix_types.h states:
> > | * Most 32 bit architectures use "unsigned int" size_t,
> > | * and all 64 bit architectures use "unsigned long" size_t.
> >
> > Is that statement wrong? Or did I mix up the context?
>
> That statement is correct. But as both 'unsigned int' and 'unsigned
> long' are 32-bit wide on 32-bit Linux platforms they are compatible.
>
>
> Thomas
sure, thanks!
Acked-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Christophe Leroy (CS GROUP) @ 2026-02-06 9:09 UTC (permalink / raw)
To: Thomas Weißschuh, Nathan Chancellor, Arnd Bergmann,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Paul Moore, James Morris, Serge E. Hallyn, Jonathan Corbet,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Naveen N Rao, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Nicolas Schier, Daniel Gomez, Aaron Tomlin,
Nicolas Schier, Nicolas Bouchinet, Xiu Jianfeng
Cc: Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-5-0b932db9b56b@weissschuh.net>
Le 13/01/2026 à 13:28, Thomas Weißschuh a écrit :
> Switching the types will make some later changes cleaner.
> size_t is also the semantically correct type for this field.
>
> As both 'size_t' and 'unsigned int' are always the same size, this
> should be risk-free.
Are you sure ?
Some architectures have size_t as 'unsigned int', some have 'unsigned
long', some have 'unsigned long long'
https://elixir.bootlin.com/linux/v6.19-rc5/source/arch/s390/include/uapi/asm/posix_types.h#L16
https://elixir.bootlin.com/linux/v6.19-rc5/source/arch/sparc/include/uapi/asm/posix_types.h#L35
https://elixir.bootlin.com/linux/v6.19-rc5/source/arch/xtensa/include/uapi/asm/posix_types.h#L26
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/uapi/asm-generic/posix_types.h#L68
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/uapi/asm-generic/posix_types.h#L72
https://elixir.bootlin.com/linux/v6.19-rc5/source/arch/sparc/include/uapi/asm/posix_types.h#L23
https://elixir.bootlin.com/linux/v6.19-rc5/source/arch/x86/include/uapi/asm/posix_types_x32.h#L15
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/uapi/asm-generic/posix_types.h#L16
Christophe
^ permalink raw reply
* Re: [PATCH v4 05/17] module: Switch load_info::len to size_t
From: Thomas Weißschuh @ 2026-02-06 9:18 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Nicolas Schier,
Daniel Gomez, Aaron Tomlin, Nicolas Schier, Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <ffdafd21-fe7a-44a2-86ec-0e0c2ad4238c@kernel.org>
On 2026-02-06 10:09:12+0100, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 13/01/2026 à 13:28, Thomas Weißschuh a écrit :
> > Switching the types will make some later changes cleaner.
> > size_t is also the semantically correct type for this field.
> >
> > As both 'size_t' and 'unsigned int' are always the same size, this
> > should be risk-free.
> Are you sure ?
As mentioned before by David [0], this should have been 'unsigned long'
instead of 'unsigned int'. Which is also what the diff shows.
> Some architectures have size_t as 'unsigned int', some have 'unsigned long',
> some have 'unsigned long long'
(...)
[0] https://lore.kernel.org/lkml/2919071.1770365933@warthog.procyon.org.uk/
^ permalink raw reply
* IMA vs TPM (SPI) boot order problems
From: Jonathan McDowell @ 2026-02-06 10:37 UTC (permalink / raw)
To: linux-integrity, Romain Naour; +Cc: Mimi Zohar
I'm seeing an issue with a SPI attached TPM, where it's not coming up
early enough for IMA to decide there's a TPM available that it can
measure into. The TPM is definitely present, and by the time we get to
userspace it's working fine.
This is sort of resurrecting a post from 2024 by Romain, though that
concerned an i2c TPM:
https://lore.kernel.org/all/9b98d912-ba78-402c-a5c8-154bef8794f7@smile.fr/
There doesn't seem to have actually been a fixed applied, so I tried the
late_initcall_sync suggestion, but that didn't change things:
[ 0.000000] ACPI: TPM2 0x0000004044BCA998 00004C (v04 ALASKA A M I 00000001 AMI 00000000)
[ 0.000000] GICv3: 960 SPIs implemented
[ 0.000000] GICv3: 320 Extended SPIs implemented
[ 0.000447] LSM: initializing lsm=capability,bpf,ima
[ 0.394832] Trying to unpack rootfs image as initramfs...
[ 0.681134] tegra-qspi NVDA1513:00: Adding to iommu group 1
[ 0.681241] tegra-qspi NVDA1513:00: device reset failed
[ 0.686925] tpm_tis_spi spi-PRP0001:01: 2.0 TPM (device-id 0x1B, rev-id 22)
[ 0.894451] ima: No TPM chip found, activating TPM-bypass!
[ 0.894462] ima: Allocated hash algorithm: sha256
[ 0.894471] ima: No architecture policies found
This seems to show SPI + the TPM coming up before IMA, but still not in
a way that makes IMA happy.
Romain, did you solve your issue in some other manner?
J.
--
If I want to hear the pitter patter of little feet, I'll put shoes on
my cats.
^ permalink raw reply
* Re: IMA vs TPM (SPI) boot order problems
From: Mimi Zohar @ 2026-02-06 15:36 UTC (permalink / raw)
To: Jonathan McDowell, linux-integrity, Romain Naour
In-Reply-To: <aYXEepLhUouN5f99@earth.li>
On Fri, 2026-02-06 at 10:37 +0000, Jonathan McDowell wrote:
> I'm seeing an issue with a SPI attached TPM, where it's not coming up
> early enough for IMA to decide there's a TPM available that it can
> measure into. The TPM is definitely present, and by the time we get to
> userspace it's working fine.
>
> This is sort of resurrecting a post from 2024 by Romain, though that
> concerned an i2c TPM:
>
> https://lore.kernel.org/all/9b98d912-ba78-402c-a5c8-154bef8794f7@smile.fr/
>
> There doesn't seem to have actually been a fixed applied, so I tried the
> late_initcall_sync suggestion, but that didn't change things:
>
> [ 0.000000] ACPI: TPM2 0x0000004044BCA998 00004C (v04 ALASKA A M I 00000001 AMI 00000000)
> [ 0.000000] GICv3: 960 SPIs implemented
> [ 0.000000] GICv3: 320 Extended SPIs implemented
> [ 0.000447] LSM: initializing lsm=capability,bpf,ima
> [ 0.394832] Trying to unpack rootfs image as initramfs...
> [ 0.681134] tegra-qspi NVDA1513:00: Adding to iommu group 1
> [ 0.681241] tegra-qspi NVDA1513:00: device reset failed
> [ 0.686925] tpm_tis_spi spi-PRP0001:01: 2.0 TPM (device-id 0x1B, rev-id 22)
> [ 0.894451] ima: No TPM chip found, activating TPM-bypass!
> [ 0.894462] ima: Allocated hash algorithm: sha256
> [ 0.894471] ima: No architecture policies found
>
> This seems to show SPI + the TPM coming up before IMA, but still not in
> a way that makes IMA happy.
Here's an example with really well written patch descriptions, that was
upstreamed:
746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to
rootfs_initcall")
Mimi
^ permalink raw reply
* Re: [PATCH v4 06/17] kbuild: add stamp file for vmlinux BTF data
From: Nicolas Schier @ 2026-02-06 16:28 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-6-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:50PM +0100, Thomas Weißschuh wrote:
> The upcoming module hashes functionality will build the modules in
> between the generation of the BTF data and the final link of vmlinux.
> Having a dependency from the modules on vmlinux would make this
> impossible as it would mean having a cyclic dependency.
> Break this cyclic dependency by introducing a new target.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> scripts/Makefile.modfinal | 4 ++--
> scripts/link-vmlinux.sh | 6 ++++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 07/17] kbuild: generate module BTF based on vmlinux.unstripped
From: Nicolas Schier @ 2026-02-06 16:37 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-7-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:51PM +0100, Thomas Weißschuh wrote:
> The upcoming module hashes functionality will build the modules in
> between the generation of the BTF data and the final link of vmlinux.
> At this point vmlinux is not yet built and therefore can't be used for
> module BTF generation. vmlinux.unstripped however is usable and
> sufficient for BTF generation.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> scripts/Makefile.modfinal | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> index adfef1e002a9..930db0524a0a 100644
> --- a/scripts/Makefile.modfinal
> +++ b/scripts/Makefile.modfinal
> @@ -40,11 +40,11 @@ quiet_cmd_ld_ko_o = LD [M] $@
>
> quiet_cmd_btf_ko = BTF [M] $@
> cmd_btf_ko = \
> - if [ ! -f $(objtree)/vmlinux ]; then \
> - printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
> + if [ ! -f $(objtree)/vmlinux.unstripped ]; then \
> + printf "Skipping BTF generation for %s due to unavailability of vmlinux.unstripped\n" $@ 1>&2; \
> else \
> - LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) $(MODULE_PAHOLE_FLAGS) --btf_base $(objtree)/vmlinux $@; \
> - $(RESOLVE_BTFIDS) -b $(objtree)/vmlinux $@; \
> + LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) $(MODULE_PAHOLE_FLAGS) --btf_base $(objtree)/vmlinux.unstripped $@; \
> + $(RESOLVE_BTFIDS) -b $(objtree)/vmlinux.unstripped $@; \
Reviewed-by: Nicolas Schier <nsc@kernel.org> # kbuild
I'd like to have some BTF ack for that.
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-06 17:12 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Petr Pavlu, Nathan Chancellor, Arnd Bergmann, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <28cf8d51-7530-41d5-a47b-cad5ecabd269@t-8ch.de>
On Tue, Feb 03, 2026 at 01:55:05PM +0100, Thomas Weißschuh wrote:
> On 2026-01-30 18:06:20+0100, Petr Pavlu wrote:
> > On 1/13/26 1:28 PM, Thomas Weißschuh wrote:
> > > Normally the .ko module files depend on a fully built vmlinux to be
> > > available for modpost validation and BTF generation. With
> > > CONFIG_MODULE_HASHES, vmlinux now depends on the modules
> > > to build a merkle tree. This introduces a dependency cycle which is
> > > impossible to satisfy. Work around this by building the modules during
> > > link-vmlinux.sh, after vmlinux is complete enough for modpost and BTF
> > > but before the final module hashes are
> >
> > I wonder if this dependency cycle could be resolved by utilizing the
> > split into vmlinux.unstripped and vmlinux that occurred last year.
> >
> > The idea is to create the following ordering: vmlinux.unstripped ->
> > modules -> vmlinux, and to patch in .module_hashes only when building
> > the final vmlinux.
> >
> > This would require the following:
> > * Split scripts/Makefile.vmlinux into two Makefiles, one that builds the
> > current vmlinux.unstripped and the second one that builds the final
> > vmlinux from it.
> > * Modify the top Makefile to recognize vmlinux.unstripped and update the
> > BTF generation rule 'modules: vmlinux' to
> > 'modules: vmlinux.unstripped'.
> > * Add the 'vmlinux: modules' ordering in the top Makefile for
> > CONFIG_MODULE_HASHES=y.
> > * Remove the patching of vmlinux.unstripped in scripts/link-vmlinux.sh
> > and instead move it into scripts/Makefile.vmlinux when running objcopy
> > to produce the final vmlinux.
> >
> > I think this approach has two main advantages:
> > * CONFIG_MODULE_HASHES can be made orthogonal to
> > CONFIG_DEBUG_INFO_BTF_MODULES.
> > * All dependencies are expressed at the Makefile level instead of having
> > scripts/link-vmlinux.sh invoke 'make -f Makefile modules'.
> >
> > Below is a rough prototype that applies on top of this series. It is a
> > bit verbose due to the splitting of part of scripts/Makefile.vmlinux
> > into scripts/Makefile.vmlinux_unstripped.
>
> That looks like a feasible alternative. Before adopting it, I'd like to
> hear the preference of the kbuild folks.
After the first run-through, the proposed alternative sounds good.
Unfortunately, I ran out of time for this week. I can give a more
founded reply in a few days.
Kind regards,
Nicolas
> > diff --git a/Makefile b/Makefile
> > index 841772a5a260..19a3beb82fa7 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1259,7 +1259,7 @@ vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
> > vmlinux.o modules.builtin.modinfo modules.builtin: vmlinux_o
> > @:
> >
> > -PHONY += vmlinux
> > +PHONY += vmlinux.unstripped vmlinux
> > # LDFLAGS_vmlinux in the top Makefile defines linker flags for the top vmlinux,
> > # not for decompressors. LDFLAGS_vmlinux in arch/*/boot/compressed/Makefile is
> > # unrelated; the decompressors just happen to have the same base name,
> > @@ -1270,9 +1270,11 @@ PHONY += vmlinux
> > # https://savannah.gnu.org/bugs/?61463
> > # For Make > 4.4, the following simple code will work:
> > # vmlinux: private export LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > -vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > -vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
> > -vmlinux: vmlinux.o $(KBUILD_LDS) modpost
> > +vmlinux.unstripped: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > +vmlinux.unstripped: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
> > +vmlinux.unstripped: vmlinux.o $(KBUILD_LDS) modpost
> > + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_unstripped
> > +vmlinux: vmlinux.unstripped
> > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
>
> Maybe we could keep them together in a single Makefile,
> and instead have different targets in it.
>
> (...)
>
> > @@ -98,70 +44,15 @@ remove-symbols := -w --strip-unneeded-symbol='__mod_device_table__*'
> > # To avoid warnings: "empty loadable segment detected at ..." from GNU objcopy,
> > # it is necessary to remove the PT_LOAD flag from the segment.
> > quiet_cmd_strip_relocs = OBJCOPY $@
> > - cmd_strip_relocs = $(OBJCOPY) $(patsubst %,--set-section-flags %=noload,$(remove-section-y)) $< $@; \
> > - $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $(remove-symbols) $@
> > + cmd_script_relocs = $(OBJCOPY) $(patsubst %,--set-section-flags %=noload,$(remove-section-y)) $< $@; \
> > + $(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) \
> > + $(remove-symbols) \
> > + $(patch-module-hashes) $@
>
> cmd_script_relocs -> cmd_strip_relocs
>
> (...)
--
Nicolas
^ permalink raw reply
* Re: IMA vs TPM (SPI) boot order problems
From: Jonathan McDowell @ 2026-02-06 19:45 UTC (permalink / raw)
To: Mimi Zohar; +Cc: linux-integrity, Romain Naour
In-Reply-To: <f8b3451a6ef619dd2934bc839618fabc9408967c.camel@linux.ibm.com>
On Fri, Feb 06, 2026 at 10:36:36AM -0500, Mimi Zohar wrote:
>On Fri, 2026-02-06 at 10:37 +0000, Jonathan McDowell wrote:
>> I'm seeing an issue with a SPI attached TPM, where it's not coming up
>> early enough for IMA to decide there's a TPM available that it can
>> measure into. The TPM is definitely present, and by the time we get to
>> userspace it's working fine.
>>
>> This is sort of resurrecting a post from 2024 by Romain, though that
>> concerned an i2c TPM:
>>
>> https://lore.kernel.org/all/9b98d912-ba78-402c-a5c8-154bef8794f7@smile.fr/
>>
>> There doesn't seem to have actually been a fixed applied, so I tried the
>> late_initcall_sync suggestion, but that didn't change things:
>>
>> [ 0.000000] ACPI: TPM2 0x0000004044BCA998 00004C (v04 ALASKA A M I 00000001 AMI 00000000)
>> [ 0.000000] GICv3: 960 SPIs implemented
>> [ 0.000000] GICv3: 320 Extended SPIs implemented
>> [ 0.000447] LSM: initializing lsm=capability,bpf,ima
>> [ 0.394832] Trying to unpack rootfs image as initramfs...
>> [ 0.681134] tegra-qspi NVDA1513:00: Adding to iommu group 1
>> [ 0.681241] tegra-qspi NVDA1513:00: device reset failed
>> [ 0.686925] tpm_tis_spi spi-PRP0001:01: 2.0 TPM (device-id 0x1B, rev-id 22)
>> [ 0.894451] ima: No TPM chip found, activating TPM-bypass!
>> [ 0.894462] ima: Allocated hash algorithm: sha256
>> [ 0.894471] ima: No architecture policies found
>>
>> This seems to show SPI + the TPM coming up before IMA, but still not in
>> a way that makes IMA happy.
>
>Here's an example with really well written patch descriptions, that was
>upstreamed:
>
>746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
>0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to
>rootfs_initcall")
Thanks Mimi, really useful pointers. I think the TPM/SPI chain is a
little bit more tricky (I guess I can just fix the path that works for
me, rather than *any* SPI bus driver), but I'll investigate.
J.
--
Shall I call the United Nations?
This .sig brought to you by the letter W and the number 30
Product of the Republic of HuggieTag
^ permalink raw reply
* Re: [PATCH v5 3/3] ima: Use kstat.ctime as a fallback change detection for stacked fs
From: Frederick Lawler @ 2026-02-06 20:06 UTC (permalink / raw)
To: Mimi Zohar
Cc: Roberto Sassu, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton, linux-kernel,
linux-integrity, linux-security-module, kernel-team
In-Reply-To: <6f82d5dc6b499ecd03c985d6de20de94fea04cfe.camel@linux.ibm.com>
On Wed, Feb 04, 2026 at 11:26:27PM -0500, Mimi Zohar wrote:
> On Wed, 2026-02-04 at 15:22 -0600, Frederick Lawler wrote:
> > That said, I think Mimi pointed out in an email [2] where multi-grain
> > file systems are impacted regardless of stacked fs or not due to the last
> > writer check.
> >
> > I don't recall coming across that in my tests, but perhaps I did that
> > specific test wrong? To be sure, I created the C program, and on the VM,
> > created a XFS disk, mounted it on loopback, ran the rdwr program on
> > "somefile" multiple times, and only got 1 audit log for it, until I
> > mutated it with touch, and only got 2 hits: original + after mutation
> > after running the program multiple times.
> >
> > I'm not sure what's going on there, so I'll look into that a bit more,
> > but so far the impact is stacked file systems & multigrain ctime AFAIK.
>
> Make sure you're testing without your patch set applied or at least the last
> patch.
>
I'm still not sure what went wrong with my test suite, but spinning up a
VM similar to Mimi's, I was able to reproduce the last writer issue. I
used patch 1 as a baseline because that's noop from base 6.19, and used
that function as a convenient trace point.
And, then running the attached example test for stacked FS works as
expected on both patches 1 (multiple log messages) & 3 (just one log
message).
I left out the dump_stack() in integrity_inode_attrs_stat_change()
for readability in these results. For Mimi's test, we just see
calls into ima_check_last_writer(), and for the attached sample
in 0/0, we get the calls straight from process_measurement() for
stacked fs. Running Mimi's and then attached in that order, I get
double the logs because the FILE_CHECK is hitting the last writer,
and we get the process_measurement() for the binary run.
Based on all of this, I can drop the stacked FS wording in the patch
descriptions, and keep it all focused that the change_cookie semantics
have been changed for multigrain file systems.
Results:
PATCH 1/3
[root@localhost ~]# ./mimi.sh
filename: /usr/bin/date-20260206140427
filename: /usr/bin/date-20260206140427
filename: /usr/bin/date-20260206140427
FAIL: Expected 1 audit event, but found 3.
[ 26.033572] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.034372] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[ 26.037453] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.038425] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[ 26.039821] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.041383] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[root@localhost fred-tests]# ./simple-fedora.sh
314572800 bytes (315 MB, 300 MiB) copied, 0.132908 s, 2.4 GB/s
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
FAIL: Expected 1 audit event, but found 4.
Note: Does not have dmesg output because this patch didn't put the trace
function into integrity_inode_attrs_changed().
PATCH 3/3
[root@localhost ~]# ./mimi.sh
filename: /usr/bin/date-20260206140141
filename: /usr/bin/date-20260206140141
filename: /usr/bin/date-20260206140141
PASS: Found exactly 1 audit event.
[ 17.191235] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.192213] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[ 17.196325] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.197380] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[ 17.199750] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.200682] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[root@localhost fred-tests]# ./simple-fedora.sh
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
PASS: Found exactly 1 audit event.
[ 23.315358] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.328978] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
[ 23.332122] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.347162] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
[ 23.352931] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.368026] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
Note that the in stacked FS case, process_measurement() skipped the check
for attrs changed, and skipped to measuring. Subsequent calls into
process_measurement() hits the integrity_inode_attrs_stat_changed().
^ permalink raw reply
* Re: [PATCH v15 02/28] tpm: Move TPM1 specific definitions and functions to new headers
From: Jarkko Sakkinen @ 2026-02-08 13:39 UTC (permalink / raw)
To: ross.philipson
Cc: Daniel P. Smith, linux-kernel, x86, linux-integrity, linux-doc,
linux-crypto, kexec, linux-efi, iommu, tglx, mingo, bp, hpa,
dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, jgg, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, andrew.cooper3, trenchboot-devel
In-Reply-To: <6e1e771c-ecd4-4ab6-ba9f-900f34c5d89d@oracle.com>
On Wed, Feb 04, 2026 at 09:44:34AM -0800, ross.philipson@oracle.com wrote:
> On 2/1/26 8:23 AM, Daniel P. Smith wrote:
> > On 1/19/26 18:57, Jarkko Sakkinen wrote:
> > > On Mon, Dec 15, 2025 at 03:32:50PM -0800, Ross Philipson wrote:
> > > > This gathers all the TPM1 definitions and structures into two separate
> > > > header files (public tpm1.h and private tpm1_structs.h). The definitions
> > > > moved to these files correspond to the TCG specification for TPM 1 family:
> > > >
> > > > TPM 1.2 Main Specification
> > > > - https://urldefense.com/v3/__https://trustedcomputinggroup.org/resource/tpm-main-specification/__;!!ACWV5N9M2RV99hQ!OivTxO-R0nvBJYXIV-T0n0fq0wY64MTgdaecPzAauxrFkRxTcQ6CuBEcXmZZYY1KfZlqmfLTZBbPaEr7Y8k7hJk9_mQ$
> > > > Note that the structures were pulled into tpm1_structs.h to allow their
> > > > external reuse.
> > > >
> > > > Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> > > > Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
> > > > ---
> > > > drivers/char/tpm/tpm.h | 98 +--------------------------------
> > > > drivers/char/tpm/tpm1-cmd.c | 5 --
> > > > drivers/char/tpm/tpm1_structs.h | 97 ++++++++++++++++++++++++++++++++
> > >
> > > I think you are overcomplicating the patch set and doing more
> > > than you really need to do.
> > >
> > > I.e. structs could go also just as well to tpm_command.h. We
> > > will deal with if/when that file ever grows too large. It's
> > > absolutely not a priority for this patch set.
> >
> > Ack.
> >
> > > > include/linux/tpm1.h | 34 +++++++++++-
> > > > 4 files changed, 132 insertions(+), 102 deletions(-)
> > > > create mode 100644 drivers/char/tpm/tpm1_structs.h
> > > >
> > > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > > index ca391b2a211c..1f9f8540eede 100644
> > > > --- a/drivers/char/tpm/tpm.h
> > > > +++ b/drivers/char/tpm/tpm.h
> > > > @@ -50,105 +50,9 @@ enum tpm_addr {
> > > > TPM_ADDR = 0x4E,
> > > > };
> > > > -#define TPM_WARN_RETRY 0x800
> > > > -#define TPM_WARN_DOING_SELFTEST 0x802
> > > > -#define TPM_ERR_DEACTIVATED 0x6
> > > > -#define TPM_ERR_DISABLED 0x7
> > > > -#define TPM_ERR_FAILEDSELFTEST 0x1C
> > > > -#define TPM_ERR_INVALID_POSTINIT 38
> > > > -
> > > > -#define TPM_TAG_RQU_COMMAND 193
> > > > -
> > > > /* TPM2 specific constants. */
> > > > #define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
> > > > -struct stclear_flags_t {
> > > > - __be16 tag;
> > > > - u8 deactivated;
> > > > - u8 disableForceClear;
> > > > - u8 physicalPresence;
> > > > - u8 physicalPresenceLock;
> > > > - u8 bGlobalLock;
> > > > -} __packed;
> > > > -
> > > > -struct tpm1_version {
> > > > - u8 major;
> > > > - u8 minor;
> > > > - u8 rev_major;
> > > > - u8 rev_minor;
> > > > -} __packed;
> > > > -
> > > > -struct tpm1_version2 {
> > > > - __be16 tag;
> > > > - struct tpm1_version version;
> > > > -} __packed;
> > > > -
> > > > -struct timeout_t {
> > > > - __be32 a;
> > > > - __be32 b;
> > > > - __be32 c;
> > > > - __be32 d;
> > > > -} __packed;
> > > > -
> > > > -struct duration_t {
> > > > - __be32 tpm_short;
> > > > - __be32 tpm_medium;
> > > > - __be32 tpm_long;
> > > > -} __packed;
> > > > -
> > > > -struct permanent_flags_t {
> > > > - __be16 tag;
> > > > - u8 disable;
> > > > - u8 ownership;
> > > > - u8 deactivated;
> > > > - u8 readPubek;
> > > > - u8 disableOwnerClear;
> > > > - u8 allowMaintenance;
> > > > - u8 physicalPresenceLifetimeLock;
> > > > - u8 physicalPresenceHWEnable;
> > > > - u8 physicalPresenceCMDEnable;
> > > > - u8 CEKPUsed;
> > > > - u8 TPMpost;
> > > > - u8 TPMpostLock;
> > > > - u8 FIPS;
> > > > - u8 operator;
> > > > - u8 enableRevokeEK;
> > > > - u8 nvLocked;
> > > > - u8 readSRKPub;
> > > > - u8 tpmEstablished;
> > > > - u8 maintenanceDone;
> > > > - u8 disableFullDALogicInfo;
> > > > -} __packed;
> > > > -
> > > > -typedef union {
> > > > - struct permanent_flags_t perm_flags;
> > > > - struct stclear_flags_t stclear_flags;
> > > > - __u8 owned;
> > > > - __be32 num_pcrs;
> > > > - struct tpm1_version version1;
> > > > - struct tpm1_version2 version2;
> > > > - __be32 manufacturer_id;
> > > > - struct timeout_t timeout;
> > > > - struct duration_t duration;
> > > > -} cap_t;
> > > > -
> > > > -enum tpm_capabilities {
> > > > - TPM_CAP_FLAG = 4,
> > > > - TPM_CAP_PROP = 5,
> > > > - TPM_CAP_VERSION_1_1 = 0x06,
> > > > - TPM_CAP_VERSION_1_2 = 0x1A,
> > > > -};
> > > > -
> > > > -enum tpm_sub_capabilities {
> > > > - TPM_CAP_PROP_PCR = 0x101,
> > > > - TPM_CAP_PROP_MANUFACTURER = 0x103,
> > > > - TPM_CAP_FLAG_PERM = 0x108,
> > > > - TPM_CAP_FLAG_VOL = 0x109,
> > > > - TPM_CAP_PROP_OWNER = 0x111,
> > > > - TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> > > > - TPM_CAP_PROP_TIS_DURATION = 0x120,
> > > > -};
> > > > -
> > > > enum tpm2_pt_props {
> > > > TPM2_PT_NONE = 0x00000000,
> > > > TPM2_PT_GROUP = 0x00000100,
> > > > @@ -229,6 +133,8 @@ enum tpm2_pt_props {
> > > > * compiler warnings about stack frame size. */
> > > > #define TPM_MAX_RNG_DATA 128
> > > > +#include "tpm1_structs.h"
> > > > +
> > > > extern const struct class tpm_class;
> > > > extern const struct class tpmrm_class;
> > > > extern dev_t tpm_devt;
> > > > diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> > > > index f29827b454d2..02f20a0aa37d 100644
> > > > --- a/drivers/char/tpm/tpm1-cmd.c
> > > > +++ b/drivers/char/tpm/tpm1-cmd.c
> > > > @@ -505,11 +505,6 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> > > > }
> > > > EXPORT_SYMBOL_GPL(tpm1_getcap);
> > > > -struct tpm1_get_random_out {
> > > > - __be32 rng_data_len;
> > > > - u8 rng_data[TPM_MAX_RNG_DATA];
> > > > -} __packed;
> > > > -
> > > > /**
> > > > * tpm1_get_random() - get random bytes from the TPM's RNG
> > > > * @chip: a &struct tpm_chip instance
> > > > diff --git a/drivers/char/tpm/tpm1_structs.h b/drivers/char/tpm/tpm1_structs.h
> > > > new file mode 100644
> > > > index 000000000000..ad21376af5ab
> > > > --- /dev/null
> > > > +++ b/drivers/char/tpm/tpm1_structs.h
> > > > @@ -0,0 +1,97 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +/*
> > > > + * Copyright (C) 2004 IBM Corporation
> > > > + * Copyright (C) 2015 Intel Corporation
> > > > + *
> > > > + * Authors:
> > > > + * Leendert van Doorn <leendert@watson.ibm.com>
> > > > + * Dave Safford <safford@watson.ibm.com>
> > > > + * Reiner Sailer <sailer@watson.ibm.com>
> > > > + * Kylene Hall <kjhall@us.ibm.com>
> > > > + *
> > > > + * Maintained by: <tpmdd-devel@lists.sourceforge.net>
> > > > + *
> > > > + * Device driver for TCG/TCPA TPM (trusted platform module).
> > > > + * Specifications at https://urldefense.com/v3/__http://www.trustedcomputinggroup.org__;!!ACWV5N9M2RV99hQ!OivTxO-R0nvBJYXIV-T0n0fq0wY64MTgdaecPzAauxrFkRxTcQ6CuBEcXmZZYY1KfZlqmfLTZBbPaEr7Y8k7HW5iz_w$ + */
> > > > +
> > > > +#ifndef __TPM1_STRUCTS_H__
> > > > +#define __TPM1_STRUCTS_H__
> > > > +
> > > > +struct stclear_flags_t {
> > > > + __be16 tag;
> > > > + u8 deactivated;
> > > > + u8 disableForceClear;
> > > > + u8 physicalPresence;
> > > > + u8 physicalPresenceLock;
> > > > + u8 bGlobalLock;
> > > > +} __packed;
> > >
> > >
> > > Don't retain alignment.
> > >
> >
> > Okay.
>
> I wanted to clarify what you are asking here. Do you mean to just not pack the structs? It seems some of these structs define the responses from the TPM chip and I would assume they are packed this way.
>
> >
> > > > +
> > > > +struct tpm1_version {
> > > > + u8 major;
> > > > + u8 minor;
> > > > + u8 rev_major;
> > > > + u8 rev_minor;
> > > > +} __packed;
> > > > +
> > > > +struct tpm1_version2 {
> > > > + __be16 tag;
> > > > + struct tpm1_version version;
> > > > +} __packed;
> > > > +
> > > > +struct timeout_t {
> > > > + __be32 a;
> > > > + __be32 b;
> > > > + __be32 c;
> > > > + __be32 d;
> > > > +} __packed;
> > > > +
> > > > +struct duration_t {
> > > > + __be32 tpm_short;
> > > > + __be32 tpm_medium;
> > > > + __be32 tpm_long;
> > > > +} __packed;
> > > > +
> > > > +struct permanent_flags_t {
> > > > + __be16 tag;
> > > > + u8 disable;
> > > > + u8 ownership;
> > > > + u8 deactivated;
> > > > + u8 readPubek;
> > > > + u8 disableOwnerClear;
> > > > + u8 allowMaintenance;
> > > > + u8 physicalPresenceLifetimeLock;
> > > > + u8 physicalPresenceHWEnable;
> > > > + u8 physicalPresenceCMDEnable;
> > > > + u8 CEKPUsed;
> > > > + u8 TPMpost;
> > > > + u8 TPMpostLock;
> > > > + u8 FIPS;
> > > > + u8 operator;
> > > > + u8 enableRevokeEK;
> > > > + u8 nvLocked;
> > > > + u8 readSRKPub;
> > > > + u8 tpmEstablished;
> > > > + u8 maintenanceDone;
> > > > + u8 disableFullDALogicInfo;
> > > > +} __packed;
> > > > +
> > > > +/* Gather all capabilities related information info one type */
> > > > +typedef union {
> > > > + struct permanent_flags_t perm_flags;
> > > > + struct stclear_flags_t stclear_flags;
> > > > + __u8 owned;
> > > > + __be32 num_pcrs;
> > > > + struct tpm1_version version1;
> > > > + struct tpm1_version2 version2;
> > > > + __be32 manufacturer_id;
> > > > + struct timeout_t timeout;
> > > > + struct duration_t duration;
> > > > +} cap_t;
> > >
> > > Don't retain alignment here.
>
> Again to clarify, do you mean none of these structs should be packed (and thus the union won't be either)?
I only meant the syntactical (is that even a word) alignment :-)
I don't know what purpose does it serve here, as struct members already
convolute, and alignment then sort of add up to the convolution.
E.g., "__be32 manufacturer_id" with just one spacebar is what I mean.
>
> Thanks
> Ross
>
> > >
> >
> > Okay.
> >
> > > > +
> > > > +struct tpm1_get_random_out {
> > > > + __be32 rng_data_len;
> > > > + u8 rng_data[TPM_MAX_RNG_DATA];
> > > > +} __packed;
> > > > +
> > > > +#endif
> > > > diff --git a/include/linux/tpm1.h b/include/linux/tpm1.h
> > > > index 54c6c211eb9e..5fad94ac8d15 100644
> > > > --- a/include/linux/tpm1.h
> > > > +++ b/include/linux/tpm1.h
> > > > @@ -47,7 +47,39 @@ enum tpm_command_ordinals {
> > > > TPM_ORD_UNSEAL = 24,
> > > > };
> > > > -/* Other constants */
> > > > +enum tpm_capabilities {
> > > > + TPM_CAP_FLAG = 4,
> > > > + TPM_CAP_PROP = 5,
> > > > + TPM_CAP_VERSION_1_1 = 0x06,
> > > > + TPM_CAP_VERSION_1_2 = 0x1A,
> > > > +};
> > > > +
> > > > +enum tpm_sub_capabilities {
> > > > + TPM_CAP_PROP_PCR = 0x101,
> > > > + TPM_CAP_PROP_MANUFACTURER = 0x103,
> > > > + TPM_CAP_FLAG_PERM = 0x108,
> > > > + TPM_CAP_FLAG_VOL = 0x109,
> > > > + TPM_CAP_PROP_OWNER = 0x111,
> > > > + TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> > > > + TPM_CAP_PROP_TIS_DURATION = 0x120,
> > > > +};
> > > > +
> > > > +/* Return Codes */
> > > > +enum tpm_return_codes {
> > > > + TPM_BASE_MASK = 0,
> > > > + TPM_NON_FATAL_MASK = 0x00000800,
> > > > + TPM_SUCCESS = TPM_BASE_MASK + 0,
> > > > + TPM_ERR_DEACTIVATED = TPM_BASE_MASK + 6,
> > > > + TPM_ERR_DISABLED = TPM_BASE_MASK + 7,
> > > > + TPM_ERR_FAIL = TPM_BASE_MASK + 9,
> > > > + TPM_ERR_FAILEDSELFTEST = TPM_BASE_MASK + 28,
> > > > + TPM_ERR_INVALID_POSTINIT = TPM_BASE_MASK + 38,
> > > > + TPM_ERR_INVALID_FAMILY = TPM_BASE_MASK + 55,
> > > > + TPM_WARN_RETRY = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 0,
> > > > + TPM_WARN_DOING_SELFTEST = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 2,
> > > > +};
> > > > +
> > > > +/* Misc. constants */
> > >
> > > These constants should be relocated in a separate patch.
> > >
> >
> > Okay.
> >
> > > > #define SRKHANDLE 0x40000000
> > > > #define TPM_NONCE_SIZE 20
> > > > #define TPM_ST_CLEAR 1
> > > > --
> > > > 2.43.7
> > > >
> > >
> > > BR, Jarkko
> >
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v9 11/11] tpm-buf: Implement managed allocations
From: Jarkko Sakkinen @ 2026-02-08 14:09 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Ross Philipson, Stefan Berger, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <20260125192526.782202-12-jarkko@kernel.org>
On Sun, Jan 25, 2026 at 09:25:21PM +0200, Jarkko Sakkinen wrote:
> From: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
>
> Decouple kzalloc from buffer creation, so that a managed allocation can be
> used:
>
> struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE,
> GFP_KERNEL);
> if (!buf)
> return -ENOMEM;
>
> tpm_buf_init(buf, TPM_BUFSIZE);
>
> Alternatively, stack allocations are also possible:
>
> u8 buf_data[512];
> struct tpm_buf *buf = (struct tpm_buf *)buf_data;
> tpm_buf_init(buf, sizeof(buf_data));
>
> This is achieved by embedding buffer's header inside the allocated blob,
> instead of having an outer wrapper.
>
> Cc: Ross Philipson <ross.philipson@oracle.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Since rest of the series does not seem to move forward maybe I should
rebase this to bottom and send it as a separate patch?
This patch eliminates a category of memory bugs and is that way useful.
It also starts to be pretty well stress tested.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT
From: Ard Biesheuvel @ 2026-02-09 14:04 UTC (permalink / raw)
To: Ross Philipson, linux-kernel, x86, linux-integrity, linux-doc,
linux-crypto, kexec, linux-efi, iommu
Cc: dpsmith, Thomas Gleixner, mingo, bp, H . Peter Anvin, dave.hansen,
mjg59, James.Bottomley, peterhuewe, jarkko, jgg, luto, nivedita,
herbert, davem, corbet, ebiederm, dwmw2, baolu.lu, kanth.ghatraju,
andrew.cooper3, trenchboot-devel
In-Reply-To: <20251215233316.1076248-1-ross.philipson@oracle.com>
On Tue, 16 Dec 2025, at 00:32, Ross Philipson wrote:
> Secure Launch is a vendor-neutral approach to implementing TGC Dynamic
> Root of Trust (DRTM) support in the kernel. This is complementary to
> better known Static Root of Trust (SRTM) schemes such as UEFI SecureBoot.
>
> This series provides the common infrastructure along with Intel TXT
> support, without needing the tboot exokernel. Support for AMD SKINIT is
> pending the common infrastructure getting nailed down, and ARM are
> looking to build on it too.
>
> Originally, tboot were approached to see if they'd take support for
> other vendors, but they elected not to. Hence this approach instead.
>
> Work is being coordinated by the Trenchboot project,
> https://trenchboot.org/,
> organising Secure Launch support for upstream open source projects
> including
> Grub, iPXE and Xen. The goal of the Trenchboot project is to make DTRM
> easy
> to use. e.g. for Grub, it's simply adding "slaunch" as a command in
> the boot
> stanza. See
> https://trenchboot.org/user-docs/QUICKSTART/#linux-quick-start-guide
> for more details
>
> Patch set based on commit:
> torvalds/master/fd57572253bc356330dbe5b233c2e1d8426c66fd
>
> Depends on v3 of the following TPM patch set (note this patch
> set is being actively worked on separately):
> [PATCH v3 00/10] tpm: Decouple Trenchboot dependencies
> Message ID: 20250929194832.2913286-1-jarkko@kernel.org
>
> Finally we would like to thank everyone for their input and
> assistance. It has all been very helpful in improving the quality of
> our solution and in reviewing/strengthening our security posture.
>
Hi Daniel and Ross,
I have finally gotten around to getting the right hardware and building GRUB and Linux with your patches, and I have managed to get them running on an old Skylake HP laptop successfully.
Surprisingly, even when doing a secure launch, the EFI runtime services still work happily, which means (AIUI) that code that was excluded from the D-RTM TCB is still being executed at ring 0? Doesn't this defeat D-RTM entirely in the case some exploit is hidden in the EFI runtime code? Should we measure the contents of EfiRuntimeServicesCode regions too?
In any case, I am aware that upstreaming this work has been a painful experience so far. Unfortunately, I don't think we're quite there yet.
The way the work is divided between GRUB and Linux seems to be predicated entirely (at least originally) on the idea that the GRUB->Linux handover and the secure launch should be one and the same. I.e., GRUB sets the stage, pokes the ACM, which returns to the loaded linux image and boots it. This requires a lot of coordination, e.g., putting a MLE header in the kernel image and exposing it to GRUB in a certain manner, resource tables and other things that have to remain in sync between both sides.
There also appears to be an assumption that the fact that the ACM returns to the loaded image in 32-bit mode requires a round trip through the decompressor, which may relocate itself in memory and do other things that the slaunch code then has to work around again.
Due to the changes to the EFI boot path, this design has been watered down a bit already, in the sense that GRUB invokes the EFI entry point as usual, and only later, the pivot via the ACM is made.
Other than the SHA-1 debate [*], the main issue I have with this approach is that it adds things to the boot ABI that are closely tied to TXT on the one hand, and bzImage oddities on the other (kernel_info, setup block etc). IOW, the complete lack of abstractions is going to make this a maintenance burden going forward.
I've had a stab at implementing all of this in a manner that is more idiomatic for EFI boot:
- GRUB does minimal TXT related preparation upfront, and exposes the remaining functionality via a protocol that is attached to the loaded image by GRUB
- The SL stub is moved to the core kernel, with some startup code added to pivot to long mode
- the EFI stub executes and decompresses the kernel as usual
- if the protocol is present, the EFI stub calls it to pass the bootparams pointer, the base and size of the MLE and the header offset back to the GRUB code
- after calling ExitBootServices(), it calls another protocol method to trigger the secure launch.
The only pre-launch ABI that is being added here is a GRUB-specific protocol that is not necessarily tied to TXT. (For legacy boot, it should be feasible to call back into GRUB too, although it would be more of a ad-hoc construction, via the SLR table perhaps.) But no kernel_info and MLE headers etc being added to the ABI surface. Also, there is no longer a need for the GRUB code to understand how the decompressor is constructed, with a setup block etc, or take special care to perform PMR checks when its moves itself around in memory.
Code can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/grub.git/log/?h=sl-v2
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=x86-slaunch
I am aware that this is not the feedback you are waiting for at this point, given that we're at v15 already. But there are some warts in the current design that really need to be addressed before we can proceed with this IMHO.
--
Ard.
[*] which I still don't get: why is it fine to cap other banks with a single 0x1 byte [as the ACM does too, apparently], but do we require an SHA-1 implementation for capping the SHA-1 banks? Also, the TXT spec dropped all support for TPM1.2 so I wonder if that should be dropped from this series as well.
^ permalink raw reply
* Re: [PATCH v2 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Mimi Zohar @ 2026-02-09 20:43 UTC (permalink / raw)
To: Coiby Xu, linux-integrity
Cc: Heiko Carstens, Alexander Egorenkov, Ard Biesheuvel, Dave Hansen,
Roberto Sassu, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, Jarkko Sakkinen, open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <20260203041434.872784-2-coxu@redhat.com>
On Tue, 2026-02-03 at 12:14 +0800, Coiby Xu wrote:
> EVM and other LSMs need the ability to query the secure boot status of
> the system, without directly calling the IMA arch_ima_get_secureboot
> function. Refactor the secure boot status check into a general function
> named arch_get_secureboot.
>
> Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Suggested-by: Roberto Sassu <roberto.sassu@huawei.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
Thanks, Coiby. Other than unnecessarily splitting a line, the patch set looks
good. As soon as the open window closes, I'll queue these patches for linux-
next.
> diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
> index 138029bfcce1..27521d665d33 100644
> --- a/security/integrity/ima/ima_efi.c
> +++ b/security/integrity/ima/ima_efi.c
> @@ -2,52 +2,9 @@
> /*
> * Copyright (C) 2018 IBM Corporation
> */
> -#include <linux/efi.h>
> #include <linux/module.h>
> #include <linux/ima.h>
> -#include <asm/efi.h>
> -
> -#ifndef arch_ima_efi_boot_mode
> -#define arch_ima_efi_boot_mode efi_secureboot_mode_unset
> -#endif
> -
> -static enum efi_secureboot_mode get_sb_mode(void)
> -{
> - enum efi_secureboot_mode mode;
> -
> - if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) {
> - pr_info("ima: secureboot mode unknown, no efi\n");
> - return efi_secureboot_mode_unknown;
> - }
> -
> - mode = efi_get_secureboot_mode(efi.get_variable);
> - if (mode == efi_secureboot_mode_disabled)
> - pr_info("ima: secureboot mode disabled\n");
> - else if (mode == efi_secureboot_mode_unknown)
> - pr_info("ima: secureboot mode unknown\n");
> - else
> - pr_info("ima: secureboot mode enabled\n");
> - return mode;
> -}
> -
> -bool arch_ima_get_secureboot(void)
> -{
> - static enum efi_secureboot_mode sb_mode;
> - static bool initialized;
> -
> - if (!initialized && efi_enabled(EFI_BOOT)) {
> - sb_mode = arch_ima_efi_boot_mode;
> -
> - if (sb_mode == efi_secureboot_mode_unset)
> - sb_mode = get_sb_mode();
> - initialized = true;
> - }
> -
> - if (sb_mode == efi_secureboot_mode_enabled)
> - return true;
> - else
> - return false;
> -}
> +#include <linux/secure_boot.h>
>
> /* secureboot arch rules */
> static const char * const sb_arch_rules[] = {
> @@ -67,7 +24,8 @@ static const char * const sb_arch_rules[] = {
>
> const char * const *arch_get_ima_policy(void)
> {
> - if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> + if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) &&
> + arch_get_secureboot()) {
No need to split the line here or below.
> if (IS_ENABLED(CONFIG_MODULE_SIG))
> set_module_sig_enforced();
> if (IS_ENABLED(CONFIG_KEXEC_SIG))
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 5770cf691912..6d093ac82a45 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -949,8 +949,8 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
>
> switch (id) {
> case LOADING_KEXEC_IMAGE:
> - if (IS_ENABLED(CONFIG_KEXEC_SIG)
> - && arch_ima_get_secureboot()) {
> + if (IS_ENABLED(CONFIG_KEXEC_SIG) &&
> + arch_get_secureboot()) {
===>
Mimi
> pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
> return -EACCES;
> }
^ permalink raw reply
* [PATCH v6 0/3] ima: Detect changes to files via kstat changes rather than i_version
From: Frederick Lawler @ 2026-02-09 21:21 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton
Cc: linux-kernel, linux-integrity, linux-security-module, kernel-team,
Frederick Lawler
We uncovered a case in kernels >= 6.13 where XFS is no longer updating
struct kstat.change_cookie on i_op getattr() access calls. Instead, XFS is
using multigrain ctime (as well as other file systems) for
change detection in commit 1cf7e834a6fb ("xfs: switch to
multigrain timestamps").
Because file systems may implement i_version as they see fit, IMA
unnecessarily measures files.
We're proposing to compare against the kstat.change_cookie
directly to the cached version, and fall back to a ctime comparison,
if STATX_CHANGE_COOKIE is not supplied by vfs_getattr_nosec()'s result
mask.
EVM is largely left alone since there's no trivial way to query a file
directly in the LSM call paths to obtain kstat.change_cookie &
kstat.ctime to cache. Thus retains accessing i_version directly.
Regression tests will be added to the Linux Test Project instead of
selftest to help catch future file system changes that may impact
future evaluation of IMA.
I'd like this to be backported to at least 6.18 if possible.
Patches 1 & 2 are preparation patches. Ideally patch 2 is squashed into
3, though not strictly necessary.
Below is a simplified test that demonstrates the issue such that
there are multiple unnecessary measurements occurring for actions on
a file in a stacked TMPFS on XFS, prior to the file moved over to TMPFS:
_fragment.config_
CONFIG_XFS_FS=y
CONFIG_OVERLAY_FS=y
CONFIG_IMA=y
CONFIG_IMA_WRITE_POLICY=y
CONFIG_IMA_READ_POLICY=y
_./test.sh_
IMA_POLICY="/sys/kernel/security/ima/policy"
TEST_BIN="/bin/date"
MNT_BASE="/tmp/ima_test_root"
mkdir -p "$MNT_BASE"
mount -t tmpfs tmpfs "$MNT_BASE"
mkdir -p "$MNT_BASE"/{xfs_disk,upper,work,ovl}
dd if=/dev/zero of="$MNT_BASE/xfs.img" bs=1M count=300
mkfs.xfs -q "$MNT_BASE/xfs.img"
mount "$MNT_BASE/xfs.img" "$MNT_BASE/xfs_disk"
cp "$TEST_BIN" "$MNT_BASE/xfs_disk/test_prog"
mount -t overlay overlay -o \
"lowerdir=$MNT_BASE/xfs_disk,upperdir=$MNT_BASE/upper,workdir=$MNT_BASE/work" \
"$MNT_BASE/ovl"
echo "audit func=BPRM_CHECK uid=$(id -u nobody)" > "$IMA_POLICY"
target_prog="$MNT_BASE/ovl/test_prog"
setpriv --reuid nobody "$target_prog"
setpriv --reuid nobody "$target_prog"
setpriv --reuid nobody "$target_prog"
audit_count=$(dmesg | grep -c "file=\"$target_prog\"")
if [[ "$audit_count" -eq 1 ]]; then
echo "PASS: Found exactly 1 audit event."
else
echo "FAIL: Expected 1 audit event, but found $audit_count."
exit 1
fi
Signed-off-by: Frederick Lawler <fred@cloudflare.com>
---
Changes in v6:
- Patch 1: No changes
- All other patches including cover letter have descriptions updated.
- Link to v5: https://lore.kernel.org/r/20260130-xfs-ima-fixup-v5-0-57e84ea91712@cloudflare.com
Changes in v5:
- Split into patch series. [Mimi]
- Link to v4: https://lore.kernel.org/r/20260129-xfs-ima-fixup-v4-1-6bb89df7b6a3@cloudflare.com
Changes in v4:
- No functional changes.
- Add Reviewed-by & Fixes tags.
- Link to v3: https://lore.kernel.org/r/20260122-xfs-ima-fixup-v3-1-20335a8aa836@cloudflare.com
Changes in v3:
- Prefer timespec64_to_ns() to leverage attr.version. [Roberto]
- s/TPMFS/TMPFS/ in description.
- Link to v2: https://lore.kernel.org/r/20260120-xfs-ima-fixup-v2-1-f332ead8b043@cloudflare.com
Changes in v2:
- Updated commit description + message to clarify the problem.
- compare struct timespec64 to avoid collision possibility [Roberto].
- Don't check inode_attr_changed() in ima_check_last_writer()
- Link to v1: https://lore.kernel.org/r/20260112-xfs-ima-fixup-v1-1-8d13b6001312@cloudflare.com
Changes since RFC:
- Remove calls to I_IS_VERSION()
- Function documentation/comments
- Abide IMA/EVM change detection fallback invariants
- Combined ctime guard into version for attributes struct
- Link to RFC: https://lore.kernel.org/r/20251229-xfs-ima-fixup-v1-1-6a717c939f7c@cloudflare.com
---
Frederick Lawler (3):
ima: Unify vfs_getattr_nosec() stat comparisons under helper function
ima: Make integrity_inode_attrs_changed() call into VFS
ima: Use kstat.ctime as a fallback for change detection
include/linux/integrity.h | 43 +++++++++++++++++++++++++++++++++++----
security/integrity/evm/evm_main.c | 5 ++---
security/integrity/ima/ima_api.c | 11 +++++++---
security/integrity/ima/ima_main.c | 11 +++++-----
4 files changed, 54 insertions(+), 16 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251212-xfs-ima-fixup-931780a62c2c
Best regards,
--
Frederick Lawler <fred@cloudflare.com>
^ permalink raw reply
* [PATCH v6 1/3] ima: Unify vfs_getattr_nosec() stat comparisons under helper function
From: Frederick Lawler @ 2026-02-09 21:21 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton
Cc: linux-kernel, linux-integrity, linux-security-module, kernel-team,
Frederick Lawler
In-Reply-To: <20260209-xfs-ima-fixup-v6-0-72f576f90e67@cloudflare.com>
The logic for comparing kstat.change_cookie against IMA version is
hard to read. Abstract comparison logic into a new function
integrity_inode_attrs_stat_changed().
No functional change intended.
Signed-off-by: Frederick Lawler <fred@cloudflare.com>
---
include/linux/integrity.h | 11 +++++++++++
security/integrity/ima/ima_main.c | 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/integrity.h b/include/linux/integrity.h
index f5842372359be5341b6870a43b92e695e8fc78af..beb9ab19fa6257e79266b58bcb5f55b0c5445828 100644
--- a/include/linux/integrity.h
+++ b/include/linux/integrity.h
@@ -49,6 +49,17 @@ integrity_inode_attrs_store(struct integrity_inode_attributes *attrs,
attrs->ino = inode->i_ino;
}
+/* Compares stat attributes for change detection. */
+static inline bool
+integrity_inode_attrs_stat_changed
+(const struct integrity_inode_attributes *attrs, const struct kstat *stat)
+{
+ if (stat->result_mask & STATX_CHANGE_COOKIE)
+ return stat->change_cookie != attrs->version;
+
+ return true;
+}
+
/*
* On stacked filesystems detect whether the inode or its content has changed.
*/
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 5770cf691912aa912fc65280c59f5baac35dd725..6570ad10887b9ea1172c78274cf62482350e87ff 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -201,8 +201,8 @@ static void ima_check_last_writer(struct ima_iint_cache *iint,
vfs_getattr_nosec(&file->f_path, &stat,
STATX_CHANGE_COOKIE,
AT_STATX_SYNC_AS_STAT) ||
- !(stat.result_mask & STATX_CHANGE_COOKIE) ||
- stat.change_cookie != iint->real_inode.version) {
+ integrity_inode_attrs_stat_changed(&iint->real_inode,
+ &stat)) {
iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
iint->measured_pcrs = 0;
if (update)
--
2.43.0
^ permalink raw reply related
* [PATCH v6 2/3] ima: Make integrity_inode_attrs_changed() call into VFS
From: Frederick Lawler @ 2026-02-09 21:21 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton
Cc: linux-kernel, linux-integrity, linux-security-module, kernel-team,
Frederick Lawler
In-Reply-To: <20260209-xfs-ima-fixup-v6-0-72f576f90e67@cloudflare.com>
ima_check_last_writer() is already comparing kstat.change_cookie
against the cached attribute's version set by
ima_collect_masurement(). Make integrity_inode_attrs_changed()
call into the VFS as well. For file systems that do not set the
change cookie, IMA still treats the file as changed.
Fall back to current behavior if VFS cannot obtain it.
No logical change intended.
Signed-off-by: Frederick Lawler <fred@cloudflare.com>
---
include/linux/integrity.h | 28 ++++++++++++++++++++++++----
security/integrity/evm/evm_main.c | 5 ++---
security/integrity/ima/ima_main.c | 5 ++---
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/include/linux/integrity.h b/include/linux/integrity.h
index beb9ab19fa6257e79266b58bcb5f55b0c5445828..382c783f0fa3ae4a938cdf9559291ba1903a378e 100644
--- a/include/linux/integrity.h
+++ b/include/linux/integrity.h
@@ -9,6 +9,7 @@
#include <linux/fs.h>
#include <linux/iversion.h>
+#include <linux/kernel.h>
enum integrity_status {
INTEGRITY_PASS = 0,
@@ -62,14 +63,33 @@ integrity_inode_attrs_stat_changed
/*
* On stacked filesystems detect whether the inode or its content has changed.
+ *
+ * Must be called in process context.
*/
static inline bool
integrity_inode_attrs_changed(const struct integrity_inode_attributes *attrs,
- const struct inode *inode)
+ struct file *file, struct inode *inode)
{
- return (inode->i_sb->s_dev != attrs->dev ||
- inode->i_ino != attrs->ino ||
- !inode_eq_iversion(inode, attrs->version));
+ struct kstat stat;
+
+ might_sleep();
+
+ if (inode->i_sb->s_dev != attrs->dev || inode->i_ino != attrs->ino)
+ return true;
+
+ /*
+ * EVM currently relies on backing inode i_version. While IS_I_VERSION
+ * is not a good indicator of i_version support, this still retains
+ * the logic such that a re-evaluation should still occur for EVM, and
+ * only for IMA if vfs_getattr_nosec() fails.
+ */
+ if (!file || vfs_getattr_nosec(&file->f_path, &stat,
+ STATX_CHANGE_COOKIE,
+ AT_STATX_SYNC_AS_STAT))
+ return !IS_I_VERSION(inode) ||
+ !inode_eq_iversion(inode, attrs->version);
+
+ return integrity_inode_attrs_stat_changed(attrs, &stat);
}
diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
index 73d500a375cb37a54f295b0e1e93fd6e5d9ecddc..6a4e0e246005246d5700b1db590c1759242b9cb6 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -752,9 +752,8 @@ bool evm_metadata_changed(struct inode *inode, struct inode *metadata_inode)
bool ret = false;
if (iint) {
- ret = (!IS_I_VERSION(metadata_inode) ||
- integrity_inode_attrs_changed(&iint->metadata_inode,
- metadata_inode));
+ ret = integrity_inode_attrs_changed(&iint->metadata_inode,
+ NULL, metadata_inode);
if (ret)
iint->evm_status = INTEGRITY_UNKNOWN;
}
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 6570ad10887b9ea1172c78274cf62482350e87ff..8cb17c9d446caaa5a98f5ec8f027c17ba7babca8 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -328,9 +328,8 @@ static int process_measurement(struct file *file, const struct cred *cred,
real_inode = d_real_inode(file_dentry(file));
if (real_inode != inode &&
(action & IMA_DO_MASK) && (iint->flags & IMA_DONE_MASK)) {
- if (!IS_I_VERSION(real_inode) ||
- integrity_inode_attrs_changed(&iint->real_inode,
- real_inode)) {
+ if (integrity_inode_attrs_changed(&iint->real_inode,
+ file, real_inode)) {
iint->flags &= ~IMA_DONE_MASK;
iint->measured_pcrs = 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/3] ima: Use kstat.ctime as a fallback for change detection
From: Frederick Lawler @ 2026-02-09 21:21 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton
Cc: linux-kernel, linux-integrity, linux-security-module, kernel-team,
Frederick Lawler
In-Reply-To: <20260209-xfs-ima-fixup-v6-0-72f576f90e67@cloudflare.com>
IMA performs unnecessary measurements on files in file systems
that do not set STATX_CHANGE_COOKIE in the vfs_getattr_nosec()'s
result mask.
Commit 1cf7e834a6fb ("xfs: switch to multigrain timestamps") introduced
multigrain timestamps to XFS, and this made XFS no longer report an
inode's i_version used by ima_collect_measurement() for change detection.
Additionally, ima_check_last_writer() & integrity_inode_attributes_change()
think there's a change for a file, when there may have not been.
Most file systems already use ctime for change detection, therefore, make
IMA fall back to compare against ctime when a file system does not report
an i_version to the kstat.change_cookie.
If neither fields are reported by vfs_getattr_nosec(), assume the file
changed.
timespec64_to_ns() is chosen to avoid adding extra storage to
integrity_inode_attributes by leveraging the existing version field.
XFS is just one example. There may be more file systems that adopt
multigrain timestamps in the future.
Link: https://lore.kernel.org/all/aTspr4_h9IU4EyrR@CMGLRV3
Fixes: 1cf7e834a6fb ("xfs: switch to multigrain timestamps")
Suggested-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Frederick Lawler <fred@cloudflare.com>
---
include/linux/integrity.h | 6 +++++-
security/integrity/ima/ima_api.c | 11 ++++++++---
security/integrity/ima/ima_main.c | 2 +-
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/linux/integrity.h b/include/linux/integrity.h
index 382c783f0fa3ae4a938cdf9559291ba1903a378e..ec2c94907f417c4a71ecce29ac79edac9bc2c6f8 100644
--- a/include/linux/integrity.h
+++ b/include/linux/integrity.h
@@ -10,6 +10,7 @@
#include <linux/fs.h>
#include <linux/iversion.h>
#include <linux/kernel.h>
+#include <linux/time64.h>
enum integrity_status {
INTEGRITY_PASS = 0,
@@ -58,6 +59,9 @@ integrity_inode_attrs_stat_changed
if (stat->result_mask & STATX_CHANGE_COOKIE)
return stat->change_cookie != attrs->version;
+ if (stat->result_mask & STATX_CTIME)
+ return timespec64_to_ns(&stat->ctime) != (s64)attrs->version;
+
return true;
}
@@ -84,7 +88,7 @@ integrity_inode_attrs_changed(const struct integrity_inode_attributes *attrs,
* only for IMA if vfs_getattr_nosec() fails.
*/
if (!file || vfs_getattr_nosec(&file->f_path, &stat,
- STATX_CHANGE_COOKIE,
+ STATX_CHANGE_COOKIE | STATX_CTIME,
AT_STATX_SYNC_AS_STAT))
return !IS_I_VERSION(inode) ||
!inode_eq_iversion(inode, attrs->version);
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c35ea613c9f8d404ba4886e3b736c3bab29d1668..e47d6281febc15a0ac1bd2ea1d28fea4d0cd5c58 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -272,10 +272,15 @@ int ima_collect_measurement(struct ima_iint_cache *iint, struct file *file,
* to an initial measurement/appraisal/audit, but was modified to
* assume the file changed.
*/
- result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
+ result = vfs_getattr_nosec(&file->f_path, &stat,
+ STATX_CHANGE_COOKIE | STATX_CTIME,
AT_STATX_SYNC_AS_STAT);
- if (!result && (stat.result_mask & STATX_CHANGE_COOKIE))
- i_version = stat.change_cookie;
+ if (!result) {
+ if (stat.result_mask & STATX_CHANGE_COOKIE)
+ i_version = stat.change_cookie;
+ else if (stat.result_mask & STATX_CTIME)
+ i_version = timespec64_to_ns(&stat.ctime);
+ }
hash.hdr.algo = algo;
hash.hdr.length = hash_digest_size[algo];
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 8cb17c9d446caaa5a98f5ec8f027c17ba7babca8..776db158b0bd8a0d053729ac0cc15af8b6020a98 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -199,7 +199,7 @@ static void ima_check_last_writer(struct ima_iint_cache *iint,
&iint->atomic_flags);
if ((iint->flags & IMA_NEW_FILE) ||
vfs_getattr_nosec(&file->f_path, &stat,
- STATX_CHANGE_COOKIE,
+ STATX_CHANGE_COOKIE | STATX_CTIME,
AT_STATX_SYNC_AS_STAT) ||
integrity_inode_attrs_stat_changed(&iint->real_inode,
&stat)) {
--
2.43.0
^ permalink raw reply related
* Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-7.0-rc1
From: pr-tracker-bot @ 2026-02-10 0:50 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Linus Torvalds, Peter Huewe, Jason Gunthorpe, David Howells,
keyrings, linux-integrity, linux-kernel
In-Reply-To: <aYFFfTwGGFFl6hn7@kernel.org>
The pull request you sent on Tue, 3 Feb 2026 02:46:53 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-next-7.0-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/37b4fbf8dbdfb694f2972d1bd7fcd36304a520dd
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [GIT PULL] integrity: subsystem updates for v7.0
From: Mimi Zohar @ 2026-02-10 14:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-integrity, linux-kernel, Roberto Sassu
Hi Linus,
There are just two bug fixes: IMA's detecting scripts (bprm_creds_for_exec),
calculating the EVM HMAC.
thanks,
Mimi
The following changes since commit f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da:
Linux 6.19-rc3 (2025-12-28 13:24:26 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/ tags/integrity-v7.0
for you to fetch changes up to 0496fc9cdc384f67be4413b1c6156eb64fccd5c4:
evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac() (2026-01-23 14:31:41 -0500)
----------------------------------------------------------------
integrity-v7.0
----------------------------------------------------------------
Chris J Arges (1):
ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()
Roberto Sassu (1):
evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac()
security/integrity/evm/evm_crypto.c | 14 ++++++++++----
security/integrity/ima/ima.h | 6 ++++--
security/integrity/ima/ima_appraise.c | 16 +++-------------
security/integrity/ima/ima_main.c | 22 +++++++++++++---------
4 files changed, 30 insertions(+), 28 deletions(-)
^ 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