FS#65523 - [libseccomp] blocks systemd and new time64 functions for 32-bit with glibc 2.31 (sytemd-nspawn)

Attached to Project: Arch Linux
Opened by Andreas Baumann (andreas_baumann) - Sunday, 16 February 2020, 20:06 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 27 February 2020, 12:00 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Evangelos Foutras (foutrelis)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

systemd-nspawn fails to run 32-bit containers having glibc 2.31 installed.
systemd doesn't boot 32-bit systems at all due to missing time64 function
in libseccomp 2.4.1.

Reproducable with:

staging-pentium4-build (with a glibc 2.31 in the chroot)
mount --bind /var/lib/archbuild/staging-pentium4/builduser/staging
systemd-nspawn -D /mnt sleep 5

An strace on systemd-nspawn -D /mnt sleep 5 shows:

[pid 269905] clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=5, tv_nsec=0}, 0xff8ea1cc) = -1 EPERM (Operation not permitted)

This might not really be easily reproducable and I also know it
is completely unsupported (as it is 32-bit), but this blocks
our build slaves using systemd-nspawn currently.

You can follow (the somewhat frantic and intermixed with sshd update problems)
discusison at https://bbs.archlinux32.org/viewtopic.php?pid=6935.

I report that against libseccomp 2.4.1 though I know that it has already
been flagged out-of-date. But I cannot reflag it or add comments there..

I'm also aware that this "bug" doesn't affect anybody on 64-bit.

I posted this bug in the hope that the update to libseccomp 2.4.2 could
be hurried up a little bit. :-)
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Thursday, 27 February 2020, 12:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  libseccomp 2.4.2-1
Comment by Eli Schwartz (eschwartz) - Sunday, 16 February 2020, 21:31 GMT
It's not really about 32-bit archlinux being unsupported, though, is it?

It's about 64-bit systemd-nspawn being useless for entering nspawn containers containing 32-bit systems, including not only archlinux32 containers, but also debian i386 containers.

Question: is updating libseccomp to 2.4.2 sufficient to fix this?
Comment by Levente Polyak (anthraxx) - Sunday, 16 February 2020, 22:43 GMT
libseccomp update is halted as unfortunately the upstream folks took a weird path and refuse to send me a signed confirmation of the new maintainers signing key. Instead they commited the new maintainers signing key as a .md file into the repository and the old maintainer will sign (hopefully) the next upcoming release 2.4.3.
If someone wants to see 2.4.2 in our repos, you will need to convince them to post a signed confirmation anywhere that contains the new maintainers full fingerprint and was signed with the original maintainers signing key.

Basically the .md is added here https://github.com/seccomp/libseccomp/commit/e5c4b5ee8086b936d28b080e5477950f632b4d43 but he also refused to sign commits, so until there is a new signed release done by him that commits is pretty worthless from a trust chain PoV
Comment by Eli Schwartz (eschwartz) - Sunday, 16 February 2020, 23:22 GMT
I *think* the relevant change would be https://github.com/seccomp/libseccomp/commit/bf747eb21e428c2b3ead6ebcca27951b681963a0

So perhaps we can try backporting this instead, while we wait for a trustworthy signed release?
Comment by Evangelos Foutras (foutrelis) - Monday, 17 February 2020, 01:18 GMT
@Levente: The v2.4.2 tag is signed by Paul's key which is currently trusted in the PKGBUILD. This should provide sufficient confidence in the new maintainer's key.

We probably also want to grab these fixes planned for 2.4.3: https://github.com/seccomp/libseccomp/issues/187
Comment by Andreas Baumann (andreas_baumann) - Monday, 17 February 2020, 06:24 GMT
At least I can confirm that after upgrading to libsecomp 2.4.2 system-nspawn -D /mnt sleep 5 works again.

Also while doing a pacman -S glibc (being glibc 2.31) I got before:
(tons of) warning: warning given when extracting /usr/share/locale/ru/LC_MESSAGES/libc.mo (Can't restore time)
touch: setting times of '/usr': Operation not permitted

This also looks fine now (no errors after the update).

I checked also the sources of systemd and there I see for instance the new time syscalls in filter groups like @default.
Comment by Levente Polyak (anthraxx) - Monday, 17 February 2020, 06:44 GMT
@Evangelos: Nice, I may just switch over to the signed git tag for the time being. However, that doesn't provide any confidence in the new maintainer's key at all as that's not really how a trust graph can be maintained. Once a cryptographic (signing) key has been established as the root trust node, only cryptographic proves legitimate any content or new (additional) trust nodes. Even when the git tag is signed with the root trust but the release artifact is signed with a new unknown key, this doesn't add any cryptographic legitimacy to the new key. Instead it is to be considered as two independent paths, one you trust and one unknown until the established trust graph provides a cryptographic evidence that a new key is to be considered legitimate. As long as this didn't happen implicitly (embedded) or explicitly the two distinct trust graphs are not interconnected.

TLDR: I will switch over to git tags for 2.4.2 and get in touch with upstream yet again.
Comment by Eli Schwartz (eschwartz) - Monday, 17 February 2020, 06:55 GMT
upstream really needs to attest to the new version, but, if they still haven't done so by the time a new major.minor release is cut from master, then a valid signature on the tag cut from master will also sign https://github.com/seccomp/libseccomp/commit/e5c4b5ee8086b936d28b080e5477950f632b4d43 -- the totally unauthenticated git commit which claims that a new maintainer key is permitted to sign releases.

Why can't everyone be like this person? https://github.com/EFForg/https-everywhere/pull/17007#issuecomment-434968524
Comment by Levente Polyak (anthraxx) - Monday, 17 February 2020, 06:58 GMT
@Eli: Yes, that's what i meant by implicit (embedded) trust, any future release cut that contains that commit and is done by Paul will legitimate the new key :)
Wow, https-everywhere is exactly how it should be :thumbs:
Comment by alzeih (alzeih) - Tuesday, 18 February 2020, 10:50 GMT
Running steam in an nspawn container will use 200% cpu with the same message above in strace. Installing libseccomp 2.4.2 from testing fixes it. I would also like the new libseccomp to "be hurried up a little bit".
Comment by Eli Schwartz (eschwartz) - Tuesday, 18 February 2020, 15:58 GMT
This is also causing issues for building [multilib] lib32-glib2.

Loading...