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