test_021_aslr_dapper_libs from ubuntu_qrt_kernel_security failed on K-5.19 / J-OEM-6.1 / J-6.2 AMD64

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1983357

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This test is trying to call a compiled binary "aslr32" and execute:
./aslr32 libs --verbose

If you try to call it from the script, it will fail, however if you run the binary directly it will be good:

ubuntu@harpo:~/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts$ sudo python2 ./test-kernel-security.py -v KernelSecurityTest.test_021_aslr_dapper_libs
Running test: './test-kernel-security.py' distro: 'Ubuntu 22.10' kernel: '5.19.0-15.15 (Ubuntu 5.19.0-15.15-generic 5.19.0)' arch: 'amd64' uid: 0/0 SUDO_USER: 'ubuntu')
test_021_aslr_dapper_libs (__main__.KernelSecurityTest)
ASLR of libs ... (default libs native) (default libs native rekey) (default libs COMPAT) FAIL

======================================================================
FAIL: test_021_aslr_dapper_libs (__main__.KernelSecurityTest)
ASLR of libs
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-kernel-security.py", line 1782, in test_021_aslr_dapper_libs
    self._test_aslr('libs', expected)
  File "./test-kernel-security.py", line 1739, in _test_aslr
    self._test_aslr_all(area, expected, "default %s" % area)
  File "./test-kernel-security.py", line 1732, in _test_aslr_all
    self._test_aslr_exec(area, expected, target, name)
  File "./test-kernel-security.py", line 1715, 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 1203, in assertShellExitEquals
    self.assertEqual(expected, rc, msg + result + report)
AssertionError: default libs COMPAT:
Got exit code 1, expected 0
Command: './aslr32', 'libs', '--verbose'
Output:
Checking ASLR of libs:
 0xf7c81790
 0xf7c81790
 0xf7c81790
FAIL: ASLR not functional (libs always at 0xf7c81790)

----------------------------------------------------------------------
Ran 1 test in 0.589s

FAILED (failures=1)
ubuntu@harpo:~/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts$ sudo ./kernel-security/aslr/aslr libs --verbose
Checking ASLR of libs:
 0x007fb495c907c0
 0x007f674ea907c0
 0x007f0e0fe907c0
ok: ASLR of libs functional

For comment #2, I misread the output, it's actually calling aslr32 instead of aslr, and no it's not working with running the binary directly

ubuntu@harpo:~/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/aslr$ sudo ./aslr32 libs --verbose
Checking ASLR of libs:
 0xf7c81790
 0xf7c81790
 0xf7c81790
FAIL: ASLR not functional (libs always at 0xf7c81790)

Some instances, show the same issue with test_021_aslr_dapper_mmap

FAIL: test_021_aslr_dapper_mmap (__main__.KernelSecurityTest)
ASLR of mmap

Traceback (most recent call last):
File "./test-kernel-security.py", line 1755, in test_021_aslr_dapper_mmap
  self._test_aslr('mmap', expected)
File "./test-kernel-security.py", line 1727, in _test_aslr
  self._test_aslr_all(area, expected, "default %s" % area)
File "./test-kernel-security.py", line 1720, in _test_aslr_all
  self._test_aslr_exec(area, expected, target, name)
File "./test-kernel-security.py", line 1703, 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 1203, in assertShellExitEquals
  self.assertEqual(expected, rc, msg + result + report)
AssertionError: default mmap COMPAT:
Got exit code 1, expected 0
Command: './aslr32', 'mmap', '--verbose'
Output:
Checking ASLR of mmap:
  0xf7aff010
  0xf7aff010
  0xf7aff010
ASLR not functional (mmap always at 0xf7aff010)

This issue, test_021_aslr_dapper_libs failure, can be found on J-oem-6.0.0-1002.2 as well.

This issue can be found on J-nvidia-5.19/5.19.0-1002.2 with node blanka.

This issue can be found on J-azure-6.2 AMD64 as well.

aslr32 libs regressed because of upstream commit 1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX").

Some filesystems mmap will try to align the address by the size and when glibc loaded maps the ELF file, a randomized address will be chosen but then aligned to the PMD size (21 bits on x86). Given we default to randomizing 8 bits of the address on 32-bit programs on x86 and the page size of 4096, we end up clearing the random bits when that alignment is done.

There are a couple of paths here:

1) revert that upstream commit, losing optimization on transparent huge pages due to the PMD aligment for every file mapped by either 32-bit of 64-bit programs;
2) do not align for 32-bit programs. I don't expect code to be maintainable here.
3) increase the default random bits for 32-bit programs to 16 (the x86 maximum) and other sensible values on other platforms (arm64 and ppc64el), which has the potential of breaking a few programs, specially ones that require "too much memory", but those should be using 64-bit if that is really needed;
4) ignore the issue and leave 32-bit programs vulnerable to attacks.

Given the alternative of leaving programs vulnerable, I would rather experimenting with changing the default (option 3). The option is tunable anyway and users should be able to change the setting if necessary. We could also consider making the behavior tunable and we actually have THP as a setting, so could as well use it.

Cascardo.

Thanks for investigating this, Cascardo. I agree that option 3 is likely the best path forward, either via changing our kernel config defaults or adjusting the sysctl defaults via the procps package. For reference the adjustable sysctl setting is vm.mmap_rnd_compat_bits.

Hey, Steve, we have applied this on linux-unstable, and will let it sit there for a bit before we try this on mantic and lunar. I took the opportunity and raised all values to the max, including the non-compat ones. That should recover some of the bits we lost due to this PMD alignment.