Comment 3 for bug 1821625

coverletter explanation as sent to kernel-team list:

In bionic, all archs provided by Ubuntu either define __NR_pkey_mprotect
(arm/x86) or define __IGNORE_pkey_mprotect (powerpc/s390). This value was
used, until libseccomp was updated via bug 1815415, to instead (if
__NR_pkey_mprotect was not defined by the kernel headers) define it as a
negative error value:

+#define __PNR_pkey_mprotect -10201
+#ifndef __NR_pkey_mprotect
+#define __NR_pkey_mprotect __PNR_pkey_mprotect
+#endif /* __NR_pkey_mprotect */

systemd, the next time it was built against libseccomp, pulled that
__NR_pkey_mprotect value and started using it for ppc64el, though it was
a negative error value, so it would not actually work as a syscall number.
This caused the systemd test-seccomp autopkgtest to start failing, as
the systemd function it tested only issued the pkey_mprotect syscall if
__NR_pkey_mprotect was defined.

After these patches are applied to bionic, both libseccomp and systemd will
need to be rebuilt - libseccomp rebuilt against the kernel headers, and
systemd against the libseccomp headers.

Note this is not only a fix to allow a test to pass, this actually
provides the syscall number for the functionality on ppc64el on bionic,
which would have failed before (on ppc64el on bionic, but not x86/arm
on bionic); specifically one example is the systemd usage
MemoryDenyWriteExecution as shown in bug 1725348.

Also note that s390x also defines __IGNORE_pkey_mprotect, but the systemd
test only expects its test case to pass for select archs, and s390x is not
one of them, so it has always expected a failure there. It appears s390x
still does not support pkey_mprotect (it defined pkey_* starting at
commit b41c51c8e194c0bdfb4b1778a137aea8246c86cd, but appears to still
not support them).