Kernel security test 060, 072 failed on arm64 Yakkety

Bug #1653889 reported by Po-Hsu Lin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QA Regression Testing
Fix Released
Undecided
Unassigned

Bug Description

The following two test cases failed on arm64 Yakkety

test_060_nx
test_072_config_debug_set_module_ronx

======================================================================
FAIL: test_060_nx (__main__.KernelSecurityTest)
NX bit is working
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test-kernel-security.py", line 451, in test_060_nx
self.assertShellExitEquals(expected, ["./nx-test", "data"])
File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1124, in assertShellExitEquals
self.assertEqual(expected, rc, msg + result + report)
AssertionError: Got exit code -11, expected 0
Command: './nx-test', 'data'
Output:
rodata:0x401120
data: 0x4120a8
bss: 0x4220c8
brk: 0x1b23a020
rw: 0xffff94545000
rwx: 0xffff94544000
stack: 0xfffff7bcd258
Dump of /proc/self/maps:
00400000-00402000 r-xp 00000000 08:02 7736520 /home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test
00411000-00412000 r--p 00001000 08:02 7736520 /home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test
00412000-00413000 rw-p 00002000 08:02 7736520 /home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test
00413000-00423000 rw-p 00000000 00:00 0
1b239000-1b25b000 rw-p 00000000 00:00 0 [heap]
ffff943d6000-ffff94507000 r-xp 00000000 08:02 6816036 /lib/aarch64-linux-gnu/libc-2.24.so
ffff94507000-ffff94516000 ---p 00131000 08:02 6816036 /lib/aarch64-linux-gnu/libc-2.24.so
ffff94516000-ffff9451a000 r--p 00130000 08:02 6816036 /lib/aarch64-linux-gnu/libc-2.24.so
ffff9451a000-ffff9451c000 rw-p 00134000 08:02 6816036 /lib/aarch64-linux-gnu/libc-2.24.so
ffff9451c000-ffff94520000 rw-p 00000000 00:00 0

FAIL: test_072_config_debug_set_module_ronx (__main__.KernelSecurityTest)
CONFIG_DEBUG_SET_MODULE_RONX enabled
----------------------------------------------------------------------
Traceback (most recent call last):
File "./test-kernel-security.py", line 642, in test_072_config_debug_set_module_ronx
self.assertEqual(self._test_config('DEBUG_SET_MODULE_RONX'), expected)
AssertionError: True != False

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

This 072 failure can be seen on s2lp4 Yakkety as well (060 is fine with s2lp4)

FAIL: test_072_config_debug_rodata (__main__.KernelSecurityTest)
Traceback (most recent call last):
File "./test-kernel-security.py", line 624, in test_072_config_debug_rodata
self.assertEqual(self._test_config('DEBUG_RODATA'), expected)
AssertionError: True != False

Revision history for this message
Steve Beattie (sbeattie) wrote :

Hi Po-Hsu,

I don't know what s2lp4 is. Test 072 succeeding on arm64 would indicate that bug 1501645 ("arm64 kernel has READ_IMPLIES_EXEC in personality, makes data areas executable") has been fixed, but if it's not that way on all yakkety arm64 hosts, then I don't know what's going on. Can you check the contents of /proc/self/personality on hosts where the test is "succeeding" (really, it's configured to expect failure on arm64), as well as "failing".

Also, while it's a bit subtle, the first machine is showing that test test_072_config_debug_set_module_ronx is failing (which checks that the 'DEBUG_SET_MODULE_RONX' kernel config option is set, while s2lp4 shows that the test test_072_config_debug_rodata is failing (which checks for the slightly different 'DEBUG_RODATA' kernel config option).

For the 'DEBUG_SET_MODULE_RONX' config option, it looks like arm64 support for that has been added to the kernel, so I've fixed the test_072_config_debug_set_module_ronx test to expect success there.

For 'DEBUG_RODATA', somethings gone wonky with the test, as the test should be expecting the it to be set, but doesn't appear to be (the 'expected' value looks to be False). Is there a full output of the test run somewhere?

Thanks.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Oops,
s2lp4 is s390x (Ubuntu on LPAR), the arch for these two systems are different, sorry about the confusion.

In summary:
060, 072 failed on arm64 Yakkety
072 failed on s390x Yakkety

072 didn't pass on the arm host, so I think this is expected as you mentioned in the comment.

The /proc/self/personality content on the failing arm64 system
ubuntu@ms10-35-mcdivittB0-kernel:~$ cat /proc/self/personality
00000000

Thanks for the fix to DEBUG_SET_MODULE_RONX.

For the "DEBUG_RODATA" issue on s390x, the complete log can be found here: http://pastebin.ubuntu.com/23744549/

Revision history for this message
Steve Beattie (sbeattie) wrote :

Ah, thanks for the explanation. Okay, it looks like CONFIG_DEBUG_RODATA is supported/enabled on s390x in yakkety's kernel. And it looks like READ_IMPLIES_EXEC isn't always forced on on arm64 anymore either (though it looks like it's still getting set on pid 1, or else a different test would fail).

I've updated the lp:qa-regression-testing tests to take these changes into account, so rerunning the tests with the updated tree should all pass now (it should also address the test_213_setscokopt_sndbufforce_negative_value() failure that is also present in the s390x log that was pasted). Therefore, I'm closing this bug (please re-open if testing shows I messed something up).

Thanks!

Changed in qa-regression-testing:
status: New → Fix Released
Revision history for this message
Steve Beattie (sbeattie) wrote :

It looks like I mis-read the test_050_personality() in test-kernel-security.py; it should fail if pid 1 also has the READ_IMPLIES_EXEC personality set, and since it's not failing, I think that's all good on arm64.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.