Catting the SecureBoot efivar in /sys hangs

Attempting to run:
cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
hangs.

hexdump barfs:
$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
hexdump: /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c: Interrupted system call

Trying under sudo makes no difference.

stracing that cat request results in:
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd9ca513000
read(3, 0x7fd9ca514000, 131072) = -1 EINTR (Interrupted system call)
read(3, 0x7fd9ca514000, 131072) = -1 EINTR (Interrupted system call)
read(3, 0x7fd9ca514000, 131072) = -1 EINTR (Interrupted system call)
read(3, 0x7fd9ca514000, 131072) = -1 EINTR (Interrupted system call)

With that Interrupted system call just spinning repeating over and over until I stop it.

At this point, this is not a problem I can fix. It's very much tied to their hardware, and to the kernel on that hardware. This is the only instance of this I have ever seen, anywhere, over literally thousands of test runs, and it is very easily reproduced manually by simply catting the efi variable for SecureBoot, so it exists outside the test suite.

I've added a kernel task, if there's any fix to be had here, it would have to occur there.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1896119

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

after some more commentary from the customer, I'm still not convinced that this isn't related to the hardware itself, HOWEVER, while doing a bit more deubgging I noticed that the boot_mode_test.py script opens files but does not properly close them (expecting python to close them on exit?)

So while this may or may not resolve the hang that was reported when the secureboot test runs, I can at least fix this a bit so that we properly close the files after reading them.

For context, the update from the customer was that

cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

actually works fine UNTIL he runs the cert suite, after which point it hangs.

So I wonder if not properly closing the file leaves this in a bad state somehow once the script is killed with a ctrl-c...

As I said, I'm still not convinced this actually solves the issue, but we'll see. I do hope this is all the issue is.