stack protector related configs test failed in qrt for ARM64 T-LTS-X

Bug #1789353 reported by Po-Hsu Lin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QA Regression Testing
Fix Released
Undecided
Unassigned
ubuntu-kernel-tests
Fix Released
Undecided
Unassigned
linux-lts-xenial (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

4.4.0-134-generic #160~14.04.1

These two failures were only reported on ARM64

  FAIL: test_180_config_stack_protector (__main__.KernelSecurityConfigTest)
  CONFIG_CC_STACKPROTECTOR set
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "./test-kernel-security.py", line 2338, in test_180_config_stack_protector
      self.assertKernelConfig(config_option, expected)
    File "./test-kernel-security.py", line 209, in assertKernelConfig
      self.assertKernelConfigUnset(name)
    File "./test-kernel-security.py", line 200, in assertKernelConfigUnset
      '%s option was expected to be unset in the kernel config' % name)
  AssertionError: CC_STACKPROTECTOR option was expected to be unset in the kernel config

  ======================================================================
  FAIL: test_190_config_have_stack_protector (__main__.KernelSecurityConfigTest)
  CONFIG_HAVE_CC_STACKPROTECTOR set
  ----------------------------------------------------------------------
  Traceback (most recent call last):
m[]sszzz self.assertKernelConfig(config_option, expected)
    File "./test-kernel-security.py", line 209, in assertKernelConfig
      self.assertKernelConfigUnset(name)
    File "./test-kernel-security.py", line 200, in assertKernelConfigUnset
      '%s option was expected to be unset in the kernel config' % name)
  AssertionError: HAVE_CC_STACKPROTECTOR option was expected to be unset in the kernel config

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-4.4.0-134-generic 4.4.0-134.160~14.04.1
ProcVersionSignature: User Name 4.4.0-134.160~14.04.1-generic 4.4.140
Uname: Linux 4.4.0-134-generic aarch64
ApportVersion: 2.14.1-0ubuntu3.29
Architecture: arm64
Date: Tue Aug 28 05:53:13 2018
SourcePackage: linux-lts-xenial
UpgradeStatus: No upgrade log present (probably fresh install)

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

On this ARM64 node (4.4.0-134-generic #160~14.04.1-Ubuntu):
$ grep STACKPRO config-4.4.0-134-generic
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

On i386 node (4.4.0-134-generic #160~14.04.1-Ubuntu):
$ grep STACKPRO config-4.4.0-134-generic
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

On amd64 node (4.4.0-134-generic #160~14.04.1-Ubuntu):
$ grep STACKPRO config-4.4.0-134-generic
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

So they're all posing the same config, this looks like an issue in qrt suite to me.

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

It looks like this part in qrt is the cause:

    def is_stackprotector_available(self):
        ....
            if self.dpkg_arch in ['arm64'] and \
               not self.lsb_release['Release'] > 14.04:
                self._skipped("gcc-4.8 and older did not support stack-protector on arm64")
                result = False
        ....

So in this case, it will return False, making the following if statement become valid:

    def test_180_config_stack_protector(self):
        ....
        expected = 'y'
        if not self.is_stackprotector_available():
            expected = None

In the end it's expecting the stack_protector to be unset for ARM64.

This issue can be split into two parts:1
1. Maybe we should include amd64 and i386 in is_stackprotector_available
2. If we're doing 1., then these config must be disabled on T-HWE

Revision history for this message
Stefan Bader (smb) wrote :

Just from my memory: I believe that config option (at least on the x86) side required support in the compiler which is not available back in the Trusty user-space. And the Trusty/lts-backport-xenial (not called HWE, yet to really make things confusing) is build in the Trusty user-space environment. The config options for stack protector (there was something available with a different option name) get automatically converted using the backport script.
If its left set for arm64, its probably a mistake, but somehow seems to have no visible effect. Maybe its ignored on that arch or the arm64 gcc was already including that option.
If that option is really actively enabled on arm64, then the test should probably be changed to expect this. If its a false positive, the test also needs to be adapted, but ... differently.

Po-Hsu Lin (cypressyew)
summary: - stack protector related configs test failed in qrt for ARM64 T-HWE
+ stack protector related configs test failed in qrt for ARM64 T-LTS-X
Po-Hsu Lin (cypressyew)
Changed in ubuntu-kernel-tests:
status: New → Confirmed
Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

It looks like I can use "-fsstack-protector" flag on an ARM64 node with T-LTS-X (works with cc as well)

ubuntu@ms10-34-mcdivittB0-kernel:~$ gcc --help | grep config
ubuntu@ms10-34-mcdivittB0-kernel:~$ gcc -fsstack-protector test.c
gcc: error: unrecognized command line option ‘-fsstack-protector’
ubuntu@ms10-34-mcdivittB0-kernel:~$ gcc -fstack-protector test.c
ubuntu@ms10-34-mcdivittB0-kernel:~$ gcc --version
gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.4) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ubuntu@ms10-34-mcdivittB0-kernel:~$ uname -a
Linux ms10-34-mcdivittB0-kernel 4.4.0-148-generic #174~14.04.1-Ubuntu SMP Thu May 9 08:23:55 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ms10-34-mcdivittB0-kernel:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.6 LTS
Release: 14.04
Codename: trusty

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

Hi Po-Hsu,

I'm really confused, because the check for arm64 was added for bug 1712007. Anyhow, I've fixed up the test to look for 4.4 kernels and newer in https://git.launchpad.net/qa-regression-testing/commit/?id=85067ab92fe820aca4de571f423a7542bb7e43bc. Please re-open this bug I got the logic wrong here.

Thanks!

Changed in qa-regression-testing:
status: New → Fix Released
Changed in linux-lts-xenial (Ubuntu):
status: New → Invalid
Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Hi Steve,

The updated qrt will make these two test cases pass on 4.4 Trusty ARM64.
Thanks!

Changed in ubuntu-kernel-tests:
status: Confirmed → Fix Released
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.