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

[Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

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