test_030_mmap_min in ubuntu_qrt_kernel_security failed on 5.11/5.13/5.15 ARM64k

[Po-Hsu Lin]

Issue found on 5.11.0-20.21-generic-64k and 5.8.0-56.63-generic-64k with arm64 instances on aws cloud (instance a1.2xlarge, a1.medium, c6g.8xlarge)

  ======================================================================
  FAIL: test_030_mmap_min (__main__.KernelSecurityTest)
  Low memory allocation respects mmap_min_addr
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "./test-kernel-security.py", line 289, in test_030_mmap_min
      self.assertShellExitEquals(expected, ['sudo', '-u', os.environ['SUDO_USER'], "./low-mmap", '%d' % (wanted)])
    File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1166, in assertShellExitEquals
      self.assertEqual(expected, rc, msg + result + report)
  AssertionError: Got exit code 1, expected 0
  Command: 'sudo', '-u', 'ubuntu', './low-mmap', '32768'
  Output:
  Testing lower 32768 bytes in 65536 byte chunks: pass (could not allocate memory)
  Testing 65536 byte chunk above 32767:
   Unexpectedly unable to allocate 65536 bytes at 0x00000000
  FAIL (cannot allocate memory)

This is not a regression as it can be found in 5.11.0-14.15-generic-64k and 5.8.0-52.59-generic-64k as well.

Also, it looks like this issue does not exist on generic arm64 kernel with the same instance.

[Kleber Sacilotto de Souza (kleber-souza)]

Found with hirsute/linux 5.11.0-26.28.

[Stefan Bader (smb)]

Is mmap_min_addr working on arm64 with the generic-64k flavour? Or rather supposed to, maybe that is a x86 thing...

[Po-Hsu Lin (cypressyew)]

Hi Stefan,
yes this test_030_mmap_min test passed with generic arm64, but not generic-64k arm64

5.11.0-38.4 with appleton arm64:
 test_030_mmap_min (__main__.KernelSecurityTest)
 Low memory allocation respects mmap_min_addr ... (32768) ok

[Steve Beattie (sbeattie)]

I suspect with the 64k pages, that the mmap_min_addr has to be page aligned, and so might be getting set or rounded to 64k instead of 32k like on arm64 with 4k pages. I say this because it looks like from the testcase output that it is correctly blocking the attempt to mmap the lowest 32k, but also unexpectedly blocking the next 32k, where the test expects mmap_min_addr to be 32k on arm64.

What is the contents of /proc/sys/vm/mmap_min_addr on such a system, as well as the output of 'grep PageSize /proc/self/smaps | sort | uniq'?

[Po-Hsu Lin (cypressyew)]

Hi Steve,
here is the output from an AWS a1.medium instance running with H-5.11 generic-64k:

$ uname -a
Linux ip-172-31-9-86 5.11.0-38-generic-64k #42-Ubuntu SMP Fri Sep 24 15:47:04 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
$ cat /proc/sys/vm/mmap_min_addr
32768
$ grep PageSize /proc/self/smaps | sort | uniq
KernelPageSize: 64 kB
MMUPageSize: 64 kB

[Steve Beattie (sbeattie)]

Hey Po-Hsu, I attempted to get a generic/generic-64k kernel to boot in ec2 and never got it to recognize the root device, so I couldn't reporduce the failure. That said, from what I've read it and what the failed tests report indicates that despite the kernel reporting mmap_min_addr of 32k, the kernel enforces it by pages so on a 64k page system, the actual enforced value will be 64k.

I have gone ahead and committed a fix to QRT that checks for whether CONFIG_ARM64_64K_PAGES is enabled and keeps the expected 64k enforced value if so: https://git.launchpad.net/qa-regression-testing/commit/?id=d56f3347a1f69c06be638ca6b6917083143ce5a4

I verified that it didn't trigger with the regular aws arm kernel, but it would be great if you could validate the adjusted test on arm64 + 64k page environment.

Thanks!

[Po-Hsu Lin (cypressyew)]

Hello Steve,
sorry for the late reply, I think it can be reproduced on a arm64 bare-metal system. This test is now failing with a different error message.

On A 5.11.0-39.43 generic-64k ARM64 bare-metal node "dazzle":
    ======================================================================
    FAIL: test_030_mmap_min (__main__.KernelSecurityTest)
    Low memory allocation respects mmap_min_addr
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "./test-kernel-security.py", line 285, in test_030_mmap_min
        mmap_limit = self._test_sysctl_value('vm/mmap_min_addr', wanted, "is wine or qemu-kvm-extras-static installed?")
      File "/home/ubuntu/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1269, in _test_sysctl_value
        self.assertEqual(value, expected, report)
    AssertionError: /proc/sys/vm/mmap_min_addr is not 65536: 32768 (is wine or qemu-kvm-extras-static installed?)

Test suite HEAD SHA1: 07a33cbe

This can be spotted with 5.11.0-39.43 generic-64k on a1.medium / a1.metal / c6g.8xlarge
and 5.13.0-21.21 generic-64k as well.

[Thadeu Lima de Souza Cascardo (cascardo)]

https://code.launchpad.net/~cascardo/qa-regression-testing/+git/qa-regression-testing/+merge/435498

[Steve Beattie (sbeattie)]

Cascardo, nice catch, merged. Thanks.

[Po-Hsu Lin (cypressyew)]

I can confirm that with Cascardo's fix, the low-mmap test in test_030_mmap_min is now green.

$ sudo -u ubuntu ./low-mmap 65536
Testing lower 65536 bytes in 65536 byte chunks: pass (could not allocate memory)
Testing 65536 byte chunk above 65535: pass (able to allocate memory)

Closing this bug base on this result.

However the zero-possible test is failing (unexpected pass), please see bug 2002503

[Po-Hsu Lin (cypressyew)]

Hints retired. Thanks.