| Message ID | 20190603120349.403-1-dan.streetman@canonical.com |
|---|---|
| Headers | show |
| Series | Provide ppc64el syscall for pkey_* | expand |
On 03.06.19 14:03, Dan Streetman wrote: > From: Dan Streetman <ddstreet@canonical.com> > > BugLink: https://bugs.launchpad.net/bugs/1821625 > > 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). > > Ram Pai (2): > powerpc: sys_pkey_alloc() and sys_pkey_free() system calls > powerpc: sys_pkey_mprotect() system call > > arch/powerpc/include/asm/systbl.h | 3 +++ > arch/powerpc/include/asm/unistd.h | 6 +----- > arch/powerpc/include/uapi/asm/unistd.h | 3 +++ > 3 files changed, 7 insertions(+), 5 deletions(-) > Acked-by: Stefan Bader <stefan.bader@canonical.com>
On 6/3/19 5:03 AM, Dan Streetman wrote: > From: Dan Streetman <ddstreet@canonical.com> > > BugLink: https://bugs.launchpad.net/bugs/1821625 > > 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). > > Ram Pai (2): > powerpc: sys_pkey_alloc() and sys_pkey_free() system calls > powerpc: sys_pkey_mprotect() system call > > arch/powerpc/include/asm/systbl.h | 3 +++ > arch/powerpc/include/asm/unistd.h | 6 +----- > arch/powerpc/include/uapi/asm/unistd.h | 3 +++ > 3 files changed, 7 insertions(+), 5 deletions(-) > Acked-by: Connor Kuehl <connor.kuehl@canonical.com>
On 6/3/19 2:03 PM, Dan Streetman wrote: > From: Dan Streetman <ddstreet@canonical.com> > > BugLink: https://bugs.launchpad.net/bugs/1821625 > > 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). > > Ram Pai (2): > powerpc: sys_pkey_alloc() and sys_pkey_free() system calls > powerpc: sys_pkey_mprotect() system call > > arch/powerpc/include/asm/systbl.h | 3 +++ > arch/powerpc/include/asm/unistd.h | 6 +----- > arch/powerpc/include/uapi/asm/unistd.h | 3 +++ > 3 files changed, 7 insertions(+), 5 deletions(-) > Applied to bionic/master-next branch. Thanks, Kleber
From: Dan Streetman <ddstreet@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1821625 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). Ram Pai (2): powerpc: sys_pkey_alloc() and sys_pkey_free() system calls powerpc: sys_pkey_mprotect() system call arch/powerpc/include/asm/systbl.h | 3 +++ arch/powerpc/include/asm/unistd.h | 6 +----- arch/powerpc/include/uapi/asm/unistd.h | 3 +++ 3 files changed, 7 insertions(+), 5 deletions(-)