* Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
From: Petr Vorel @ 2026-04-16 6:40 UTC (permalink / raw)
To: kernel test robot
Cc: Michał Grzelak, lkp, intel-gfx, Jani Nikula, oe-lkp,
intel-xe, ltp, linux-integrity, Mimi Zohar
In-Reply-To: <202604150702.d409a2b6-lkp@intel.com>
Hi all,
[ Cc Mimi and linux-integrity ]
> Hello,
> kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps" on:
> commit: 07d1ee54da4966c1457602dc088a8a43b29254cb ("[PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default")
> url: https://github.com/intel-lab-lkp/linux/commits/Micha-Grzelak/drm-i915-lt-align-xe3plpd-with-VS-PE-Override-layout/20260401-092928
> base: https://gitlab.freedesktop.org/drm/i915/kernel.git for-linux-next
> patch link: https://lore.kernel.org/all/20260331183332.1773886-16-michal.grzelak@intel.com/
> patch subject: [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
> in testcase: ltp
> version:
> with following parameters:
> test: ima
> config: x86_64-rhel-9.4-ltp
> compiler: gcc-14
> test machine: 22 threads 1 sockets Intel(R) Core(TM) Ultra 9 185H @ 4.5GHz (Meteor Lake) with 32G memory
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202604150702.d409a2b6-lkp@intel.com
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com
> kern :err : [ 27.966990] [ T399] ==================================================================
> kern :err : [ 27.968126] [ T399] BUG: KASAN: slab-out-of-bounds in parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.969712] [ T399] Read of size 4 at addr ffff8881eba2c49d by task (udev-worker)/399
> kern :err : [ 27.971135] [ T399] CPU: 4 UID: 0 PID: 399 Comm: (udev-worker) Tainted: G S 7.0.0-rc4-01496-g07d1ee54da49 #1 PREEMPT(lazy)
> kern :err : [ 27.971139] [ T399] Tainted: [S]=CPU_OUT_OF_SPEC
> kern :err : [ 27.971140] [ T399] Hardware name: ASUSTeK COMPUTER INC. NUC14RVS-B/NUC14RVSU9, BIOS RVMTL357.0047.2025.0108.1408 01/08/2025
> kern :err : [ 27.971142] [ T399] Call Trace:
> kern :err : [ 27.971144] [ T399] <TASK>
> kern :err : [ 27.971145] [ T399] dump_stack_lvl+0x47/0x70
> kern :err : [ 27.971152] [ T399] print_address_description+0x88/0x320
> kern :err : [ 27.971156] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971355] [ T399] print_report+0x106/0x1f4
> kern :err : [ 27.971357] [ T399] ? __virt_addr_valid+0xc4/0x230
> kern :err : [ 27.971360] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971533] [ T399] kasan_report+0xb5/0xf0
> kern :err : [ 27.971537] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971704] [ T399] parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971868] [ T399] intel_bios_init+0xcc1/0x14b0 [i915]
> kern :err : [ 27.972042] [ T399] ? drm_vblank_init+0x147/0x330 [drm]
> kern :err : [ 27.972105] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> kern :err : [ 27.972295] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> kern :err : [ 27.972445] [ T399] ? __pfx_mutex_lock+0x10/0x10
> kern :err : [ 27.972450] [ T399] ? mutex_lock+0x91/0xf0
> kern :err : [ 27.972451] [ T399] ? __pfx_i915_driver_probe+0x10/0x10 [i915]
> kern :err : [ 27.972597] [ T399] ? drm_privacy_screen_get+0x2bf/0x370 [drm]
> kern :err : [ 27.972628] [ T399] ? intel_display_driver_probe_defer+0x41/0x70 [i915]
> kern :err : [ 27.972814] [ T399] ? i915_pci_probe+0x2ab/0x3b0 [i915]
> kern :err : [ 27.972963] [ T399] ? __pfx_i915_pci_probe+0x10/0x10 [i915]
> kern :err : [ 27.973110] [ T399] local_pci_probe+0xdb/0x1b0
> kern :err : [ 27.973114] [ T399] pci_call_probe+0x153/0x4f0
> kern :err : [ 27.973116] [ T399] ? __pfx_pci_call_probe+0x10/0x10
> kern :err : [ 27.973117] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973119] [ T399] ? pci_assign_irq+0x80/0x2f0
> kern :err : [ 27.973121] [ T399] ? pci_match_device+0x38d/0x6b0
> kern :err : [ 27.973123] [ T399] ? kernfs_create_link+0x164/0x230
> kern :err : [ 27.973127] [ T399] pci_device_probe+0x173/0x2f0
> kern :err : [ 27.973128] [ T399] call_driver_probe+0x62/0x1f0
> kern :err : [ 27.973132] [ T399] really_probe+0x197/0x770
> kern :err : [ 27.973134] [ T399] __driver_probe_device+0x18c/0x3b0
> kern :err : [ 27.973137] [ T399] driver_probe_device+0x4a/0x130
> kern :err : [ 27.973139] [ T399] __driver_attach+0x18c/0x4f0
> kern :err : [ 27.973141] [ T399] ? __pfx___driver_attach+0x10/0x10
> kern :err : [ 27.973143] [ T399] bus_for_each_dev+0xef/0x170
> kern :err : [ 27.973145] [ T399] ? kasan_unpoison+0x40/0x70
> kern :err : [ 27.973147] [ T399] ? __pfx_bus_for_each_dev+0x10/0x10
> kern :err : [ 27.973149] [ T399] ? __kasan_slab_alloc+0x2f/0x70
> kern :err : [ 27.973152] [ T399] ? klist_add_tail+0x132/0x270
> kern :err : [ 27.973154] [ T399] bus_add_driver+0x2a7/0x4f0
> kern :err : [ 27.973156] [ T399] driver_register+0x1a1/0x370
> kern :err : [ 27.973158] [ T399] i915_init+0x57/0x160 [i915]
> kern :err : [ 27.973307] [ T399] ? __pfx_i915_init+0x10/0x10 [i915]
> kern :err : [ 27.973453] [ T399] do_one_initcall+0x8d/0x3f0
> kern :err : [ 27.973455] [ T399] ? __pfx_do_one_initcall+0x10/0x10
> kern :err : [ 27.973457] [ T399] ? kasan_unpoison+0x3b/0x70
> kern :err : [ 27.973458] [ T399] ? kasan_unpoison+0x40/0x70
> kern :err : [ 27.973460] [ T399] do_init_module+0x281/0x830
> kern :err : [ 27.973463] [ T399] ? __pfx_do_init_module+0x10/0x10
> kern :err : [ 27.973464] [ T399] ? kfree+0x195/0x430
> kern :err : [ 27.973467] [ T399] load_module+0x173d/0x2070
> kern :err : [ 27.973469] [ T399] ? ima_post_read_file+0x18f/0x230
I'm surprised, but indeed it's could be triggered by IMA.
Looking at full dmesg [1] I'm surprised that this is triggered before tests are
actually run and there is no IMA specific kernel command line parameter. That
means that error is not related to any LTP test.
Is it always reproducible or just a random glitch?
ima_post_read_file() is a part of IMA core therefore issue might be not related
to any config, but just FYI kernel config [2].
Kind regards,
Petr
[1] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/kmsg.xz
[2] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/config-7.0.0-rc4-01496-g07d1ee54da49
> kern :err : [ 27.973474] [ T399] ? __pfx_load_module+0x10/0x10
> kern :err : [ 27.973476] [ T399] ? security_kernel_post_read_file+0x35/0xf0
> kern :err : [ 27.973479] [ T399] ? __pfx_kernel_read_file+0x10/0x10
> kern :err : [ 27.973483] [ T399] ? __pfx_current_time+0x10/0x10
> kern :err : [ 27.973486] [ T399] ? init_module_from_file+0x157/0x1b0
> kern :err : [ 27.973487] [ T399] init_module_from_file+0x157/0x1b0
> kern :err : [ 27.973489] [ T399] ? __pfx_init_module_from_file+0x10/0x10
> kern :err : [ 27.973491] [ T399] ? touch_atime+0x1bc/0x4f0
> kern :err : [ 27.973493] [ T399] ? _raw_spin_lock+0x80/0xf0
> kern :err : [ 27.973494] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973496] [ T399] ? __pfx_filemap_read+0x10/0x10
> kern :err : [ 27.973498] [ T399] ? do_sys_openat2+0xeb/0x170
> kern :err : [ 27.973501] [ T399] idempotent_init_module+0x21c/0x770
> kern :err : [ 27.973503] [ T399] ? __pfx_idempotent_init_module+0x10/0x10
> kern :err : [ 27.973505] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973506] [ T399] ? security_capable+0x35/0xf0
> kern :err : [ 27.973509] [ T399] __x64_sys_finit_module+0xca/0x170
> kern :err : [ 27.973511] [ T399] do_syscall_64+0x108/0x5b0
> kern :err : [ 27.973513] [ T399] ? vfs_read+0x3be/0x9b0
> kern :err : [ 27.973514] [ T399] ? vfs_read+0x3be/0x9b0
> kern :err : [ 27.973516] [ T399] ? __pfx_vfs_read+0x10/0x10
> kern :err : [ 27.973517] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973519] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973520] [ T399] ? __pfx___seccomp_filter+0x10/0x10
> kern :err : [ 27.973523] [ T399] ? __x64_sys_pread64+0x18d/0x1f0
> kern :err : [ 27.973525] [ T399] ? __pfx___x64_sys_pread64+0x10/0x10
> kern :err : [ 27.973526] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973528] [ T399] ? security_capable+0x35/0xf0
> kern :err : [ 27.973530] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973531] [ T399] ? arch_exit_to_user_mode_prepare+0x9e/0xf0
> kern :err : [ 27.973533] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973534] [ T399] ? __x64_sys_openat+0x104/0x1f0
> kern :err : [ 27.973536] [ T399] ? __pfx___x64_sys_openat+0x10/0x10
> kern :err : [ 27.973538] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973540] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973541] [ T399] ? irqentry_exit+0x76/0x4f0
> kern :err : [ 27.973544] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> kern :err : [ 27.973546] [ T399] RIP: 0033:0x7f3689aa8779
> kern :err : [ 27.973549] [ T399] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 67 76 0d 00 f7 d8 64 89 01 48
> kern :err : [ 27.973551] [ T399] RSP: 002b:00007ffca3326338 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> kern :err : [ 27.973555] [ T399] RAX: ffffffffffffffda RBX: 000055c94afdd3e0 RCX: 00007f3689aa8779
> kern :err : [ 27.973556] [ T399] RDX: 0000000000000000 RSI: 00007f36882ae44d RDI: 0000000000000053
> kern :err : [ 27.973557] [ T399] RBP: 0000000000000000 R08: 0000000000000000 R09: 000055c94af65b30
> kern :err : [ 27.973558] [ T399] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f36882ae44d
> kern :err : [ 27.973559] [ T399] R13: 0000000000020000 R14: 000055c94afb65f0 R15: 0000000000000000
> kern :err : [ 27.973561] [ T399] </TASK>
> kern :err : [ 28.051757] [ T399] Allocated by task 399:
> kern :warn : [ 28.052350] [ T399] kasan_save_stack+0x1e/0x70
> kern :warn : [ 28.053001] [ T399] kasan_save_track+0x10/0x30
> kern :warn : [ 28.053646] [ T399] __kasan_kmalloc+0x8b/0xb0
> kern :warn : [ 28.054278] [ T399] __kmalloc_noprof+0x1d8/0x5f0
> kern :warn : [ 28.054944] [ T399] init_bdb_block+0x128/0xc30 [i915]
> kern :warn : [ 28.055915] [ T399] intel_bios_init+0x4de/0x14b0 [i915]
> kern :warn : [ 28.056854] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> kern :warn : [ 28.057984] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> kern :warn : [ 28.058917] [ T399] local_pci_probe+0xdb/0x1b0
> kern :warn : [ 28.059565] [ T399] pci_call_probe+0x153/0x4f0
> kern :warn : [ 28.060210] [ T399] pci_device_probe+0x173/0x2f0
> kern :warn : [ 28.060878] [ T399] call_driver_probe+0x62/0x1f0
> kern :warn : [ 28.061547] [ T399] really_probe+0x197/0x770
> kern :warn : [ 28.062168] [ T399] __driver_probe_device+0x18c/0x3b0
> kern :warn : [ 28.062894] [ T399] driver_probe_device+0x4a/0x130
> kern :warn : [ 28.063587] [ T399] __driver_attach+0x18c/0x4f0
> kern :warn : [ 28.064243] [ T399] bus_for_each_dev+0xef/0x170
> kern :warn : [ 28.064898] [ T399] bus_add_driver+0x2a7/0x4f0
> kern :warn : [ 28.065543] [ T399] driver_register+0x1a1/0x370
> kern :warn : [ 28.066202] [ T399] i915_init+0x57/0x160 [i915]
> kern :warn : [ 28.067030] [ T399] do_one_initcall+0x8d/0x3f0
> kern :warn : [ 28.067677] [ T399] do_init_module+0x281/0x830
> kern :warn : [ 28.068320] [ T399] load_module+0x173d/0x2070
> kern :warn : [ 28.068951] [ T399] init_module_from_file+0x157/0x1b0
> kern :warn : [ 28.069678] [ T399] idempotent_init_module+0x21c/0x770
> kern :warn : [ 28.070417] [ T399] __x64_sys_finit_module+0xca/0x170
> kern :warn : [ 28.071143] [ T399] do_syscall_64+0x108/0x5b0
> kern :warn : [ 28.071777] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> kern :err : [ 28.072915] [ T399] The buggy address belongs to the object at ffff8881eba2c000
> which belongs to the cache kmalloc-2k of size 2048
> kern :err : [ 28.074832] [ T399] The buggy address is located 0 bytes to the right of
> allocated 1181-byte region [ffff8881eba2c000, ffff8881eba2c49d)
> kern :err : [ 28.077135] [ T399] The buggy address belongs to the physical page:
> kern :warn : [ 28.078017] [ T399] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eba28
> kern :warn : [ 28.079226] [ T399] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> kern :warn : [ 28.080389] [ T399] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
> kern :warn : [ 28.081460] [ T399] page_type: f5(slab)
> kern :warn : [ 28.082008] [ T399] raw: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> kern :warn : [ 28.083180] [ T399] raw: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> kern :warn : [ 28.084355] [ T399] head: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> kern :warn : [ 28.085541] [ T399] head: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> kern :warn : [ 28.086725] [ T399] head: 0017ffffc0000003 ffffea0007ae8a01 00000000ffffffff 00000000ffffffff
> kern :warn : [ 28.087909] [ T399] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> kern :warn : [ 28.089093] [ T399] page dumped because: kasan: bad access detected
> kern :err : [ 28.090297] [ T399] Memory state around the buggy address:
> kern :err : [ 28.091073] [ T399] ffff8881eba2c380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> kern :err : [ 28.092175] [ T399] ffff8881eba2c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> kern :err : [ 28.093276] [ T399] >ffff8881eba2c480: 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.094376] [ T399] ^
> kern :err : [ 28.095041] [ T399] ffff8881eba2c500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.096145] [ T399] ffff8881eba2c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.097247] [ T399] ==================================================================
> kern :warn : [ 28.098668] [ T399] Disabling lock debugging due to kernel taint
^ permalink raw reply
* Re: [PATCH v4] KEYS: trusted: Debugging as a feature
From: Nayna Jain @ 2026-04-16 3:16 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-integrity
Cc: Srish Srinivasan, Jonathan Corbet, Shuah Khan, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
Andrew Morton, Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Pawan Gupta, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Li RongQing, Paul E. McKenney, Thomas Gleixner, Bjorn Helgaas,
linux-doc, linux-kernel, keyrings, linux-security-module
In-Reply-To: <20260415111202.63888-1-jarkko@kernel.org>
On 4/15/26 7:12 AM, Jarkko Sakkinen wrote:
> TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> keys, and use it to replace these ad-hoc feature flags.
>
> Given that trusted keys debug dumps can contain sensitive data, harden the
> feature as follows:
>
> 1. In the Kconfig description postulate that pr_debug() statements must be
> used.
> 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
>
> Traces, when actually needed, can be easily enabled by providing
> trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
Thanks for adding the documentation.
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
>
> Reported-by: Nayna Jain <nayna@linux.ibm.com>
> Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
> Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> v4:
> - Added kernel parameter documentation.t
> - Added tags from Srishand and Nayna.
> - Sanity check round. This version will be applied unless there is
> something specific to address.
> v3:
> - Add kernel-command line option for enabling the traces.
> - Add safety information to the Kconfig entry.
> v2:
> - Implement for all trusted keys backends.
> - Add HAVE_TRUSTED_KEYS_DEBUG as it is a good practice despite full
> coverage.
> ---
> .../admin-guide/kernel-parameters.txt | 16 +++++++
> include/keys/trusted-type.h | 21 +++++----
> security/keys/trusted-keys/Kconfig | 23 ++++++++++
> security/keys/trusted-keys/trusted_caam.c | 7 ++-
> security/keys/trusted-keys/trusted_core.c | 6 +++
> security/keys/trusted-keys/trusted_tpm1.c | 44 +++++++++++--------
> 6 files changed, 87 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index f2ce1f4975c1..f1515668c8ab 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7917,6 +7917,22 @@ Kernel parameters
> first trust source as a backend which is initialized
> successfully during iteration.
>
> + trusted.debug= [KEYS]
> + Format: <bool>
> + Enable trusted keys debug traces at runtime when
> + CONFIG_TRUSTED_KEYS_DEBUG=y.
> +
> + To make the traces visible after enabling the option,
> + use trusted.dyndbg='+p' as needed. By convention,
> + the subsystem uses pr_debug() for these traces.
> +
> + SAFETY: The traces can leak sensitive data, so be
> + cautious before enabling this. They remain inactive
> + unless this parameter is set this option to a true
> + value.
> +
> + Default: false
> +
> trusted.rng= [KEYS]
> Format: <string>
> The RNG used to generate key material for trusted keys.
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 03527162613f..9f9940482da4 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -83,18 +83,21 @@ struct trusted_key_source {
>
> extern struct key_type key_type_trusted;
>
> -#define TRUSTED_DEBUG 0
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> +extern bool trusted_debug;
>
> -#if TRUSTED_DEBUG
> static inline void dump_payload(struct trusted_key_payload *p)
> {
> - pr_info("key_len %d\n", p->key_len);
> - print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> - 16, 1, p->key, p->key_len, 0);
> - pr_info("bloblen %d\n", p->blob_len);
> - print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> - 16, 1, p->blob, p->blob_len, 0);
> - pr_info("migratable %d\n", p->migratable);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("key_len %d\n", p->key_len);
> + print_hex_dump_debug("key ", DUMP_PREFIX_NONE,
> + 16, 1, p->key, p->key_len, 0);
> + pr_debug("bloblen %d\n", p->blob_len);
> + print_hex_dump_debug("blob ", DUMP_PREFIX_NONE,
> + 16, 1, p->blob, p->blob_len, 0);
> + pr_debug("migratable %d\n", p->migratable);
> }
> #else
> static inline void dump_payload(struct trusted_key_payload *p)
> diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
> index 9e00482d886a..e5a4a53aeab2 100644
> --- a/security/keys/trusted-keys/Kconfig
> +++ b/security/keys/trusted-keys/Kconfig
> @@ -1,10 +1,29 @@
> config HAVE_TRUSTED_KEYS
> bool
>
> +config HAVE_TRUSTED_KEYS_DEBUG
> + bool
> +
> +config TRUSTED_KEYS_DEBUG
> + bool "Debug trusted keys"
> + depends on HAVE_TRUSTED_KEYS_DEBUG
> + default n
> + help
> + Trusted key backends and core code that support debug traces can
> + opt-in that feature here. Traces must only use debug level output, as
> + sensitive data may pass by. In the kernel-command line traces can be
> + enabled via trusted.dyndbg='+p'.
> +
> + SAFETY: Debug dumps are inactive at runtime until trusted.debug is set
> + to a true value on the kernel command-line. Use at your utmost
> + consideration when enabling this feature on a production build. The
> + general advice is not to do this.
> +
> config TRUSTED_KEYS_TPM
> bool "TPM-based trusted keys"
> depends on TCG_TPM >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select CRYPTO_HASH_INFO
> select CRYPTO_LIB_SHA1
> select CRYPTO_LIB_UTILS
> @@ -23,6 +42,7 @@ config TRUSTED_KEYS_TEE
> bool "TEE-based trusted keys"
> depends on TEE >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of the Trusted Execution Environment (TEE) as trusted
> @@ -33,6 +53,7 @@ config TRUSTED_KEYS_CAAM
> depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
> select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of NXP's Cryptographic Accelerator and Assurance Module
> @@ -42,6 +63,7 @@ config TRUSTED_KEYS_DCP
> bool "DCP-based trusted keys"
> depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
> @@ -50,6 +72,7 @@ config TRUSTED_KEYS_PKWM
> bool "PKWM-based trusted keys"
> depends on PSERIES_PLPKS >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of IBM PowerVM Key Wrapping Module (PKWM) as a trusted key backend.
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60..6a33dbf2a7f5 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -28,10 +28,13 @@ static const match_table_t key_tokens = {
> {opt_err, NULL}
> };
>
> -#ifdef CAAM_DEBUG
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> static inline void dump_options(const struct caam_pkey_info *pkey_info)
> {
> - pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("key encryption algo %d\n", pkey_info->key_enc_algo);
> }
> #else
> static inline void dump_options(const struct caam_pkey_info *pkey_info)
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 0b142d941cd2..6aed17bee09d 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -31,6 +31,12 @@ static char *trusted_rng = "default";
> module_param_named(rng, trusted_rng, charp, 0);
> MODULE_PARM_DESC(rng, "Select trusted key RNG");
>
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> +bool trusted_debug;
> +module_param_named(debug, trusted_debug, bool, 0);
> +MODULE_PARM_DESC(debug, "Enable trusted keys debug traces (default: 0)");
> +#endif
> +
> static char *trusted_key_source;
> module_param_named(source, trusted_key_source, charp, 0);
> MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam, dcp or pkwm)");
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 6ea728f1eae6..13513819991e 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -46,38 +46,44 @@ enum {
> SRK_keytype = 4
> };
>
> -#define TPM_DEBUG 0
> -
> -#if TPM_DEBUG
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> static inline void dump_options(struct trusted_key_options *o)
> {
> - pr_info("sealing key type %d\n", o->keytype);
> - pr_info("sealing key handle %0X\n", o->keyhandle);
> - pr_info("pcrlock %d\n", o->pcrlock);
> - pr_info("pcrinfo %d\n", o->pcrinfo_len);
> - print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
> - 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("sealing key type %d\n", o->keytype);
> + pr_debug("sealing key handle %0X\n", o->keyhandle);
> + pr_debug("pcrlock %d\n", o->pcrlock);
> + pr_debug("pcrinfo %d\n", o->pcrinfo_len);
> + print_hex_dump_debug("pcrinfo ", DUMP_PREFIX_NONE,
> + 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> }
>
> static inline void dump_sess(struct osapsess *s)
> {
> - print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> - 16, 1, &s->handle, 4, 0);
> - pr_info("secret:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> - 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> - pr_info("trusted-key: enonce:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> - 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> + if (!trusted_debug)
> + return;
> +
> + print_hex_dump_debug("trusted-key: handle ", DUMP_PREFIX_NONE,
> + 16, 1, &s->handle, 4, 0);
> + pr_debug("secret:\n");
> + print_hex_dump_debug("", DUMP_PREFIX_NONE,
> + 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> + pr_debug("trusted-key: enonce:\n");
> + print_hex_dump_debug("", DUMP_PREFIX_NONE,
> + 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> }
>
> static inline void dump_tpm_buf(unsigned char *buf)
> {
> int len;
>
> - pr_info("\ntpm buffer\n");
> + if (!trusted_debug)
> + return;
> + pr_debug("\ntpm buffer\n");
> len = LOAD32(buf, TPM_SIZE_OFFSET);
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> + print_hex_dump_debug("", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> }
> #else
> static inline void dump_options(struct trusted_key_options *o)
^ permalink raw reply
* Re: [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Marco Felsch @ 2026-04-15 20:50 UTC (permalink / raw)
To: Josh Snyder
Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20260415-trusted-key-header-v2-1-5244f9ef0d09@code406.com>
On 26-04-15, Josh Snyder wrote:
> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> prefix into every translation unit that transitively includes
> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
>
> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
>
> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> addition, so the regression has been live from the moment the header
> gained its own pr_fmt definition.
>
> Move the pr_fmt definition into the trusted-keys source files that
> actually want the prefix, with specific prefixes for each key type.
>
> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Josh Snyder <josh@code406.com>
> ---
> Changes in v2:
> - specific pr_fmt based on trusted key type
> ---
> include/keys/trusted-type.h | 6 ------
> security/keys/trusted-keys/trusted_caam.c | 2 ++
> security/keys/trusted-keys/trusted_core.c | 2 ++
> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
You missed the trusted_tee.c, sorry for not spotting this earlier.
Regards,
Marco
> 7 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 03527162613f7..54da1f174aeab 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -11,12 +11,6 @@
> #include <linux/rcupdate.h>
> #include <linux/tpm.h>
>
> -#ifdef pr_fmt
> -#undef pr_fmt
> -#endif
> -
> -#define pr_fmt(fmt) "trusted_key: " fmt
> -
> #define MIN_KEY_SIZE 32
> #define MAX_KEY_SIZE 128
> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60f..71c173bb2f727 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -4,6 +4,8 @@
> * Copyright 2025 NXP
> */
>
> +#define pr_fmt(fmt) "trusted_key: caam: " fmt
> +
> #include <keys/trusted_caam.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 0b142d941cd2e..159af9dcfc774 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: " fmt
> +
> #include <keys/user-type.h>
> #include <keys/trusted-type.h>
> #include <keys/trusted_tee.h>
> diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
> index 7b6eb655df0cb..41a23e2f30891 100644
> --- a/security/keys/trusted-keys/trusted_dcp.c
> +++ b/security/keys/trusted-keys/trusted_dcp.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2021 sigma star gmbh
> */
>
> +#define pr_fmt(fmt) "trusted_key: dcp: " fmt
> +
> #include <crypto/aead.h>
> #include <crypto/aes.h>
> #include <crypto/algapi.h>
> diff --git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
> index bf42c6679245a..108db105b639f 100644
> --- a/security/keys/trusted-keys/trusted_pkwm.c
> +++ b/security/keys/trusted-keys/trusted_pkwm.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
> */
>
> +#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
> +
> #include <keys/trusted_pkwm.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 6ea728f1eae6f..207be849796ed 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
> +
> #include <crypto/hash_info.h>
> #include <crypto/sha1.h>
> #include <crypto/utils.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index 6340823f8b53c..2a540b1af0b33 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -4,6 +4,8 @@
> * Copyright (C) 2014 Intel Corporation
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
> +
> #include <linux/asn1_encoder.h>
> #include <linux/oid_registry.h>
> #include <linux/string.h>
>
> ---
> base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
> change-id: 20260411-trusted-key-header-a544a4f149d2
>
> Best regards,
> --
> Josh
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Josh Snyder @ 2026-04-15 20:40 UTC (permalink / raw)
To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg
Cc: linux-integrity, keyrings, linux-kernel, linux-security-module,
Josh Snyder
Defining pr_fmt in a widely-included header leaks the "trusted_key: "
prefix into every translation unit that transitively includes
<keys/trusted-type.h>. dm-crypt, for example, ends up printing
trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
("dm crypt: support using trusted keys"), which predates the pr_fmt
addition, so the regression has been live from the moment the header
gained its own pr_fmt definition.
Move the pr_fmt definition into the trusted-keys source files that
actually want the prefix, with specific prefixes for each key type.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Josh Snyder <josh@code406.com>
---
Changes in v2:
- specific pr_fmt based on trusted key type
---
| 6 ------
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
7 files changed, 12 insertions(+), 6 deletions(-)
--git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 03527162613f7..54da1f174aeab 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -11,12 +11,6 @@
#include <linux/rcupdate.h>
#include <linux/tpm.h>
-#ifdef pr_fmt
-#undef pr_fmt
-#endif
-
-#define pr_fmt(fmt) "trusted_key: " fmt
-
#define MIN_KEY_SIZE 32
#define MAX_KEY_SIZE 128
#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
--git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
index 601943ce0d60f..71c173bb2f727 100644
--- a/security/keys/trusted-keys/trusted_caam.c
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -4,6 +4,8 @@
* Copyright 2025 NXP
*/
+#define pr_fmt(fmt) "trusted_key: caam: " fmt
+
#include <keys/trusted_caam.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0b142d941cd2e..159af9dcfc774 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: " fmt
+
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <keys/trusted_tee.h>
--git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
index 7b6eb655df0cb..41a23e2f30891 100644
--- a/security/keys/trusted-keys/trusted_dcp.c
+++ b/security/keys/trusted-keys/trusted_dcp.c
@@ -3,6 +3,8 @@
* Copyright (C) 2021 sigma star gmbh
*/
+#define pr_fmt(fmt) "trusted_key: dcp: " fmt
+
#include <crypto/aead.h>
#include <crypto/aes.h>
#include <crypto/algapi.h>
--git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
index bf42c6679245a..108db105b639f 100644
--- a/security/keys/trusted-keys/trusted_pkwm.c
+++ b/security/keys/trusted-keys/trusted_pkwm.c
@@ -3,6 +3,8 @@
* Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
*/
+#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
+
#include <keys/trusted_pkwm.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 6ea728f1eae6f..207be849796ed 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
+
#include <crypto/hash_info.h>
#include <crypto/sha1.h>
#include <crypto/utils.h>
--git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 6340823f8b53c..2a540b1af0b33 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -4,6 +4,8 @@
* Copyright (C) 2014 Intel Corporation
*/
+#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
+
#include <linux/asn1_encoder.h>
#include <linux/oid_registry.h>
#include <linux/string.h>
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-trusted-key-header-a544a4f149d2
Best regards,
--
Josh
^ permalink raw reply related
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Stefan Berger @ 2026-04-15 20:32 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <be3fdb81a322ab96e356e165b737c46f00c12cc3.camel@linux.ibm.com>
On 4/14/26 10:01 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Add support for sigv3 signature verification using ML-DSA in pure mode.
>> When a sigv3 signature is verified, first check whether the key to use
>> for verification is an ML-DSA key and therefore uses a hashless signature
>> verification scheme. The hashless signature verification method uses the
>> ima_file_id structure directly for signature verification rather than
>> its digest.
>>
>> Suggested-by: Eric Biggers <ebiggers@kernel.org>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>>
>
> Thanks, Stefan.
>> ---
>> v2: Set hash_algo in public_key_signature to "none"
>> ---
>> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
>> 1 file changed, 79 insertions(+), 5 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index e29ed73f15cd..c80cb2b117a6 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
>> return rc;
>> }
>>
>> +/*
>
> kernel-doc starts with "/**".
I followed the pattern of documentation of a static function that you
just moved:
/*
* calc_file_id_hash - calculate the hash of the ima_file_id struct data
* @type: xattr type [enum evm_ima_xattr_type]
>
>> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
>> + * @key: The key to use for signature verification
>> + * @pk: The associated public key
>> + * @encoding: The encoding the key type uses
>> + * @sig: The signature
>> + * @siglen: The length of the xattr signature
>> + * @algo: The hash algorithm
>> + * @digest: The file digest
>> + *
>> + * Create an ima_file_id structure and use it for signature verification
>> + * directly. This can be used for ML-DSA in pure mode for example.
>
> Like the comments on 1/2, please add a comment here indicating that all callers
> must verify the signature length (siglen) and the public key (pk) is not NULL,
> before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
> must free the key.
>
>> + */
>> +static int asymmetric_verify_v3_hashless(struct key *key,
>> + const struct public_key *pk,
>> + const char *encoding,
>> + const char *sig, int siglen,
>> + u8 algo,
>> + const u8 *digest)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + struct ima_file_id file_id = {
>> + .hash_type = hdr->type,
>> + .hash_algorithm = algo,
>> + };
>> + size_t digest_size = hash_digest_size[algo];
>
> Defer initializing the digest_size and .m_size, below, until after checking the
> hash algorithm is valid.
This function is called by asymmetric_verify. asymmetric_verify calls
calc_file_id_hash, which doesn't check algo for valid range, either. I
suppose it's an untrusted value at this point (IMA never checked it's
value for valid range?) an we should check it in asymmetric_verify then
to cover both cases? Or you want to check it individually?
>
>> + struct public_key_signature pks = {
>> + .m = (u8 *)&file_id,
>> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
>> + .s = hdr->sig,
>> + .s_size = siglen - sizeof(*hdr),
>> + .pkey_algo = pk->pkey_algo,
>> + .hash_algo = "none",
>> + .encoding = encoding,
>> + };
>> + int ret;
>> +
>> + if (hdr->type != IMA_VERITY_DIGSIG &&
>> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
>> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
>> + return -EINVAL;
>> +
>> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
>> + return -EBADMSG;
>> +
>> + memcpy(file_id.hash, digest, digest_size);
>
> First check the hash algorithm is valid, before using digest_size.
>
>> +
>> + ret = verify_signature(key, &pks);
>> + pr_debug("%s() = %d\n", __func__, ret);
>> + return ret;
>> +}
>> +
>> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
>> const char *data, int datalen, u8 algo)
>> {
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> struct ima_max_digest_data hash;
>> + const struct public_key *pk;
>> + struct key *key;
>> int rc;
>>
>> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> - if (rc)
>> - return -EINVAL;
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>>
>> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
>> - hash.hdr.length);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test to check that 'pk' isn't null.
>
>> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
>> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
>> + sig, siglen, algo, data);
>> + } else {
>> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> + if (rc) {
>> + rc = -EINVAL;
>> + goto err_exit;
>> + }
>> +
>> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
>> + hash.hdr.length);
>> + }
>> +
>> +err_exit:
>
> Normally a label named 'err*' would be preceded by a return. Here, the label
> "err_exit" is always called, not only when there is an error. Please rename the
> label to something more appropriate - out, cleanup, etc.
Ok, will call it 'out'.
>
>> + key_put(key);
>> +
>> + return rc;
>> }
>
> thanks,
>
> Mimi
>
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Stefan Berger @ 2026-04-15 20:15 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <0375ccecdfb77286dff7f40af5ddbd20f7d6e0fa.camel@linux.ibm.com>
On 4/14/26 10:00 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Refactor asymmetric_verify for reusability. Have it call
>> asymmetric_verify_common with the signature verification key and the
>> public_key structure as parameters. sigv3 support for ML-DSA will need to
>> check the public key type first to decide how to do the signature
>> verification and therefore will have these parameters available for
>> calling asymmetric_verify_common.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
> Thanks, Stefan.
>
>> ---
>> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
>> 1 file changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index 6e68ec3becbd..e29ed73f15cd 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
>> return key;
>> }
>>
>> -int asymmetric_verify(struct key *keyring, const char *sig,
>> - int siglen, const char *data, int datalen)
>> +static int asymmetric_verify_common(const struct key *key,
>> + const struct public_key *pk,
>> + const char *sig, int siglen,
>> + const char *data, int datalen)
>> {
>> - struct public_key_signature pks;
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> - const struct public_key *pk;
>> - struct key *key;
>> + struct public_key_signature pks;
>> int ret;
>>
>> - if (siglen <= sizeof(*hdr))
>> - return -EBADMSG;
>> -
>> siglen -= sizeof(*hdr);
>
> Normally kernel-doc is unnecessary for static functions. Here, however, since
> only the caller verifies the signature length, there should be a kernel-doc
> function definition. It should indicate that all callers must verify the
> signature length (siglen) and that the public key (pk) is not NULL, before
> calling asymmetric_verify_common().
Will add.
>
>>
>> if (siglen != be16_to_cpu(hdr->sig_size))
>> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> if (hdr->hash_algo >= HASH_ALGO__LAST)
>> return -ENOPKG;
>>
>> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> - if (IS_ERR(key))
>> - return PTR_ERR(key);
>> -
>> memset(&pks, 0, sizeof(pks));
>>
>> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>>
>> - pk = asymmetric_key_public_key(key);
>> pks.pkey_algo = pk->pkey_algo;
>> if (!strcmp(pk->pkey_algo, "rsa")) {
>> pks.encoding = "pkcs1";
>> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> pks.s_size = siglen;
>> ret = verify_signature(key, &pks);
>> out:
>> - key_put(key);
>
> The kernel-doc function definition should also indicate that the caller must
> free the key.
Ok, I will add it. However, symmetric_verify_common cannot free the key
since it is passed as const(!) struct key *key...
>
>> pr_debug("%s() = %d\n", __func__, ret);
>> return ret;
>> }
>>
>> +int asymmetric_verify(struct key *keyring, const char *sig,
>> + int siglen, const char *data, int datalen)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + const struct public_key *pk;
>> + struct key *key;
>> + int ret;
>> +
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test here making sure pk is not null.
As a separate patch for backporting?
Return -ENOKEY in case we hit a NULL pointer?
>
> thanks,
>
> Mimi
>
>> +
>> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
>> +
>> + key_put(key);
>> +
>> + return ret;
>> +}
>> +
>> /*
>> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
>> * @type: xattr type [enum evm_ima_xattr_type]
>
^ permalink raw reply
* Re: [PATCH] ima: Use KEXEC_SIG_FORCE for rejecting unsigned kexec images
From: Mimi Zohar @ 2026-04-15 19:22 UTC (permalink / raw)
To: Chi Wang, roberto.sassu, dmitry.kasatkin, eric.snowberg
Cc: paul, jmorris, serge, linux-integrity, linux-security-module,
linux-kernel, Chi Wang
In-Reply-To: <20260415102319.431379-1-wangchi05@163.com>
On Wed, 2026-04-15 at 18:23 +0800, Chi Wang wrote:
> From: Chi Wang <wangchi@kylinos.cn>
>
> Following the split of KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE,
> only KEXEC_SIG_FORCE indicates that unsigned kernel images must be rejected.
> KEXEC_SIG alone enables signature verification but permits unsigned images,
> so it should not trigger the IMA appraisal denial for kexec_load.
>
> Update the condition in ima_load_data() to check for KEXEC_SIG_FORCE
> instead of KEXEC_SIG.
>
> Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
>
> Signed-off-by: Chi Wang <wangchi@kylinos.cn>
It isn't enough to check whether CONFIG_KEXEC_SIG_FORCE is configured, since it
is possible to require the kexec kernel image to be signed at runtime. Based on
the IMA policy, IMA will call set_kexec_sig_enforced() to require the kexec
kernel image to be signed.
Mimi
> ---
> security/integrity/ima/ima_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 1d6229b156fb..ec70e78ab8cd 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -953,7 +953,7 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
>
> switch (id) {
> case LOADING_KEXEC_IMAGE:
> - if (IS_ENABLED(CONFIG_KEXEC_SIG)
> + if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)
> && arch_ima_get_secureboot()) {
> pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
> return -EACCES;
> --
> 2.25.1
^ permalink raw reply
* [PATCH v3 2/2] tpm: tpm_tis: stop transmit if retries are exhausted
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
In-Reply-To: <20260415160006.2275325-1-jacqwong@google.com>
tpm_tis_send_main() will attempt to retry sending data TPM_RETRY times.
Currently, if those retries are exhausted, the driver will attempt to
call execute. The TPM will be in the wrong state, leading to the
operation simply timing out.
Instead, if there is still an error after retries are exhausted, return
that error immediately.
Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors")
Signed-off-by: Jacqueline Wong <jacqwong@google.com>
Signed-off-by: Jordan Hand <jhand@google.com>
---
drivers/char/tpm/tpm_tis_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index acb91bf1e5f5..21d79ad3b164 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -556,11 +556,16 @@ static int tpm_tis_send_main(struct tpm_chip *chip, const u8 *buf, size_t len)
break;
else if (rc != -EAGAIN && rc != -EIO)
/* Data transfer failed, not recoverable */
- return rc;
+ goto out_err;
usleep_range(priv->timeout_min, priv->timeout_max);
}
+ if (rc == -EAGAIN || rc == -EIO) {
+ dev_err(&chip->dev, "Exhausted %d tpm_tis_send_data retries\n", TPM_RETRY);
+ goto out_err;
+ }
+
/* go and do it */
rc = tpm_tis_write8(priv, TPM_STS(priv->locality), TPM_STS_GO);
if (rc < 0)
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH v3 1/2] tpm: tpm_tis: add error logging for data transfer
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
In-Reply-To: <20260415160006.2275325-1-jacqwong@google.com>
Add logging to more easily determine reason for transmit failure
Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors")
Signed-off-by: Jacqueline Wong <jacqwong@google.com>
Signed-off-by: Jordan Hand <jhand@google.com>
---
drivers/char/tpm/tpm_tis_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index e2a1769081b1..acb91bf1e5f5 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -471,6 +471,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
rc = -EIO;
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be set. sts = 0x%08x\n",
+ status);
goto out_err;
}
}
@@ -491,6 +493,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
rc = -EIO;
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be unset. sts = 0x%08x\n",
+ status);
goto out_err;
}
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH v3 0/2] tpm_tis: fix retry exhaustion and add logging
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
The Fix:
- Patch 1: Adds error logs to identify the specific hardware status mismatch.
- Patch 2: Stops execution immediately when retries are exhausted.
v3 changes:
- Improved code alignment to pass checkpatch --strict.
v2 changes:
- Split logging and logic into separate patches.
- Added retry count to the error message.
- Included dmesg traces below.
Testing:
Dmesg traces obtained using error injection to simulate status register mismatches.
Before:
[ 130.288751] tpm tpm0: Operation Timed out
[ 250.306070] tpm tpm0: Operation Timed out
[ 250.310173] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts
After:
[ 10.271547] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
...
[ 10.646283] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
[ 10.653461] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
[ 10.659304] tpm tpm0: tpm_try_transmit: send(): error -5
[ 10.665435] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
...
[ 11.037198] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
[ 11.044441] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
[ 11.050288] tpm tpm0: tpm_try_transmit: send(): error -5
[ 11.055723] tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
Jacqueline Wong (2):
tpm: tpm_tis: add error logging for data transfer
tpm: tpm_tis: stop transmit if retries are exhausted
drivers/char/tpm/tpm_tis_core.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply
* [PATCH v4] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 11:12 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Nayna Jain, Srish Srinivasan, Jonathan Corbet,
Shuah Khan, James Bottomley, Mimi Zohar, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, Ahmad Fatoum,
Pengutronix Kernel Team, Andrew Morton, Borislav Petkov (AMD),
Randy Dunlap, Dave Hansen, Pawan Gupta, Feng Tang, Dapeng Mi,
Kees Cook, Marco Elver, Li RongQing, Paul E. McKenney,
Thomas Gleixner, Bjorn Helgaas, linux-doc, linux-kernel, keyrings,
linux-security-module
TPM_DEBUG, and other similar flags, are a non-standard way to specify a
feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
keys, and use it to replace these ad-hoc feature flags.
Given that trusted keys debug dumps can contain sensitive data, harden the
feature as follows:
1. In the Kconfig description postulate that pr_debug() statements must be
used.
2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
3. Require trusted.debug=1 on the kernel command line (default: 0) to
activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
Traces, when actually needed, can be easily enabled by providing
trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
Reported-by: Nayna Jain <nayna@linux.ibm.com>
Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
v4:
- Added kernel parameter documentation.t
- Added tags from Srishand and Nayna.
- Sanity check round. This version will be applied unless there is
something specific to address.
v3:
- Add kernel-command line option for enabling the traces.
- Add safety information to the Kconfig entry.
v2:
- Implement for all trusted keys backends.
- Add HAVE_TRUSTED_KEYS_DEBUG as it is a good practice despite full
coverage.
---
.../admin-guide/kernel-parameters.txt | 16 +++++++
include/keys/trusted-type.h | 21 +++++----
security/keys/trusted-keys/Kconfig | 23 ++++++++++
security/keys/trusted-keys/trusted_caam.c | 7 ++-
security/keys/trusted-keys/trusted_core.c | 6 +++
security/keys/trusted-keys/trusted_tpm1.c | 44 +++++++++++--------
6 files changed, 87 insertions(+), 30 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2ce1f4975c1..f1515668c8ab 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7917,6 +7917,22 @@ Kernel parameters
first trust source as a backend which is initialized
successfully during iteration.
+ trusted.debug= [KEYS]
+ Format: <bool>
+ Enable trusted keys debug traces at runtime when
+ CONFIG_TRUSTED_KEYS_DEBUG=y.
+
+ To make the traces visible after enabling the option,
+ use trusted.dyndbg='+p' as needed. By convention,
+ the subsystem uses pr_debug() for these traces.
+
+ SAFETY: The traces can leak sensitive data, so be
+ cautious before enabling this. They remain inactive
+ unless this parameter is set this option to a true
+ value.
+
+ Default: false
+
trusted.rng= [KEYS]
Format: <string>
The RNG used to generate key material for trusted keys.
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 03527162613f..9f9940482da4 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -83,18 +83,21 @@ struct trusted_key_source {
extern struct key_type key_type_trusted;
-#define TRUSTED_DEBUG 0
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
+extern bool trusted_debug;
-#if TRUSTED_DEBUG
static inline void dump_payload(struct trusted_key_payload *p)
{
- pr_info("key_len %d\n", p->key_len);
- print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
- 16, 1, p->key, p->key_len, 0);
- pr_info("bloblen %d\n", p->blob_len);
- print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
- 16, 1, p->blob, p->blob_len, 0);
- pr_info("migratable %d\n", p->migratable);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("key_len %d\n", p->key_len);
+ print_hex_dump_debug("key ", DUMP_PREFIX_NONE,
+ 16, 1, p->key, p->key_len, 0);
+ pr_debug("bloblen %d\n", p->blob_len);
+ print_hex_dump_debug("blob ", DUMP_PREFIX_NONE,
+ 16, 1, p->blob, p->blob_len, 0);
+ pr_debug("migratable %d\n", p->migratable);
}
#else
static inline void dump_payload(struct trusted_key_payload *p)
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index 9e00482d886a..e5a4a53aeab2 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -1,10 +1,29 @@
config HAVE_TRUSTED_KEYS
bool
+config HAVE_TRUSTED_KEYS_DEBUG
+ bool
+
+config TRUSTED_KEYS_DEBUG
+ bool "Debug trusted keys"
+ depends on HAVE_TRUSTED_KEYS_DEBUG
+ default n
+ help
+ Trusted key backends and core code that support debug traces can
+ opt-in that feature here. Traces must only use debug level output, as
+ sensitive data may pass by. In the kernel-command line traces can be
+ enabled via trusted.dyndbg='+p'.
+
+ SAFETY: Debug dumps are inactive at runtime until trusted.debug is set
+ to a true value on the kernel command-line. Use at your utmost
+ consideration when enabling this feature on a production build. The
+ general advice is not to do this.
+
config TRUSTED_KEYS_TPM
bool "TPM-based trusted keys"
depends on TCG_TPM >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select CRYPTO_HASH_INFO
select CRYPTO_LIB_SHA1
select CRYPTO_LIB_UTILS
@@ -23,6 +42,7 @@ config TRUSTED_KEYS_TEE
bool "TEE-based trusted keys"
depends on TEE >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of the Trusted Execution Environment (TEE) as trusted
@@ -33,6 +53,7 @@ config TRUSTED_KEYS_CAAM
depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of NXP's Cryptographic Accelerator and Assurance Module
@@ -42,6 +63,7 @@ config TRUSTED_KEYS_DCP
bool "DCP-based trusted keys"
depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
@@ -50,6 +72,7 @@ config TRUSTED_KEYS_PKWM
bool "PKWM-based trusted keys"
depends on PSERIES_PLPKS >= TRUSTED_KEYS
default y
+ select HAVE_TRUSTED_KEYS_DEBUG
select HAVE_TRUSTED_KEYS
help
Enable use of IBM PowerVM Key Wrapping Module (PKWM) as a trusted key backend.
diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
index 601943ce0d60..6a33dbf2a7f5 100644
--- a/security/keys/trusted-keys/trusted_caam.c
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -28,10 +28,13 @@ static const match_table_t key_tokens = {
{opt_err, NULL}
};
-#ifdef CAAM_DEBUG
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
static inline void dump_options(const struct caam_pkey_info *pkey_info)
{
- pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("key encryption algo %d\n", pkey_info->key_enc_algo);
}
#else
static inline void dump_options(const struct caam_pkey_info *pkey_info)
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0b142d941cd2..6aed17bee09d 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -31,6 +31,12 @@ static char *trusted_rng = "default";
module_param_named(rng, trusted_rng, charp, 0);
MODULE_PARM_DESC(rng, "Select trusted key RNG");
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
+bool trusted_debug;
+module_param_named(debug, trusted_debug, bool, 0);
+MODULE_PARM_DESC(debug, "Enable trusted keys debug traces (default: 0)");
+#endif
+
static char *trusted_key_source;
module_param_named(source, trusted_key_source, charp, 0);
MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam, dcp or pkwm)");
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 6ea728f1eae6..13513819991e 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -46,38 +46,44 @@ enum {
SRK_keytype = 4
};
-#define TPM_DEBUG 0
-
-#if TPM_DEBUG
+#ifdef CONFIG_TRUSTED_KEYS_DEBUG
static inline void dump_options(struct trusted_key_options *o)
{
- pr_info("sealing key type %d\n", o->keytype);
- pr_info("sealing key handle %0X\n", o->keyhandle);
- pr_info("pcrlock %d\n", o->pcrlock);
- pr_info("pcrinfo %d\n", o->pcrinfo_len);
- print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
- 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
+ if (!trusted_debug)
+ return;
+
+ pr_debug("sealing key type %d\n", o->keytype);
+ pr_debug("sealing key handle %0X\n", o->keyhandle);
+ pr_debug("pcrlock %d\n", o->pcrlock);
+ pr_debug("pcrinfo %d\n", o->pcrinfo_len);
+ print_hex_dump_debug("pcrinfo ", DUMP_PREFIX_NONE,
+ 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
}
static inline void dump_sess(struct osapsess *s)
{
- print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
- 16, 1, &s->handle, 4, 0);
- pr_info("secret:\n");
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
- 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
- pr_info("trusted-key: enonce:\n");
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
- 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
+ if (!trusted_debug)
+ return;
+
+ print_hex_dump_debug("trusted-key: handle ", DUMP_PREFIX_NONE,
+ 16, 1, &s->handle, 4, 0);
+ pr_debug("secret:\n");
+ print_hex_dump_debug("", DUMP_PREFIX_NONE,
+ 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
+ pr_debug("trusted-key: enonce:\n");
+ print_hex_dump_debug("", DUMP_PREFIX_NONE,
+ 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
}
static inline void dump_tpm_buf(unsigned char *buf)
{
int len;
- pr_info("\ntpm buffer\n");
+ if (!trusted_debug)
+ return;
+ pr_debug("\ntpm buffer\n");
len = LOAD32(buf, TPM_SIZE_OFFSET);
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
+ print_hex_dump_debug("", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
}
#else
static inline void dump_options(struct trusted_key_options *o)
--
2.39.5
^ permalink raw reply related
* [PATCH] ima: Use KEXEC_SIG_FORCE for rejecting unsigned kexec images
From: Chi Wang @ 2026-04-15 10:23 UTC (permalink / raw)
To: zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg
Cc: paul, jmorris, serge, linux-integrity, linux-security-module,
linux-kernel, Chi Wang
From: Chi Wang <wangchi@kylinos.cn>
Following the split of KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE,
only KEXEC_SIG_FORCE indicates that unsigned kernel images must be rejected.
KEXEC_SIG alone enables signature verification but permits unsigned images,
so it should not trigger the IMA appraisal denial for kexec_load.
Update the condition in ima_load_data() to check for KEXEC_SIG_FORCE
instead of KEXEC_SIG.
Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
Signed-off-by: Chi Wang <wangchi@kylinos.cn>
---
security/integrity/ima/ima_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 1d6229b156fb..ec70e78ab8cd 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -953,7 +953,7 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
switch (id) {
case LOADING_KEXEC_IMAGE:
- if (IS_ENABLED(CONFIG_KEXEC_SIG)
+ if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)
&& arch_ima_get_secureboot()) {
pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
return -EACCES;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] tpm: aovid -Wunused-but-set-variable
From: Jarkko Sakkinen @ 2026-04-15 2:48 UTC (permalink / raw)
To: Thorsten Blum
Cc: Arnd Bergmann, Matthew Garrett, Bartosz Szczepanek,
Ard Biesheuvel, Arnd Bergmann, Peter Huewe, Jason Gunthorpe,
linux-integrity, linux-kernel
In-Reply-To: <adwroOsSnGrGi5OM@linux.dev>
On Mon, Apr 13, 2026 at 01:32:48AM +0200, Thorsten Blum wrote:
> On Fri, Mar 22, 2024 at 02:22:48PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Outside of the EFI tpm code, the TPM_MEMREMAP()/TPM_MEMUNMAP functions are
> > defined as trivial macros, leading to the mapping_size variable ending
> > up unused:
> >
> > In file included from drivers/char/tpm/tpm-sysfs.c:16:
> > In file included from drivers/char/tpm/tpm.h:28:
> > include/linux/tpm_eventlog.h:167:6: error: variable 'mapping_size' set but not used [-Werror,-Wunused-but-set-variable]
> > 167 | int mapping_size;
> >
> > Turn the stubs into inline functions to avoid this warning.
> >
> > Fixes: c46f3405692d ("tpm: Reserve the TPM final events table")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > include/linux/tpm_eventlog.h | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> > index 7d68a5cc5881..6e5be15029fb 100644
> > --- a/include/linux/tpm_eventlog.h
> > +++ b/include/linux/tpm_eventlog.h
> > @@ -131,11 +131,16 @@ struct tcg_algorithm_info {
> > };
> >
> > #ifndef TPM_MEMREMAP
> > -#define TPM_MEMREMAP(start, size) NULL
> > +static inline void *TPM_MEMREMAP(unsigned long start, size_t size)
> > +{
> > + return NULL;
> > +}
> > #endif
> >
> > #ifndef TPM_MEMUNMAP
> > -#define TPM_MEMUNMAP(start, size) do{} while(0)
> > +static inline void TPM_MEMUNMAP(void *mapping, size_t size)
> > +{
> > +}
> > #endif
> >
> > /**
>
> I just stumbled upon the same problem and found this patch from 2024,
> which still applies. I cc'ed the current maintainers - maybe someone can
> pick this up? Thanks!
>
> Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev>
Thanks.
Arnd, I fixed typo in short summary and applied with that modification.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] trusted-keys: move pr_fmt out of trusted-type.h
From: Jarkko Sakkinen @ 2026-04-15 2:44 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Marco Felsch, Josh Snyder, James Bottomley, Mimi Zohar,
David Howells, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20e9f021-f6b3-4e19-9e1b-93b1e00eb803@pengutronix.de>
On Mon, Apr 13, 2026 at 01:03:30PM +0200, Ahmad Fatoum wrote:
> Hi,
>
> On 4/13/26 1:01 PM, Marco Felsch wrote:
> > Hi Josh,
> >
> > On 26-04-11, Josh Snyder wrote:
> >> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> >> prefix into every translation unit that transitively includes
> >> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
> >>
> >> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
> >>
> >> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> >> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> >> addition, so the regression has been live from the moment the header
> >> gained its own pr_fmt definition.
> >>
> >> Move the pr_fmt definition into the trusted-keys source files that
> >> actually want the prefix.
> >>
> >> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> >> Assisted-by: Claude:claude-opus-4-6
> >> Signed-off-by: Josh Snyder <josh@code406.com>
> >> ---
> >> include/keys/trusted-type.h | 6 ------
> >> security/keys/trusted-keys/trusted_caam.c | 2 ++
> >> security/keys/trusted-keys/trusted_core.c | 2 ++
> >> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> >> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> >> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
> >> 7 files changed, 12 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> >> index 03527162613f7..54da1f174aeab 100644
> >> --- a/include/keys/trusted-type.h
> >> +++ b/include/keys/trusted-type.h
> >> @@ -11,12 +11,6 @@
> >> #include <linux/rcupdate.h>
> >> #include <linux/tpm.h>
> >>
> >> -#ifdef pr_fmt
> >> -#undef pr_fmt
> >> -#endif
> >> -
> >> -#define pr_fmt(fmt) "trusted_key: " fmt
> >> -
> >> #define MIN_KEY_SIZE 32
> >> #define MAX_KEY_SIZE 128
> >> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> >> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> >> index 601943ce0d60f..a31fd89c0e5c5 100644
> >> --- a/security/keys/trusted-keys/trusted_caam.c
> >> +++ b/security/keys/trusted-keys/trusted_caam.c
> >> @@ -4,6 +4,8 @@
> >> * Copyright 2025 NXP
> >> */
> >>
> >> +#define pr_fmt(fmt) "trusted_key: " fmt
> >
> > Can we adapt this patch further to include the trusted-key type as well?
> > E.g. 'trusted_key-caam'.
>
> Agreed, if we move it into the individual files, we can use the occasion
> to make it a bit more descriptive.
>
> I would suggest "trusted_key: caam: ", so the prefix stays the same.
>
> Cheers,
> Ahmad
+1
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 0/2] tpm_tis: fix retry exhaustion and add logging
From: Jarkko Sakkinen @ 2026-04-15 2:40 UTC (permalink / raw)
To: Jacqueline Wong; +Cc: linux-integrity, peterhuewe, jgg, axelrasmussen
In-Reply-To: <20260411003300.1823020-1-jacqwong@google.com>
On Sat, Apr 11, 2026 at 12:32:58AM +0000, Jacqueline Wong wrote:
> The Fix:
> - Patch 1: Adds error logs to identify the specific hardware status mismatch.
> - Patch 2: Stops execution immediately when retries are exhausted.
>
> v2 changes:
> - Split logging and logic into separate patches.
> - Added retry count to the error message.
> - Included dmesg traces below.
>
> Testing:
> Dmesg traces obtained using error injection to simulate status register mismatches.
>
> Before:
> [ 130.288751] tpm tpm0: Operation Timed out
> [ 250.306070] tpm tpm0: Operation Timed out
> [ 250.310173] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts
>
> After:
> [ 10.271547] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
> ...
> [ 10.646283] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
> [ 10.653461] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
> [ 10.659304] tpm tpm0: tpm_try_transmit: send(): error -5
> [ 10.665435] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
> ...
> [ 11.037198] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
> [ 11.044441] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
> [ 11.050288] tpm tpm0: tpm_try_transmit: send(): error -5
> [ 11.055723] tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
>
> Jacqueline Wong (2):
> tpm: tpm_tis: add error logging for data transfer
> tpm: tpm_tis: stop transmit if retries are exhausted
>
> drivers/char/tpm/tpm_tis_core.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
OK, I dropped the patch that as I applied as I did not see this :-)
Now that we are cycling, please send v3 with checkpatch --strict passing
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] tpm_tis: Check for an error after exhausting send retires
From: Jarkko Sakkinen @ 2026-04-15 2:38 UTC (permalink / raw)
To: Jacqueline Wong
Cc: peterhuewe, jgg, Alexander.Steffen, linux-integrity, linux-kernel,
axelrasmussen, Jordan Hand
In-Reply-To: <20260410211350.1132611-1-jacqwong@google.com>
On Fri, Apr 10, 2026 at 09:13:50PM +0000, Jacqueline Wong wrote:
> From: Jordan Hand <jhand@google.com>
>
> tpm_tis_send_main() will attempt to retry sending data TPM_RETRY times.
> Currently, if those retries are exhausted, the driver will attempt to
> call execute. The TPM will be in the wrong state, leading to the
> operation simply timing out.
>
> Instead, if there is still an error after retries are exhausted, return
> that error immediately.
>
> Additionally, add logging to more easily determine reason for transmit
> failure.
>
> Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors")
> Signed-off-by: Jordan Hand <jhand@google.com>
> ---
> drivers/char/tpm/tpm_tis_core.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index e2a1769081b1..b78937841879 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -471,6 +471,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
> status = tpm_tis_status(chip);
> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
> rc = -EIO;
> + dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be set. sts = 0x%08x\n",
> + status);
> goto out_err;
> }
> }
> @@ -491,6 +493,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
> status = tpm_tis_status(chip);
> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
> rc = -EIO;
> + dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be unset. sts = 0x%08x\n",
> + status);
> goto out_err;
> }
>
> @@ -552,11 +556,16 @@ static int tpm_tis_send_main(struct tpm_chip *chip, const u8 *buf, size_t len)
> break;
> else if (rc != -EAGAIN && rc != -EIO)
> /* Data transfer failed, not recoverable */
> - return rc;
> + goto out_err;
>
> usleep_range(priv->timeout_min, priv->timeout_max);
> }
>
> + if (rc == -EAGAIN || rc == -EIO) {
> + dev_err(&chip->dev, "Exhausted tpm_tis_send_data retries\n");
> + goto out_err;
> + }
> +
> /* go and do it */
> rc = tpm_tis_write8(priv, TPM_STS(priv->locality), TPM_STS_GO);
> if (rc < 0)
> --
> 2.53.0.1213.gd9a14994de-goog
>
CHECK: Alignment should match open parenthesis
#35: FILE: drivers/char/tpm/tpm_tis_core.c:475:
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be set. sts = 0x%08x\n",
+ status);
CHECK: Alignment should match open parenthesis
#44: FILE: drivers/char/tpm/tpm_tis_core.c:497:
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be unset. sts = 0x%08x\n",
+ status);
I fixed these manually.
Good catch, thanks:
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Applied.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v1] tpm: restore timeout for key creation commands
From: Jarkko Sakkinen @ 2026-04-15 2:31 UTC (permalink / raw)
To: Baoli.Zhang
Cc: Peter Huewe, Jason Gunthorpe, Serge Hallyn, lili . li,
linux-integrity, linux-kernel
In-Reply-To: <20260410014940.3557934-1-baoli.zhang@linux.intel.com>
On Fri, Apr 10, 2026 at 09:49:39AM +0800, Baoli.Zhang wrote:
> After the per-command duration map was introduced, TPM2 key creation
> commands (`CREATE_PRIMARY`, `CREATE`, `CREATE_LOADED`) were limited to
> 30 seconds.
>
> On some platforms this is not sufficient and key creation can time out.
> Commit 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()")
> inadvertently reduced these command timeouts from 300 seconds to 30
> seconds. Restore them to 300 seconds to avoid spurious failures.
Is this like pre-silicon (FPGA) type of situation? I have doubts these
latencies happening on ASIC.
If it is pre-release hardware, maybe there should be option to extend
the delay, or does this happen on actual production hardware?
Just want to understand this better...
>
> Fixes: 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()")
>
Extra empty line.
> Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com>
> Co-developed-by: lili.li <lili.li@intel.com>
"Co-developed-by: states that the patch was co-created by several
developers; it is a used to give attribution to co-authors (in addition
to the author attributed by the From: tag) when multiple people work on
a single patch. Every Co-developed-by: must be immediately followed by a
Signed-off-by: of the associated co-author. Details and examples can be
found in Documentation/process/submitting-patches.rst." [1]
[1] https://docs.kernel.org/process/5.Posting.html
> ---
> drivers/char/tpm/tpm2-cmd.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index 3a77be7ebf4aa..430022f695f24 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -71,9 +71,9 @@ static const struct {
> {TPM2_CC_HIERARCHY_CHANGE_AUTH, 2000},
> {TPM2_CC_GET_CAPABILITY, 750},
> {TPM2_CC_NV_READ, 2000},
> - {TPM2_CC_CREATE_PRIMARY, 30000},
> - {TPM2_CC_CREATE, 30000},
> - {TPM2_CC_CREATE_LOADED, 30000},
> + {TPM2_CC_CREATE_PRIMARY, 300000},
> + {TPM2_CC_CREATE, 300000},
> + {TPM2_CC_CREATE_LOADED, 300000},
> };
>
> /**
> --
> 2.43.0
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Use kfree_sensitive() to free auth session in tpm_dev_release()
From: Jarkko Sakkinen @ 2026-04-15 2:22 UTC (permalink / raw)
To: Gunnar Kudrjavets
Cc: peterhuewe, jgg, James.Bottomley, ardb, linux-integrity,
linux-kernel, Justinien Bouron
In-Reply-To: <20260409172108.11600-1-gunnarku@amazon.com>
On Thu, Apr 09, 2026 at 05:20:54PM +0000, Gunnar Kudrjavets wrote:
> tpm_dev_release() uses plain kfree() to free chip->auth, which contains
> sensitive cryptographic material including HMAC session keys, nonces,
> and passphrase data (struct tpm2_auth).
>
> Every other code path that frees this structure uses kfree_sensitive()
> to zero the memory before releasing it: both tpm2_end_auth_session()
> and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path
> is the only one that does not, leaving key material in freed slab
> memory until it is eventually overwritten.
>
> Use kfree_sensitive() for consistency with the rest of the driver and
> to ensure session keys are scrubbed during device teardown.
>
> Fixes: 699e3efd6c64 ("tpm: Add HMAC session start and end functions")
> Signed-off-by: Gunnar Kudrjavets <gunnarku@amazon.com>
> Reviewed-by: Justinien Bouron <jbouron@amazon.com>
> ---
> drivers/char/tpm/tpm-chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 082b910ddf0d..17d9d71774ec 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -247,7 +247,7 @@ static void tpm_dev_release(struct device *dev)
> kfree(chip->work_space.context_buf);
> kfree(chip->work_space.session_buf);
> #ifdef CONFIG_TCG_TPM2_HMAC
> - kfree(chip->auth);
> + kfree_sensitive(chip->auth);
> #endif
> kfree(chip);
> }
>
> base-commit: 03e5553f5fb99cb47c315e167a604a9c69e6f724
> --
> 2.47.3
>
Applied.
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [RFC PATCH 00/10] Fix dm-ima bugs
From: Mimi Zohar @ 2026-04-15 2:06 UTC (permalink / raw)
To: Mike Snitzer, Benjamin Marzinski
Cc: Mikulas Patocka, dm-devel, linux-integrity, Roberto Sassu,
Dmitry Kasatkin, Lakshmi Ramasubramanian, steven chen
In-Reply-To: <ad51kuxJuU84Amep@kernel.org>
[Cc: Lakshmi Ramasubramanian, steven chen]
On Tue, 2026-04-14 at 13:12 -0400, Mike Snitzer wrote:
> On Mon, Apr 13, 2026 at 08:22:34PM -0400, Benjamin Marzinski wrote:
> > The dm-ima code does not guarantee that the dm_ima_measure_on_*
> > functions will not be called at the same time. Since they modify and
> > free shared memory, this can lead to Use-After-Free errors or garbage
> > measurements. Further, they don't make sure that the state they measure
> > corresponds to the actual device state. For instance if table_load()
> > runs at the same time as do_resume() on a table swap,
> > dm_ima_measure_on_device_resume() can end up thinking the wrong table is
> > active. Or a concurrent dm_hash_rename() and a table swap, can end up
> > with a the new active table still using the old name. This patchset
> > makes sure the the dm-ima function are serialized and report the correct
> > device state.
> >
> > However, the code is still messier that in could be. This is because
> > it duplicates the current measurement events and format. I would really
> > like to know if that is necessary. Specifically, it currently measures
> > the following dm device and table actions:
> >
> > load
> > clear
> > rename
> > resume
> > remove
> >
> > I don't see the benefit of reporting changes to the inactive table, or
> > resumes where the device does not change state. From the user's point of
> > view, the device is still the same after these events. At the same
> > time, it doesn't measure device creates if no table was loaded, so you
> > can have situations where the the first measurement for a device is a
> > rename or a remove. A more sensible set of actions to measure would be:
> >
> > create
> > table_swap
> > rename
> > remove
> >
> > Also, the measurement format doesn't map well to how dm device's are
> > actually set up, in a way that makes it harder for the code and records
> > extraneous information. First, like I mentioned before, I don't see the
> > benefit of measuring the inactive table. Second, the name, uuid, and
> > major/minor numbers are properties of the device, not it's table (and dm
> > devices can't have partitions, so the minor count will always be 1). I
> > don't see a reason to store and occasinally log this information twice,
> > if there is an active and incative table, and it forces extra
> > coordination between the dm_ima_measure_on_* functions.
> >
> > I'm wondering it we are stuck with the current events and format, now
> > that this has been released? Or could we bump the version, and change
> > what events we measure, and how we format the output?
> >
> > Benjamin Marzinski (10):
> > dm-ima: remove dm_ima_reset_data()
> > dm-ima: remove broken last_target_measured logic
> > dm-ima: Remove status_flags from dm_ima_measure_on_table_load()
> > dm-ima: don't copy the active table to the inactive table
> > dm-ima: Fix UAF errors and measuring incorrect context
> > dm-ima: remove new_map from dm_ima_measure_on_device_clear
> > dm-ima: Fix issues with dm_ima_measure_on_device_rename
> > dm-ima: Handle race between rename and table swap
> > dm-ima: Fail more gracefully in dm_ima_measure_on_*
> > dm-ima: use active table's size if available
> >
> > drivers/md/dm-ima.c | 506 +++++++++++++++++++-----------------------
> > drivers/md/dm-ima.h | 67 ++++--
> > drivers/md/dm-ioctl.c | 146 +++++++++++-
> > drivers/md/dm.c | 2 +-
> > 4 files changed, 421 insertions(+), 300 deletions(-)
>
> Pretty extensive changes needed here all things considered.
>
> SO I'm aware, who is using dm-ima? I see that Tushar Sugandhi is no
> longer at Microsoft and so he isn't cc'd on these changes. I can
> infer from Cc some potential users, but I just want to make sure this
> code isn't just technical debt that we're having to carry in DM now?
>
> Thanks,
> Mike
^ permalink raw reply
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Mimi Zohar @ 2026-04-15 2:01 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-3-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Add support for sigv3 signature verification using ML-DSA in pure mode.
> When a sigv3 signature is verified, first check whether the key to use
> for verification is an ML-DSA key and therefore uses a hashless signature
> verification scheme. The hashless signature verification method uses the
> ima_file_id structure directly for signature verification rather than
> its digest.
>
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
Thanks, Stefan.
> ---
> v2: Set hash_algo in public_key_signature to "none"
> ---
> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
> 1 file changed, 79 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index e29ed73f15cd..c80cb2b117a6 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
> return rc;
> }
>
> +/*
kernel-doc starts with "/**".
> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
> + * @key: The key to use for signature verification
> + * @pk: The associated public key
> + * @encoding: The encoding the key type uses
> + * @sig: The signature
> + * @siglen: The length of the xattr signature
> + * @algo: The hash algorithm
> + * @digest: The file digest
> + *
> + * Create an ima_file_id structure and use it for signature verification
> + * directly. This can be used for ML-DSA in pure mode for example.
Like the comments on 1/2, please add a comment here indicating that all callers
must verify the signature length (siglen) and the public key (pk) is not NULL,
before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
must free the key.
> + */
> +static int asymmetric_verify_v3_hashless(struct key *key,
> + const struct public_key *pk,
> + const char *encoding,
> + const char *sig, int siglen,
> + u8 algo,
> + const u8 *digest)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + struct ima_file_id file_id = {
> + .hash_type = hdr->type,
> + .hash_algorithm = algo,
> + };
> + size_t digest_size = hash_digest_size[algo];
Defer initializing the digest_size and .m_size, below, until after checking the
hash algorithm is valid.
> + struct public_key_signature pks = {
> + .m = (u8 *)&file_id,
> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
> + .s = hdr->sig,
> + .s_size = siglen - sizeof(*hdr),
> + .pkey_algo = pk->pkey_algo,
> + .hash_algo = "none",
> + .encoding = encoding,
> + };
> + int ret;
> +
> + if (hdr->type != IMA_VERITY_DIGSIG &&
> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
> + return -EINVAL;
> +
> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
> + return -EBADMSG;
> +
> + memcpy(file_id.hash, digest, digest_size);
First check the hash algorithm is valid, before using digest_size.
> +
> + ret = verify_signature(key, &pks);
> + pr_debug("%s() = %d\n", __func__, ret);
> + return ret;
> +}
> +
> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
> const char *data, int datalen, u8 algo)
> {
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> struct ima_max_digest_data hash;
> + const struct public_key *pk;
> + struct key *key;
> int rc;
>
> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> - if (rc)
> - return -EINVAL;
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
>
> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
> - hash.hdr.length);
> + pk = asymmetric_key_public_key(key);
Please add a test to check that 'pk' isn't null.
> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
> + sig, siglen, algo, data);
> + } else {
> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
> + if (rc) {
> + rc = -EINVAL;
> + goto err_exit;
> + }
> +
> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
> + hash.hdr.length);
> + }
> +
> +err_exit:
Normally a label named 'err*' would be preceded by a return. Here, the label
"err_exit" is always called, not only when there is an error. Please rename the
label to something more appropriate - out, cleanup, etc.
> + key_put(key);
> +
> + return rc;
> }
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Mimi Zohar @ 2026-04-15 2:00 UTC (permalink / raw)
To: Stefan Berger, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <20260408174154.139606-2-stefanb@linux.ibm.com>
On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
> Refactor asymmetric_verify for reusability. Have it call
> asymmetric_verify_common with the signature verification key and the
> public_key structure as parameters. sigv3 support for ML-DSA will need to
> check the public key type first to decide how to do the signature
> verification and therefore will have these parameters available for
> calling asymmetric_verify_common.
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Thanks, Stefan.
> ---
> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index 6e68ec3becbd..e29ed73f15cd 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
> return key;
> }
>
> -int asymmetric_verify(struct key *keyring, const char *sig,
> - int siglen, const char *data, int datalen)
> +static int asymmetric_verify_common(const struct key *key,
> + const struct public_key *pk,
> + const char *sig, int siglen,
> + const char *data, int datalen)
> {
> - struct public_key_signature pks;
> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> - const struct public_key *pk;
> - struct key *key;
> + struct public_key_signature pks;
> int ret;
>
> - if (siglen <= sizeof(*hdr))
> - return -EBADMSG;
> -
> siglen -= sizeof(*hdr);
Normally kernel-doc is unnecessary for static functions. Here, however, since
only the caller verifies the signature length, there should be a kernel-doc
function definition. It should indicate that all callers must verify the
signature length (siglen) and that the public key (pk) is not NULL, before
calling asymmetric_verify_common().
>
> if (siglen != be16_to_cpu(hdr->sig_size))
> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> if (hdr->hash_algo >= HASH_ALGO__LAST)
> return -ENOPKG;
>
> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> - if (IS_ERR(key))
> - return PTR_ERR(key);
> -
> memset(&pks, 0, sizeof(pks));
>
> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>
> - pk = asymmetric_key_public_key(key);
> pks.pkey_algo = pk->pkey_algo;
> if (!strcmp(pk->pkey_algo, "rsa")) {
> pks.encoding = "pkcs1";
> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> pks.s_size = siglen;
> ret = verify_signature(key, &pks);
> out:
> - key_put(key);
The kernel-doc function definition should also indicate that the caller must
free the key.
> pr_debug("%s() = %d\n", __func__, ret);
> return ret;
> }
>
> +int asymmetric_verify(struct key *keyring, const char *sig,
> + int siglen, const char *data, int datalen)
> +{
> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
> + const struct public_key *pk;
> + struct key *key;
> + int ret;
> +
> + if (siglen <= sizeof(*hdr))
> + return -EBADMSG;
> +
> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
> + if (IS_ERR(key))
> + return PTR_ERR(key);
> + pk = asymmetric_key_public_key(key);
Please add a test here making sure pk is not null.
thanks,
Mimi
> +
> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
> +
> + key_put(key);
> +
> + return ret;
> +}
> +
> /*
> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
> * @type: xattr type [enum evm_ima_xattr_type]
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:05 UTC (permalink / raw)
To: Nayna Jain
Cc: linux-integrity, keyrings, Srish Srinivasan, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <129b137c-be9b-4b01-824f-beec7111377c@linux.ibm.com>
On Sun, Apr 12, 2026 at 02:47:20PM -0400, Nayna Jain wrote:
>
> On 4/9/26 12:07 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
>
> Thanks Jarkko. Additional changes looks good to me. I just realized that the
> kernel command-line parameters document may need to be updated to include
> these parameters.
Good point. I will bake that to my PR version of patch. It's low risk as
per corrateral damage. Thanks for pointing this out.
>
> Apart from that, feel free to add my
>
> Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
Thank you! These defines have been a huge itch for me for a while :-)
>
> Thanks & Regards,
>
> - Nayna
>
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: Debugging as a feature
From: Jarkko Sakkinen @ 2026-04-15 0:03 UTC (permalink / raw)
To: Srish Srinivasan
Cc: linux-integrity, keyrings, Nayna Jain, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
linux-kernel, linux-security-module
In-Reply-To: <05c9a2c3-8077-4a1c-87f8-4e240ee1e5c4@linux.ibm.com>
On Fri, Apr 10, 2026 at 11:03:58PM +0530, Srish Srinivasan wrote:
>
> On 4/9/26 9:37 PM, Jarkko Sakinen wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> > feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> > keys, and use it to replace these ad-hoc feature flags.
> >
> > Given that trusted keys debug dumps can contain sensitive data, harden the
> > feature as follows:
> >
> > 1. In the Kconfig description postulate that pr_debug() statements must be
> > used.
> > 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> > 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> > activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
> >
> > Traces, when actually needed, can be easily enabled by providing
> > trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
> >
> > Cc: Srish Srinivasan <ssrish@linux.ibm.com>
> > Reported-by: Nayna Jain <nayna@linux.ibm.com>
> > Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
>
> Tested on PKWM and emulated TPM backends.
>
> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
Thank you!
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] tpm2-sessions: Fix missing tpm_buf_destroy() in tpm2_read_public()
From: Jarkko Sakkinen @ 2026-04-15 0:00 UTC (permalink / raw)
To: Gunnar Kudrjavets
Cc: peterhuewe, jgg, noodles, linux-integrity, linux-kernel,
Justinien Bouron
In-Reply-To: <20260408164359.24968-1-gunnarku@amazon.com>
On Wed, Apr 08, 2026 at 04:43:37PM +0000, Gunnar Kudrjavets wrote:
> tpm2_read_public() calls tpm_buf_init() but fails to call
> tpm_buf_destroy() on two exit paths, leaking a page allocation:
>
> 1. When name_size() returns an error (unrecognized hash algorithm),
> the function returns directly without destroying the buffer.
>
> 2. On the success path, the buffer is never destroyed before
> returning.
>
> All other error paths in the function correctly call
> tpm_buf_destroy() before returning.
>
> Fix both by adding the missing tpm_buf_destroy() calls.
>
> Fixes: bda1cbf73c6e ("tpm2-sessions: Fix tpm2_read_public range checks")
> Signed-off-by: Gunnar Kudrjavets <gunnarku@amazon.com>
> Reviewed-by: Justinien Bouron <jbouron@amazon.com>
> ---
> drivers/char/tpm/tpm2-sessions.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> index 09df6353ef04..f7c6c043fef4 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -203,8 +203,10 @@ static int tpm2_read_public(struct tpm_chip *chip, u32 handle, void *name)
> rc = tpm_buf_read_u16(&buf, &offset);
> name_size_alg = name_size(&buf.data[offset]);
>
> - if (name_size_alg < 0)
> + if (name_size_alg < 0) {
> + tpm_buf_destroy(&buf);
> return name_size_alg;
> + }
>
> if (rc != name_size_alg) {
> tpm_buf_destroy(&buf);
> @@ -217,6 +219,7 @@ static int tpm2_read_public(struct tpm_chip *chip, u32 handle, void *name)
> }
>
> memcpy(name, &buf.data[offset], rc);
> + tpm_buf_destroy(&buf);
> return name_size_alg;
> }
> #endif /* CONFIG_TCG_TPM2_HMAC */
>
> base-commit: 03e5553f5fb99cb47c315e167a604a9c69e6f724
> --
> 2.47.3
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Applied.
BR, Jarkko
^ permalink raw reply
* Re: [RFC PATCH 00/10] Fix dm-ima bugs
From: Benjamin Marzinski @ 2026-04-14 18:35 UTC (permalink / raw)
To: Mike Snitzer
Cc: Mikulas Patocka, dm-devel, linux-integrity, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin
In-Reply-To: <ad51kuxJuU84Amep@kernel.org>
On Tue, Apr 14, 2026 at 01:12:50PM -0400, Mike Snitzer wrote:
> On Mon, Apr 13, 2026 at 08:22:34PM -0400, Benjamin Marzinski wrote:
> > The dm-ima code does not guarantee that the dm_ima_measure_on_*
> > functions will not be called at the same time. Since they modify and
> > free shared memory, this can lead to Use-After-Free errors or garbage
> > measurements. Further, they don't make sure that the state they measure
> > corresponds to the actual device state. For instance if table_load()
> > runs at the same time as do_resume() on a table swap,
> > dm_ima_measure_on_device_resume() can end up thinking the wrong table is
> > active. Or a concurrent dm_hash_rename() and a table swap, can end up
> > with a the new active table still using the old name. This patchset
> > makes sure the the dm-ima function are serialized and report the correct
> > device state.
> >
> > However, the code is still messier that in could be. This is because
> > it duplicates the current measurement events and format. I would really
> > like to know if that is necessary. Specifically, it currently measures
> > the following dm device and table actions:
> >
> > load
> > clear
> > rename
> > resume
> > remove
> >
> > I don't see the benefit of reporting changes to the inactive table, or
> > resumes where the device does not change state. From the user's point of
> > view, the device is still the same after these events. At the same
> > time, it doesn't measure device creates if no table was loaded, so you
> > can have situations where the the first measurement for a device is a
> > rename or a remove. A more sensible set of actions to measure would be:
> >
> > create
> > table_swap
> > rename
> > remove
> >
> > Also, the measurement format doesn't map well to how dm device's are
> > actually set up, in a way that makes it harder for the code and records
> > extraneous information. First, like I mentioned before, I don't see the
> > benefit of measuring the inactive table. Second, the name, uuid, and
> > major/minor numbers are properties of the device, not it's table (and dm
> > devices can't have partitions, so the minor count will always be 1). I
> > don't see a reason to store and occasinally log this information twice,
> > if there is an active and incative table, and it forces extra
> > coordination between the dm_ima_measure_on_* functions.
> >
> > I'm wondering it we are stuck with the current events and format, now
> > that this has been released? Or could we bump the version, and change
> > what events we measure, and how we format the output?
> >
> > Benjamin Marzinski (10):
> > dm-ima: remove dm_ima_reset_data()
> > dm-ima: remove broken last_target_measured logic
> > dm-ima: Remove status_flags from dm_ima_measure_on_table_load()
> > dm-ima: don't copy the active table to the inactive table
> > dm-ima: Fix UAF errors and measuring incorrect context
> > dm-ima: remove new_map from dm_ima_measure_on_device_clear
> > dm-ima: Fix issues with dm_ima_measure_on_device_rename
> > dm-ima: Handle race between rename and table swap
> > dm-ima: Fail more gracefully in dm_ima_measure_on_*
> > dm-ima: use active table's size if available
> >
> > drivers/md/dm-ima.c | 506 +++++++++++++++++++-----------------------
> > drivers/md/dm-ima.h | 67 ++++--
> > drivers/md/dm-ioctl.c | 146 +++++++++++-
> > drivers/md/dm.c | 2 +-
> > 4 files changed, 421 insertions(+), 300 deletions(-)
>
> Pretty extensive changes needed here all things considered.
>
> SO I'm aware, who is using dm-ima? I see that Tushar Sugandhi is no
> longer at Microsoft and so he isn't cc'd on these changes. I can
> infer from Cc some potential users, but I just want to make sure this
> code isn't just technical debt that we're having to carry in DM now?
I don't actually know if anyone is. The issue is that the Use After Free
crashes can happen as long as CONFIG_IMA is set, regardless of whether
or not you have any IMA policy set.
If we don't need to care, we could just serialize the
dm_ima_measure_on_* functions to keep them from having concurrent access
to shared memory, and let them keep reporting bogus data if there are
races (or simply unfortunate orderings. load then rename then resume
currently forgets the rename, even without a race) That's a much smaller
change, and if they're currently good enough for any users, it won't
make them any worse.
-Ben
>
> Thanks,
> Mike
^ 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