> Per [1] this symbol is present in: firejail, elogind, valgrind, glibc, musl, > linux, > systemd, strace, stress-ng, libseccomp, qemu
tl;dr: it looks like glibc and stress-ng are the only packages from that list that might need a rebuild, but as with systemd, neither seem important enough to warrant a special no-change rebuild. They will pick up the new syscall value whenever they are next uploaded for any other bugfix (after the current bionic -proposed kernel is promoted to -updates). details: elogind: not included in bionic firejail: it does use SYS_pkey_mprotect (which is defined as __NR_pkey_mprotect): ddstreet@thorin:~/bugs/lp1821625/sym-check/firejail/firejail-0.9.52$ grep -r pkey_mprotect src/man/firejail.txt:the arguments of mmap, mmap2, mprotect, pkey_mprotect and shmat system src/fseccomp/seccomp.c: // same for pkey_mprotect(,,PROT_EXEC), where available src/fseccomp/seccomp.c:#ifdef SYS_pkey_mprotect src/fseccomp/seccomp.c: BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, SYS_pkey_mprotect, 0, 5), however, the latest build available: https://launchpad.net/ubuntu/+source/firejail/0.9.52-2 for ppc64el: https://launchpad.net/ubuntu/+source/firejail/0.9.52-2/+build/13948498 was built with libseccomp2, not libseccomp-dev (which provides the problematic public header file): Get:57 http://ftpmaster.internal/ubuntu bionic/main ppc64el libseccomp2 ppc64el 2.3.1-2.1ubuntu3 [47.2 kB] additionally, it was built with libseccomp2 version 2.3.1-2.1ubuntu3, which was earlier than when the problematic patch was added (per this bug comment 1). So no need to recompile. musl: appears to only define __NR_pkey_mprotect in its embedded headers, and doesn't include ppc; no need to require recompile: ddstreet@thorin:~/bugs/lp1821625/sym-check/musl/musl-1.1.19$ grep -r pkey_mprotect arch/mipsn32/bits/syscall.h.in:#define __NR_pkey_mprotect 6327 arch/mips64/bits/syscall.h.in:#define __NR_pkey_mprotect 5323 arch/arm/bits/syscall.h.in:#define __NR_pkey_mprotect 394 arch/aarch64/bits/syscall.h.in:#define __NR_pkey_mprotect 288 arch/or1k/bits/syscall.h.in:#define __NR_pkey_mprotect 288 arch/x32/bits/syscall.h.in:#define __NR_pkey_mprotect (0x40000000 + 329) arch/i386/bits/syscall.h.in:#define __NR_pkey_mprotect 380 arch/x86_64/bits/syscall.h.in:#define __NR_pkey_mprotect 329 arch/mips/bits/syscall.h.in:#define __NR_pkey_mprotect 4363 arch/microblaze/bits/syscall.h.in:#define __NR_pkey_mprotect 395 qemu: as @cpaelzer said, just in its embedded headers; no need to recompile. strace: does appear to use pkey_mprotect, but the latest ppc64el build: https://launchpad.net/ubuntu/+source/strace/4.21-1ubuntu1/+build/14750033 did not build with libseccomp-dev (or libseccomp2) at all. Additionally, it was built 2018-04-11, while the problematic patch was added to libseccomp 2019-02-12. No need to rebuild. stress-ng: it does include the number in its skip_syscalls list, of syscalls to skip while running the 'enosys' stressor: ddstreet@thorin:~/bugs/lp1821625/sym-check/stress-ng/stress-ng-0.09.25$ grep -r pkey_mprotect stress-enosys.c:#if defined(SYS_pkey_mprotect) stress-enosys.c: SYS_pkey_mprotect, stress-enosys.c:#if defined(__NR_pkey_mprotect) stress-enosys.c: __NR_pkey_mprotect, This stressor appears to call all syscall numbers that it thinks are not supported/implemented. In this case, whether __NR_pkey_mprotect is a negative number (if built with libseccomp-dev header), or not defined, the end result is the same: stress-ng will not skip the *real* pkey_mprotect syscall number. However, running 'sudo stress-ng --enosys 1' on a test ppc64el instance, at kernel 4.15.0-54 or -55, does not appear to have any negative effect. So I don't think stress-ng needs to be no-change rebuilt with the new kernel headers; it should be ok to just let it pick up the correct value whenever it is next uploaded for other reasons. valgrind: referenced only in a commented-out table in arm64-specific file; no rebuild needed. ddstreet@thorin:~/bugs/lp1821625/sym-check/valgrind/valgrind-3.13.0$ grep -r pkey_mprotect coregrind/m_syswrap/syswrap-arm64-linux.c: // (__NR_pkey_mprotect, sys_ni_syscall), // 288 glibc: it does reference pkey_mprotect. However, the latest build for bionic was on 2018-04-16, before the problematic patch was added to libseccomp. It appears that glibc's pkey_mprotect will simply return ENOSYS for the current version: int pkey_mprotect (void *addr, size_t len, int prot, int pkey) { if (pkey == -1) /* If the key is -1, the system call is precisely equivalent to mprotect. */ return __mprotect (addr, len, prot); #ifdef __NR_pkey_mprotect return INLINE_SYSCALL_CALL (pkey_mprotect, addr, len, prot, pkey); #else __set_errno (ENOSYS); return -1; #endif } It may be that glibc should now be rebuilt with the updated kernel headers, so it picks up support for the __NR_pkey_mprotect syscall, but I don't believe it is a bug to leave it returning ENOSYS until it is rebuilt later for some actual bugfix; a no-change rebuild for glibc just to pick up this new syscall number for ppc64el seems excessive. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821625 Title: systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test- seccomp) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1821625/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
