Re: [PATCH blktests] blktrace/001: Skip test when kernel lockdown is enabled

[Disha Goel <disgoel@linux.ibm.com>]

On 08/05/26 11:09 pm, Daniel Wagner wrote:
> On Fri, May 08, 2026 at 04:51:41PM +0530, Disha Goel wrote:
>> After further investigation, I've identified the root cause. This
>> failure is seen on SLES 16.x and RHEL 10.x with 6.12-based kernels when
>> Secure Boot is enabled (kernel lockdown active).
> 
> SLES ships an bunch of additional patches which hardens the lockdown
> feature a bit more. IIRC these are the same as RHEL uses. Not sure if
> this is the source of the problem though.
> 
> https://raw.githubusercontent.com/openSUSE/kernel-source/refs/heads/SL-16.1/series.conf
> 
> 	# Lock down functions for secure boot
> 	patches.suse/0001-security-lockdown-expose-a-hook-to-lock-the-kernel-down.patch
> 	patches.suse/lockdown-fix-kernel-lockdown-enforcement-issue-when-secure.patch
> 	patches.suse/0002-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-boot-mode.patch
> 	patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch
> 	patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch
> 
> The patches are in https://github.com/openSUSE/kernel-source/tree/SL-16.1/patches.suse

Hi Daniel,

Thank you for pointing me to the SUSE lockdown patches. After analysing
them, I found that the second patch (lockdown-fix-kernel-lockdown-
enforcement-issue-when-secure.patch) is causing the issue.

This patch fixes bsc#1237521 by directly calling lockdown hooks, but it
appears to be too restrictive - it blocks blktrace from accessing
debugfs even though upstream kernel 7.1+ allows this with lockdown enabled.

The patch works around a timing issue but has the side effect of
blocking legitimate debugging tools. Is this intentional, or should
debugging tools like blktrace be allowed even with lockdown enabled?

-- 
Regards,
Disha