libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

[Jamie Strandboge]

This was reported via the snapcraft forum[1]:

On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

$ lsb_release -d
Description: Ubuntu 18.04.4 LTS
$ scmp_sys_resolver -a aarch64 163
getrlimit
$ scmp_sys_resolver -a aarch64 getrlimit
163

focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

$ lsb_release -d
Description: Ubuntu 20.04 LTS
$ scmp_sys_resolver -a aarch64 163
UNKNOWN
$ scmp_sys_resolver -a aarch64 getrlimit
-10180

[1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-arm64/17237/8

[Alex Murray (alexmurray)]

When generating the list of systems calls for aarch64, libseccomp uses the generic kernel API headers rather than the architecture specific ones - and so misses the definitions of getrlimit, setrlimit and clone3 for aarch64 - if this is changed to use arch-specific headers then we can regenerate the syscalls.csv and these are now present as expected. Have submitted PRhttps://github.com/seccomp/libseccomp/pull/235 upstream for feedback.

[Alex Murray (alexmurray)]

See attached for a debdiff to fix this in groovy - this backports the PR mentioned above to add these missing syscalls for aarch64.

[Alex Murray (alexmurray)]

Tested on an up-to-date groovy install:

amurray@sec-groovy-amd64:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Groovy Gorilla (development branch)
Release: 20.10
Codename: groovy
amurray@sec-groovy-amd64:~$ dpkg -l seccomp
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-==============-============-=============================================================
ii seccomp 2.4.3-1ubuntu1 amd64 helper tools for high level interface to Linux seccomp filter
amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 getrlimit
-10180
amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 163
UNKNOWN
amurray@sec-groovy-amd64:~$ sudo apt upgrade
...
amurray@sec-groovy-amd64:~$ dpkg -l seccomp
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-==============-============-=============================================================
ii seccomp 2.4.3-1ubuntu2 amd64 helper tools for high level interface to Linux seccomp filter
amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 163
getrlimit
amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 getrlimit
163

[Alex Murray (alexmurray)]

@jdstrand would you be willing to sponsor that for me to groovy and then I'll update this bug for SRU of this back to focal (and will add this change also for the existing libseccomp SRU for eoan/bionic/xenial in LP #1876055)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "libseccomp_2.4.3-1ubuntu2.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Jamie Strandboge (jdstrand)]

Thanks for the debdiff Alex. Uploaded to groovy-proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libseccomp - 2.4.3-1ubuntu2

---------------
libseccomp (2.4.3-1ubuntu2) groovy; urgency=medium

  * Add missing syscalls for aarch64 (LP: #1877633)
    - fix-aarch64-syscalls.patch: Backport of pending PR #235 from
      upstream

 -- Alex Murray <email address hidden> Tue, 12 May 2020 13:21:14 +0930

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted libseccomp (2.4.3-1ubuntu3.16.04.2) for xenial have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/229-4ubuntu21.28 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#libseccomp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted libseccomp (2.4.3-1ubuntu3.18.04.2) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

apt/1.6.12ubuntu0.1 (arm64)
chrony/3.2-4ubuntu4.4 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#libseccomp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted libseccomp (2.4.3-1ubuntu3.20.04.2) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/unknown (armhf)
systemd/245.4-4ubuntu3.1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#libseccomp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted libseccomp (2.4.3-1ubuntu3.19.10.2) for eoan have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/242-7ubuntu3.9 (i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#libseccomp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Jamie Strandboge (jdstrand)]

FYI, I copied xenial-focal from the security-proposed ppa to -proposed. Borrowing from the ubuntu-sru team's SRU verification text:

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-<release> to verification-done-<release>. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-<release>. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Jamie Strandboge (jdstrand)]

FYI, I reran the xenial autopkgtests and they now pass.

[Jamie Strandboge (jdstrand)]

FYI, I reran the bionic and eoan autopkgtests and there are now no regressions.

[Jamie Strandboge (jdstrand)]

Sorry, I reran bionic and *focal* autopkgtests and there are now no regressions. Running eoan again.

[Alex Murray (alexmurray)]

Verified on focal using the following procedure - full log attached as well:

# install seccomp
$ apt install seccomp

# try resolving getrlimit for aarch64
$ scmp_sys_resolver -a aarch64 getrlimit
-10180

# on the current focal version this fails to resolve correctly and returns -10180

# enable -proposed
$ cat <<EOF >/etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list
# Enable Ubuntu proposed archive
deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed restricted main multiverse universe
EOF

# update libseccomp2 and seccomp from -proposed
$ apt install seccomp/$(lsb_release -cs)-proposed libseccomp2/$(lsb_release -cs)-proposed

# verify the installed version number is as expected from -proposed
$ dpkg -l seccomp libseccomp2

# try resolving getrlimit on aarch64 again
$ scmp_sys_resolver -a aarch64 getrlimit
163

[Dan Streetman (ddstreet)]

since the libseccomp uploads to b/e/x-proposed also have this bug marked in their changelog, it's showing up in the pending srus page as not verified yet for the x/b/e libseccomp uploads. As mentioned in the description, the initial problem only occurred in focal, but just for verification purposes:

eoan:

ubuntu@lp1877633-e:~$ dpkg -l |grep libseccomp
ii libseccomp2:amd64 2.4.1-0ubuntu0.19.10.3 amd64 high level interface to Linux seccomp filter
ubuntu@lp1877633-e:~$ scmp_sys_resolver -a aarch64 getrlimit
163

ubuntu@lp1877633-e:~$ dpkg -l |grep seccomp
ii libseccomp2:amd64 2.4.3-1ubuntu3.19.10.2 amd64 high level interface to Linux seccomp filter
ii seccomp 2.4.3-1ubuntu3.19.10.2 amd64 helper tools for high level interface to Linux seccomp filter
ubuntu@lp1877633-e:~$ scmp_sys_resolver -a aarch64 getrlimit
163

bionic:

ubuntu@lp1877633-b:~$ dpkg -l |grep seccomp
ii libseccomp2:amd64 2.4.1-0ubuntu0.18.04.2 amd64 high level interface to Linux seccomp filter
ii seccomp 2.4.1-0ubuntu0.18.04.2 amd64 helper tools for high level interface to Linux seccomp filter
ubuntu@lp1877633-b:~$ scmp_sys_resolver -a aarch64 getrlimit
163

ubuntu@lp1877633-b:~$ dpkg -l |grep seccomp
ii libseccomp2:amd64 2.4.3-1ubuntu3.18.04.2 amd64 high level interface to Linux seccomp filter
ii seccomp 2.4.3-1ubuntu3.18.04.2 amd64 helper tools for high level interface to Linux seccomp filter
ubuntu@lp1877633-b:~$ scmp_sys_resolver -a aarch64 getrlimit
163

xenial:

ubuntu@lp1877633-x:~$ dpkg -l|grep seccomp
ii libseccomp2:amd64 2.4.1-0ubuntu0.16.04.2 amd64 high level interface to Linux seccomp filter
ii seccomp 2.4.1-0ubuntu0.16.04.2 amd64 helper tools for high level interface to Linux seccomp filter
ubuntu@lp1877633-x:~$ scmp_sys_resolver -a aarch64 getrlimit
163

ubuntu@lp1877633-x:~$ dpkg -l|grep seccomp
ii libseccomp2:amd64 2.4.3-1ubuntu3.16.04.2 amd64 high level interface to Linux seccomp filter
ii seccomp 2.4.3-1ubuntu3.16.04.2 amd64 helper tools for high level interface to Linux seccomp filter
ubuntu@lp1877633-x:~$ scmp_sys_resolver -a aarch64 getrlimit
163

[Alex Murray (alexmurray)]

Ah thanks Dan! - I realise now that perhaps I should have had just the 1 bug report for both issues to make things simpler as having two seems to have complicated things too much.

[Dan Streetman (ddstreet)]

I think having 2 bugs is fine, it's just that doing so for libseccomp (where it's applied to all sru releases) adds both bugs to the pending-srus page:
https://people.canonical.com/~ubuntu-archive/pending-sru.html

which is used by some of the ~ubuntu-sru team members to find packages that are 'ready' to promote to -updates, so this one may have caused confusion as it was still showing this bug as yellow (i.e. not verified yet).

I think the ~ubuntu-sru team has tooling (probably from ubuntu-archive-tools project) that automatically updates all listed bugs with 'verification-RELEASE-needed' tags, it might be useful to include something like that into security tooling to add similar tags based on the changelog 'LP: #NNNNNN' bug tags.

Anyway, hopefully this can be released to -updates; we have another libseccomp patch we'd like to upload from bug 1861177.

[Alex Murray (alexmurray)]

@ddstreet - is there anything I can / still need to do to get this into -updates?

[Launchpad Janitor (janitor)]

This bug was fixed in the package libseccomp - 2.4.3-1ubuntu3.20.04.2

---------------
libseccomp (2.4.3-1ubuntu3.20.04.2) focal; urgency=medium

  * Updated to new upstream 2.4.3 version for updated syscalls support
    and test-suite robustness
    - d/p/add-5.4-local-syscall-headers.patch: Add local copy of the
      architecture specific header files which specify system call numbers
      from linux-libc-dev in focal to ensure unit tests pass on older
      releases where the linux-libc-dev package does not have the required
      system calls defined and use these during compilation of unit tests
    - d/p/db-properly-reset-attribute-state.patch: Drop this patch since
      is now upstream
    - LP: #1876055
  * Add missing aarch64 system calls
    - d/p/fix-aarch64-syscalls.patch
    - LP: #1877633

 -- Alex Murray <email address hidden> Tue, 02 Jun 2020 14:11:45 +0930

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for libseccomp has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Matt Thalman (mthalman)]

I don't see the updated applied to the ARM architecture. The versions of arm64 and armhf at https://packages.ubuntu.com/focal/libseccomp-dev still show 2.4.3-1ubuntu1. What's the story on that?

[Alex Murray (alexmurray)]

I am not sure how packages.ubuntu.com generates its list but they were published for all architectures on launchpad: https://launchpad.net/ubuntu/+source/libseccomp/2.4.3-1ubuntu3.20.04.2

Also the debs are present on ports.ubuntu.com: http://ports.ubuntu.com/ubuntu-ports/pool/main/libs/libseccomp/libseccomp-dev_2.4.3-1ubuntu3.20.04.2_armhf.deb and listed in the focal-security Packages.gz as expected.

So I suspect this is some artefact of packages.ubuntu.com perhaps only taking into account the contents of the security / updates pocket on amd64/i386 - but again I am not certain. However as far as apt is concerned, these packages exist and should be installed automatically by unattended-upgrades etc.