kernel-security tests fail on Wily 4.2.0-36.41

[Brad Figg]

======================================================================
FAIL: test_021_aslr_dapper_libs (__main__.KernelASLRm32Tests)
ASLR of libs
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-kernel-security.py", line 1719, in test_021_aslr_dapper_libs
    self._test_aslr('libs', expected)
  File "./test-kernel-security.py", line 1777, in _test_aslr
    super(KernelASLRm32Tests, self)._test_aslr(area, expected, use32=True)
  File "./test-kernel-security.py", line 1679, in _test_aslr
    self.assertShellExitEquals(expected, ["./aslr", area, "--verbose"])
  File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/scripts/testlib.py", line 1057, in assertShellExitEquals
    self.assertEquals(expected, rc, msg + result + report)
AssertionError: Got exit code 1, expected 0
Command: './aslr', 'libs', '--verbose'
Output:
Checking ASLR of libs:
 0x5558adf0
 0x5558adf0
 0x5558adf0
FAIL: ASLR not functional (libs always at 0x5558adf0)

[Steve Beattie (sbeattie)]

All the failing tests from the log:

test_021_aslr_dapper_libs (__main__.KernelASLRm32Tests)
ASLR of libs ... FAIL
test_021_aslr_dapper_mmap (__main__.KernelASLRm32Tests)
ASLR of mmap ... FAIL
test_022_aslr_hardy_vdso (__main__.KernelASLRm32Tests)
ASLR of vdso ... FAIL
test_021_aslr_dapper_libs (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of libs ... FAIL
test_021_aslr_dapper_mmap (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of mmap ... FAIL
test_022_aslr_hardy_vdso (__main__.KernelASLRm32_CVE_2016_3672_Tests)
ASLR of vdso ... FAIL

These tests (the gcc -m32 on amd64 versions) are all new to the QART tests in response to CVE-2016-3672, which is being addressed by the kernel in bug 1568523. The commit to fix CVE-2016-3672 (upstream 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb) was not incorporated in time for the 4.2.0-36.41 kernel.

With some hacky effort, I could adjust QART to not mark these as failures for the time being (and try to detect when they land via the kernel package changelog), but since the issue should be addressed in the next SRU cycle, I don't think this is a worthwhile effort. Do you concur?

[Steve Beattie (sbeattie)]

This was partially an error in QRT as well, and has been addressed in both places.