kernel-security aslr tests failing on ppc64el and zseries

[Brad Figg]

06:44:11 ERROR| [stderr] ASLR of stack ... FAIL
06:44:11 ERROR| [stderr] test_021_aslr_dapper_libs (__main__.KernelSecurityTest)
06:44:11 ERROR| [stderr] ASLR of libs ... FAIL
06:44:11 ERROR| [stderr] test_021_aslr_dapper_mmap (__main__.KernelSecurityTest)
06:44:11 ERROR| [stderr] ASLR of mmap ... FAIL
06:44:11 ERROR| [stderr] test_022_aslr_hardy_text (__main__.KernelSecurityTest)
06:44:11 ERROR| [stderr] ASLR of text ... FAIL
06:44:11 ERROR| [stderr] test_022_aslr_hardy_vdso (__main__.KernelSecurityTest)
06:44:12 ERROR| [stderr] ASLR of vdso ... FAIL
06:44:12 ERROR| [stderr] test_022_aslr_intrepid_brk (__main__.KernelSecurityTest)
06:44:12 ERROR| [stderr] ASLR of brk ... FAIL
06:44:12 ERROR| [stderr] test_023_aslr_wily_pie (__main__.KernelSecurityTest)
06:44:12 ERROR| [stderr] ASLR of text vs libs ... FAIL

This is from:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20160617_072126@/log.gz

Note, this failure is happening for multiple series; trusty, vivid, wily and xenial. We need to determine if this is really a kernel failure or a bug in the test.

[Steve Beattie (sbeattie)]

s390 failure log: http://kernel.ubuntu.com/testing/4.4.0-25.44/s2lp4__4.4.0-25.44__2016-06-19_16-57-00/ubuntu_qrt_kernel_security/results/debug/client.DEBUG

The aslr tests are failing because COMPAT mode on s390 is 31 bits, not 32, and so needs the -m31 compiler option. I've fixed this in qrt commit 2532.

I also note the tainted kernel module test is failing due to the zfs module being loaded on the test instance. I'll look at addressing that.

[Steve Beattie (sbeattie)]

ppc64le failure log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/linux/20160620_155235@/log.gz

The aslr failures here are showing the same repeated memory layout values for the case when the stack rlimit is set to unlimited, which is a similar failure to CVE-2016-3672 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-3672.html), which was the same issue but on x86/x86_64 kernels. Looking at the relevant bits of the upstream kernel source, we can see in http://lxr.free-electrons.com/source/arch/powerpc/mm/mmap.c#L96 , when mmap_is_legacy is true (either 32 bit compat mode or unlimited stack size), an unrandomized value is used for the mmap base value.

This is not a regression per se, in that we recently expanded the aslr tests to look for CVE-2016-3672 (but on all arches).

[Steve Beattie (sbeattie)]

The zfs modules being loaded triggering the tainted module check has been addressed in qrt commit 2533.

[Steve Beattie (sbeattie)]

I've filed https://github.com/linuxppc/linux/issues/59 with the upstream linuxppc project.

[Steve Beattie (sbeattie)]

Until upstream fixes the ppc64el issue, I've marked the failures as expected for the time being in qa-r-t git commit https://git.launchpad.net/qa-regression-testing/commit/?id=57d3aa8b9b10455e9a582500e6d2bb1a61055a85 . Closing bug.