test_032_dev_kmem from ubuntu_qrt_kernel_security failed on Oracular (Permission denied)

Oracular ships systemd 256 and /tmp/ is now by default a tmpfs. [1]

  On Oracular:
    $ findmnt --target /tmp/
    TARGET SOURCE FSTYPE OPTIONS
    /tmp tmpfs tmpfs rw,nosuid,nodev,size=6123876k,nr_inodes=1048576,inode64
  On Noble:
    $ findmnt --target /tmp
    TARGET
      SOURCE FSTYPE OPTIONS
    / /dev/vda1 ext4 rw,relatime,discard,errors=remount-ro,commit=30

test_032_dev_kmem runs mknod(2) to create a character device file under /tmp.
Because of the difference, on Oracular, openat(2) (by errno-read.py) returns earlier with errno 13 (Permission denied), while errno 6 (No such device) is expected.

-> vfs_open()
   [...]
   -> may_open()
     -> may_open_dev() returns 0 because of MNT_NODEV
        return -EACCES

The whole point of test_032_dev_kmem is I think to test ubuntu policy (CONFIG_DEVKMEM=n for many years before bbcd53c96071 ("drivers/char: remove /dev/kmem for good")):

-> vfs_open()
   [...]
   -> chrdev_open()
     -> memory_open()
       -> devlist[2 /*kmem*/] is empty so return -ENXIO

I'll propose an update (fix) for test_032_dev_kmem to qa-regression-testing.

[1] https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/NEWS?h=ce0abd32d7d3a&id=ce0abd32d7d3a920a7728a21a1977749db2e3776

Nice, the change makes sense to me.

Have you had a chance to test it on a variety of previous releases, too, to make sure that the test still works for older systems?

I'm surprised about the "It's worthy to note that with 6.11.0-4.4, only ARM64 has failed with this test" listed in the description. Is that a realistic assessment of the issue, or was that an initial understanding that has since been shown to be incorrect?

Thanks

Thanks for the comment.

I tested only on my local VM (Oracular,Noble,Jammy,Focal,Bionic,Xenial all amd64).

I think it was just an initial observation. My guess is that it was just because systemd was upgraded to 256 only on the ARM64 test machine back then. @cypressyew, if you have any idea, please leave a comment.
In SRU testing for Oracular 6.11.0-11.11, the same pattern of failure was observed on amd64/arm64/s390x.

Hi,

Looking back into our test history at hand from this point, for this ubuntu_qrt_kernel_security ran on our openstack cloud, we can observe that:
* 6.11.0-4.4 + Test suite HEAD SHA1: bf11077d
  - Test passed on AMD64 and PPC64EL with: /dev/kmem not available ... ok
  - Test failed on ARM64, ARM64-64k with: /tmp/kmem-..../kmem: Permission denied
* 6.11.0-5.5 + Test suite HEAD SHA1: bf11077d
  - Test failed on AMD64, ARM64, PPC64EL with: /tmp/kmem-..../kmem: Permission denied
* 6.11.0-7.7 + Test suite HEAD SHA1: 0ba379b5
  - Test failed on AMD64, ARM64, PPC64EL with: /tmp/kmem-..../kmem: Permission denied
* 6.11.0-9.9 + Test suite HEAD SHA1: 4f547131
  - Test failed on AMD64, ARM64, PPC64EL with: /tmp/kmem-..../kmem: Permission denied

So I think you can say that is our initial understanding from that time being, and it is incorrect shown to be incorrect on this point.

HTH
Thanks!