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

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

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