test_021_aslr_dapper_libs report OK but marked as failed on K-5.19 openstack PPC instance

[Po-Hsu Lin]

Issue found with K-5.19.0-41.42 on Openstack PPC instance.

Unlike bug 1983357, the test output looks OK, but the test was marked as failed.

Test log:
 Running test: './test-kernel-security.py' distro: 'Ubuntu 22.10' kernel: '5.19.0-41.42 (Ubuntu 5.19.0-41.42-generic 5.19.17)' arch: 'ppc64el' uid: 0/0 SUDO_USER: 'ubuntu')
 test_021_aslr_dapper_libs (__main__.KernelSecurityTest)
 ASLR of libs ... (default libs native) (default libs native rekey) (unlimited stack libs native) (skipped: unlimited stack aslr broken on ppc64el, skipping) FAIL

 ======================================================================
 FAIL: test_021_aslr_dapper_libs (__main__.KernelSecurityTest)
 ASLR of libs
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/./test-kernel-security.py", line 1780, in test_021_aslr_dapper_libs
     self._test_aslr('libs', expected)
   File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/./test-kernel-security.py", line 1743, in _test_aslr
     self._test_aslr_all(area, expected, "unlimited stack %s" % area)
   File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/./test-kernel-security.py", line 1720, in _test_aslr_all
     self._test_aslr_exec(area, expected, target, name)
   File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/./test-kernel-security.py", line 1713, in _test_aslr_exec
     self.assertShellExitEquals(aslr_expected, ["./%s" % (target), area, "--verbose"], msg="%s:\n" % name)
   File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1216, in assertShellExitEquals
     self.assertEqual(expected, rc, msg + result + report)
 AssertionError: 1 != 0 : unlimited stack libs native:
 Got exit code 0, expected 1
 Command: './aslr', 'libs', '--verbose'
 Output:
 Checking ASLR of libs:
     0x0024472a8a5fc0
     0x00209994ca5fc0
     0x002041d48a5fc0
 ok: ASLR of libs functional

 ----------------------------------------------------------------------
 Ran 1 test in 0.211s

 FAILED (failures=1)

[Po-Hsu Lin (cypressyew)]

A quick look into the code shows this is the problem:

if self.dpkg_arch in ['ppc64el'] and area in ['libs', 'vdso', 'mmap'] and resource.getrlimit(resource.RLIMIT_STACK) == (resource.RLIM_INFINITY, resource.RLIM_INFINITY):
            # ppc64el still has broken aslr when stack is unlimited
            # https://github.com/linuxppc/linux/issues/59
            # however, the rekey portion of the test *succeeds* so we
            # need to adjust the expected value here.
            self._skipped("unlimited stack aslr broken on ppc64el, skipping")
            aslr_expected = 1

We are expecting this test to fail on ppc64el, but it passed in this case. The mismatch makes the test fail.
I can see this failing on baremetal as well. Maybe the issue has gone? (The upstream issue https://github.com/linuxppc/issues/issues/59 has been closed as well.)

[Steve Beattie (sbeattie)]

On Thu, Apr 20, 2023 at 05:43:22AM -0000, Po-Hsu Lin wrote:
> A quick look into the code shows this is the problem:
>
> if self.dpkg_arch in ['ppc64el'] and area in ['libs', 'vdso', 'mmap'] and resource.getrlimit(resource.RLIMIT_STACK) == (resource.RLIM_INFINITY, resource.RLIM_INFINITY):
> # ppc64el still has broken aslr when stack is unlimited
> # https://github.com/linuxppc/linux/issues/59
> # however, the rekey portion of the test *succeeds* so we
> # need to adjust the expected value here.
> self._skipped("unlimited stack aslr broken on ppc64el, skipping")
> aslr_expected = 1
>
> We are expecting this test to fail on ppc64el, but it passed in this case. The mismatch makes the test fail.
> I can see this failing on baremetal as well. Maybe the issue has gone? (The upstream issue https://github.com/linuxppc/issues/issues/59 has been closed as well.)

Yes, it looks like upstream has fixed this with
https://github.com/torvalds/linux/commit/3ba4289a3e7ff4a89a78c4f74d694a344e8d9cc9
which landed in the 5.19 development cycle. We can fix that up (yay,
more special cases), but I'm wondering why we're only discovering
this failure on 5.19 now?

Thanks for highlighting this!

--
Steve Beattie
<email address hidden>

[Po-Hsu Lin (cypressyew)]

Hi Steve,
looking back into history it is start failing since 5.19.0-26.27 from sru-20221010 cycle. And yes we should be catching this.

My assumption is that this failure was undiscovered as this test is failing on other AMD64 instances (bug 1983357, and bug number needs to be corrected in the description) for a while. Until I was reviewing the test result for the newly added instances on openstack this cycle.

[Po-Hsu Lin (cypressyew)]

BTW, this is also affecting other 2 test cases on PowerPC with the same issue:
* test_021_aslr_dapper_mmap
* test_022_aslr_hardy_vdso

[Po-Hsu Lin (cypressyew)]

Patch applied, restarting tests on K/L ppc.

[Po-Hsu Lin (cypressyew)]

Test restarted, hints removed.