Comment 13 for bug 1821625

> 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.