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

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

[Disha Goel]

The blktrace/001 test fails on systems with Secure Boot enabled due to
kernel lockdown preventing access to debugfs. The test attempts to run
blktrace which requires access to /sys/kernel/debug/block/*/trace*
files, but kernel lockdown (enabled automatically with Secure Boot)
blocks this access, resulting in "Operation not permitted" errors.

Add _have_debugfs_access() helper function to detect kernel lockdown by
checking /sys/kernel/security/lockdown for [integrity] or
[confidentiality] modes. When detected, the test now skips gracefully
with a clear message: "kernel lockdown is enabled (Secure Boot may be
active)".

Also add _have_configfs check which was missing. The test uses
_configure_null_blk() which requires configfs to be mounted at
/sys/kernel/config.

Signed-off-by: Disha Goel <disgoel@linux.ibm.com>
---
 common/rc          | 14 ++++++++++++++
 tests/blktrace/001 |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/common/rc b/common/rc
index 5350057..50d63e7 100644
--- a/common/rc
+++ b/common/rc
@@ -205,6 +205,20 @@ _have_blktrace() {
 	_have_program blktrace
 }
 
+_have_debugfs_access() {
+        # Check if kernel lockdown is preventing debugfs access
+        # This happens when Secure Boot is enabled
+        if [[ -f /sys/kernel/security/lockdown ]]; then
+                local lockdown_state
+                lockdown_state=$(cat /sys/kernel/security/lockdown 2>/dev/null)
+                if [[ "$lockdown_state" =~ \[integrity\]|\[confidentiality\] ]]; then
+                        SKIP_REASONS+=("kernel lockdown is enabled (Secure Boot may be active)")
+                        return 1
+                fi
+        fi
+        return 0
+}
+
 _have_configfs() {
 	if ! findmnt -t configfs /sys/kernel/config >/dev/null; then
 		SKIP_REASONS+=("configfs is not mounted at /sys/kernel/config")
diff --git a/tests/blktrace/001 b/tests/blktrace/001
index 2cdad02..4fe7807 100755
--- a/tests/blktrace/001
+++ b/tests/blktrace/001
@@ -22,6 +22,8 @@ requires() {
 	_have_program blkzone
 	_have_null_blk
 	_have_module_param null_blk zoned
+	_have_configfs
+        _have_debugfs_access
 }
 
 test() {
-- 
2.45.1

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

[Shin'ichiro Kawasaki]

On Apr 24, 2026 / 19:41, Disha Goel wrote:
> The blktrace/001 test fails on systems with Secure Boot enabled due to
> kernel lockdown preventing access to debugfs. The test attempts to run
> blktrace which requires access to /sys/kernel/debug/block/*/trace*
> files, but kernel lockdown (enabled automatically with Secure Boot)
> blocks this access, resulting in "Operation not permitted" errors.

Hello Disha, thanks for the patch. I tried to recreate the "Operation not
permitted" error on my test node, but I can not recreate it. I tried the
command lines below, and saw blktrace worked fine with lockdown=confidentiality
condition. This means that blktrace can access /sys/kernel/debug/block/*/trace*
even when the kernel is locked down.

---------------------------------------------------------------------
  root@testnode1:~# cat /sys/kernel/security/lockdown
  [none] integrity confidentiality
  root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
  root@testnode1:~# cat /sys/kernel/security/lockdown
  none integrity [confidentiality]
  root@testnode1:~# cd /tmp
  root@testnode1:/tmp# blktrace -d /dev/sdc &
  [1] 1014
  root@testnode1:/tmp# dd if=/dev/zero of=/dev/sdc bs=4k count=1 oflag=direct
  1+0 records in
  1+0 records out
  4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00274992 s, 1.5 MB/s
  root@testnode1:/tmp# kill 1014
  root@testnode1:/tmp# === sdc ===
    CPU  0:                    6 events,        1 KiB data
    CPU  1:                    0 events,        0 KiB data
    CPU  2:                  658 events,       31 KiB data
    CPU  3:                  797 events,       38 KiB data
    Total:                  1461 events (dropped 0),       69 KiB data
  
  [1]+  Done                       blktrace -d /dev/sdc
  root@testnode1:/tmp# blkparse -i sdc | head
    8,32   2        1     0.000000000  1048  Q  WS 0 + 8 [dd]
    8,32   2        0     0.000013242  1048 1,0  m   N bfq [bfq_limit_depth] wr_busy 0 sync 1 depth 256
    8,32   2        2     0.001495890  1048  G  WS 0 + 8 [dd]
    8,32   2        3     0.001497997  1048  P   N [dd]
    8,32   2        4     0.001499079  1048  U   N [dd] 1
    8,32   2        0     0.001574560  1048 1,0  m   N bfq0A new_ioprio 4 new_weight 40
    8,32   2        0     0.001577177  1048 1,0  m   N bfq1048S allocated
    8,32   2        0     0.001581069  1048 1,0  m   N bfq1048S get_request 00000000e21f70ba: bfqq 000000001cef6c8d, 2
    8,32   2        5     0.001583291  1048  I  WS 0 + 8 [dd]
    8,32   2        0     0.001584861  1048 1,0  m   N bfq1048S add_request 1
---------------------------------------------------------------------

I would like to understand why the blktrace error happens in your environment
and does not happen in my environment. It will affect how to judge the skip of
the test case blktrace/001.

Could you share your system set up conditions? FYI, I used Fedora 43, QEMU VM,
Intel server and v7.1-rc1 kernel for the trial above. I'm guessing any
difference between the two environments causes the blktrace behavior difference.

P.S. I found that kmemleak does not work when lockdown=confidentiality
  condition. This indicates that the kernel lockdown feature works for kmemleak
  as expected.

---------------------------------------------------------------------
root@testnode1:~# cat /sys/kernel/debug/kmemleak
root@testnode1:~# cat /sys/kernel/security/lockdown
[none] integrity confidentiality
root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
root@testnode1:~# cat /sys/kernel/security/lockdown
none integrity [confidentiality]
root@testnode1:~# cat /sys/kernel/debug/kmemleak
cat: /sys/kernel/debug/kmemleak: Operation not permitted
---------------------------------------------------------------------

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

[Disha Goel]

On 29/04/26 7:22 pm, Shin'ichiro Kawasaki wrote:
> On Apr 24, 2026 / 19:41, Disha Goel wrote:
>> The blktrace/001 test fails on systems with Secure Boot enabled due to
>> kernel lockdown preventing access to debugfs. The test attempts to run
>> blktrace which requires access to /sys/kernel/debug/block/*/trace*
>> files, but kernel lockdown (enabled automatically with Secure Boot)
>> blocks this access, resulting in "Operation not permitted" errors.
> 
> Hello Disha, thanks for the patch. I tried to recreate the "Operation not
> permitted" error on my test node, but I can not recreate it. I tried the
> command lines below, and saw blktrace worked fine with lockdown=confidentiality
> condition. This means that blktrace can access /sys/kernel/debug/block/*/trace*
> even when the kernel is locked down.
> 
> ---------------------------------------------------------------------
>    root@testnode1:~# cat /sys/kernel/security/lockdown
>    [none] integrity confidentiality
>    root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
>    root@testnode1:~# cat /sys/kernel/security/lockdown
>    none integrity [confidentiality]
>    root@testnode1:~# cd /tmp
>    root@testnode1:/tmp# blktrace -d /dev/sdc &
>    [1] 1014
>    root@testnode1:/tmp# dd if=/dev/zero of=/dev/sdc bs=4k count=1 oflag=direct
>    1+0 records in
>    1+0 records out
>    4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00274992 s, 1.5 MB/s
>    root@testnode1:/tmp# kill 1014
>    root@testnode1:/tmp# === sdc ===
>      CPU  0:                    6 events,        1 KiB data
>      CPU  1:                    0 events,        0 KiB data
>      CPU  2:                  658 events,       31 KiB data
>      CPU  3:                  797 events,       38 KiB data
>      Total:                  1461 events (dropped 0),       69 KiB data
>    
>    [1]+  Done                       blktrace -d /dev/sdc
>    root@testnode1:/tmp# blkparse -i sdc | head
>      8,32   2        1     0.000000000  1048  Q  WS 0 + 8 [dd]
>      8,32   2        0     0.000013242  1048 1,0  m   N bfq [bfq_limit_depth] wr_busy 0 sync 1 depth 256
>      8,32   2        2     0.001495890  1048  G  WS 0 + 8 [dd]
>      8,32   2        3     0.001497997  1048  P   N [dd]
>      8,32   2        4     0.001499079  1048  U   N [dd] 1
>      8,32   2        0     0.001574560  1048 1,0  m   N bfq0A new_ioprio 4 new_weight 40
>      8,32   2        0     0.001577177  1048 1,0  m   N bfq1048S allocated
>      8,32   2        0     0.001581069  1048 1,0  m   N bfq1048S get_request 00000000e21f70ba: bfqq 000000001cef6c8d, 2
>      8,32   2        5     0.001583291  1048  I  WS 0 + 8 [dd]
>      8,32   2        0     0.001584861  1048 1,0  m   N bfq1048S add_request 1
> ---------------------------------------------------------------------
> 
> I would like to understand why the blktrace error happens in your environment
> and does not happen in my environment. It will affect how to judge the skip of
> the test case blktrace/001.
> 
> Could you share your system set up conditions? FYI, I used Fedora 43, QEMU VM,
> Intel server and v7.1-rc1 kernel for the trial above. I'm guessing any
> difference between the two environments causes the blktrace behavior difference.
> 

Hi Shin'ichiro,

Thank you for the detailed testing and feedback.

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).

I tested on upstream kernel v7.1.0-rc1 with lockdown enabled, and the
test ran fine. My apologies for not testing with upstream earlier.

The issue is caused by missing debugfs fixes in the distro kernels.
I'll work with SUSE and Red Hat to get these patches backported to their 
6.12-based kernels.

I'm withdrawing this patch as it's a kernel bug, not a test framework 
issue. Thank you for the thorough review.

> P.S. I found that kmemleak does not work when lockdown=confidentiality
>    condition. This indicates that the kernel lockdown feature works for kmemleak
>    as expected.
> 
> ---------------------------------------------------------------------
> root@testnode1:~# cat /sys/kernel/debug/kmemleak
> root@testnode1:~# cat /sys/kernel/security/lockdown
> [none] integrity confidentiality
> root@testnode1:~# echo confidentiality > /sys/kernel/security/lockdown
> root@testnode1:~# cat /sys/kernel/security/lockdown
> none integrity [confidentiality]
> root@testnode1:~# cat /sys/kernel/debug/kmemleak
> cat: /sys/kernel/debug/kmemleak: Operation not permitted
> ---------------------------------------------------------------------
> 

-- 
Regards,
Disha

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

[Daniel Wagner]

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

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

[Disha Goel]

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

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

[Daniel Wagner]

Hi Disha,

On Mon, May 11, 2026 at 01:16:03PM +0530, Disha Goel wrote:
> 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.

Right, so it's a downstream problem as expected.

> 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?

I am not really involved into this part of our downstream kernel and
don't know why these patches didn't make it upstream :)

Would you mind to you create a SUSE bugzilla issue and we can figure out
a solution there?

Thanks a lot!
Daniel

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

[Shin'ichiro Kawasaki]

On May 08, 2026 / 16:51, Disha Goel wrote:
> On 29/04/26 7:22 pm, Shin'ichiro Kawasaki wrote:
[...]
> > I would like to understand why the blktrace error happens in your environment
> > and does not happen in my environment. It will affect how to judge the skip of
> > the test case blktrace/001.
> > 
> > Could you share your system set up conditions? FYI, I used Fedora 43, QEMU VM,
> > Intel server and v7.1-rc1 kernel for the trial above. I'm guessing any
> > difference between the two environments causes the blktrace behavior difference.
> > 
> 
> Hi Shin'ichiro,
> 
> Thank you for the detailed testing and feedback.
> 
> 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).
> 
> I tested on upstream kernel v7.1.0-rc1 with lockdown enabled, and the
> test ran fine. My apologies for not testing with upstream earlier.
> 
> The issue is caused by missing debugfs fixes in the distro kernels.
> I'll work with SUSE and Red Hat to get these patches backported to their
> 6.12-based kernels.
> 
> I'm withdrawing this patch as it's a kernel bug, not a test framework issue.
> Thank you for the thorough review.

No worries, and thanks to you. This patch post revealed and shared the problem,
which is great :)