| Message ID | 20230725175714.1727827-1-josimmon@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | tst-personality: Check for ENOSYS | expand |
On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: > Return UNSUPPORTED if personality fails with ENOSYS. Where did you see this? It would be good to comment in the commit message the system or systems under which this occurs. > --- > sysdeps/unix/sysv/linux/tst-personality.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sysdeps/unix/sysv/linux/tst-personality.c b/sysdeps/unix/sysv/linux/tst-personality.c > index 5e59627826..4b171ccae3 100644 > --- a/sysdeps/unix/sysv/linux/tst-personality.c > +++ b/sysdeps/unix/sysv/linux/tst-personality.c > @@ -35,7 +35,7 @@ do_test (void) > { > /* The syscall argument might be filtered by kernel, so the > test can not check for the bug issue. */ > - if (errno == EPERM) > + if (errno == EPERM || errno == ENOSYS) > FAIL_UNSUPPORTED ("personality syscall argument are filtered"); > FAIL_EXIT1 ("personality (%#x) failed: %m", test_persona); > }
On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote: > On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: > > Return UNSUPPORTED if personality fails with ENOSYS. > > Where did you see this? Some "container environment" I guess. Note that personality is added in Linux 1.1.20 so there is no way a Linux system does not have this syscall today. To me we really should not try to support all these container environments with too-clever seccomp filters. > It would be good to comment in the commit message the system or > systems under which this occurs.
On Thu, Jul 27, 2023 at 10:20:37AM +0800, Xi Ruoyao wrote: > On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote: > > On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: > > > Return UNSUPPORTED if personality fails with ENOSYS. > > > > Where did you see this? > > Some "container environment" I guess. Note that personality is added in > Linux 1.1.20 so there is no way a Linux system does not have this > syscall today. > > To me we really should not try to support all these container > environments with too-clever seccomp filters. Yes it is a podman container on x86_64-linux-gnu. This is my main developement envrionment where I'm seeing a handful of testcases that fail. Thanks, Joe
On Thu, 2023-07-27 at 09:02 -0400, Joe Simmons-Talbott wrote: > On Thu, Jul 27, 2023 at 10:20:37AM +0800, Xi Ruoyao wrote: > > On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote: > > > On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: > > > > Return UNSUPPORTED if personality fails with ENOSYS. > > > > > > Where did you see this? > > > > Some "container environment" I guess. Note that personality is added in > > Linux 1.1.20 so there is no way a Linux system does not have this > > syscall today. > > > > To me we really should not try to support all these container > > environments with too-clever seccomp filters. > > Yes it is a podman container on x86_64-linux-gnu. This is my main > developement envrionment where I'm seeing a handful of testcases that > fail. Seccomp filter can block arbitrary syscall and we have no way to support all the seccomp filters in the wild. More generally, if you've specified --with-kernel=x.y but the a syscall available in Linux x.y returns ENOSYS, the situation is considered "broken kernel ABI" and not a Glibc bug. So there is nothing to be fixed here. Try to disable seccomp filter (I'm not sure if podman has an option to control it, but if not I'd be very surprised).
On 27/07/23 10:25, Xi Ruoyao via Libc-alpha wrote: > On Thu, 2023-07-27 at 09:02 -0400, Joe Simmons-Talbott wrote: >> On Thu, Jul 27, 2023 at 10:20:37AM +0800, Xi Ruoyao wrote: >>> On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote: >>>> On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: >>>>> Return UNSUPPORTED if personality fails with ENOSYS. >>>> >>>> Where did you see this? >>> >>> Some "container environment" I guess. Note that personality is added in >>> Linux 1.1.20 so there is no way a Linux system does not have this >>> syscall today. >>> >>> To me we really should not try to support all these container >>> environments with too-clever seccomp filters. >> >> Yes it is a podman container on x86_64-linux-gnu. This is my main >> developement envrionment where I'm seeing a handful of testcases that >> fail. > > Seccomp filter can block arbitrary syscall and we have no way to support > all the seccomp filters in the wild. > > More generally, if you've specified --with-kernel=x.y but the a syscall > available in Linux x.y returns ENOSYS, the situation is considered > "broken kernel ABI" and not a Glibc bug. So there is nothing to be > fixed here. > > Try to disable seccomp filter (I'm not sure if podman has an option to > control it, but if not I'd be very surprised). > We have this policy on glibc code itself, so we can use any fallback safely without the need to evaluate whether EPERM does make sense or if it should be reported to caller. This symbol is not used internally, so filtering is possible without much trouble. For tests I think it is feasible to work around Linux security filters and we already have a bug report to track it [1]. As I said in last patch review meeting, this kind of environment should be ok for CI/patchwork but we still need to occasionally and specially on release workflow to run make check on environment with maximum coverage to avoid having too much UNSUPPORTED tests. Also, the personality syscall is a trick one because Linux kABI always succeed and thus there is no easy way to correct filter it (filtering is always broken on 32 bits for instance [2]). [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30603 [2] https://patchwork.sourceware.org/project/glibc/patch/20230606164830.126052-1-adhemerval.zanella@linaro.org/
On Thu, 2023-07-27 at 10:40 -0300, Adhemerval Zanella Netto wrote: > > > On 27/07/23 10:25, Xi Ruoyao via Libc-alpha wrote: > > On Thu, 2023-07-27 at 09:02 -0400, Joe Simmons-Talbott wrote: > > > On Thu, Jul 27, 2023 at 10:20:37AM +0800, Xi Ruoyao wrote: > > > > On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote: > > > > > On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote: > > > > > > Return UNSUPPORTED if personality fails with ENOSYS. > > > > > > > > > > Where did you see this? > > > > > > > > Some "container environment" I guess. Note that personality is added in > > > > Linux 1.1.20 so there is no way a Linux system does not have this > > > > syscall today. > > > > > > > > To me we really should not try to support all these container > > > > environments with too-clever seccomp filters. > > > > > > Yes it is a podman container on x86_64-linux-gnu. This is my main > > > developement envrionment where I'm seeing a handful of testcases that > > > fail. > > > > Seccomp filter can block arbitrary syscall and we have no way to support > > all the seccomp filters in the wild. > > > > More generally, if you've specified --with-kernel=x.y but the a syscall > > available in Linux x.y returns ENOSYS, the situation is considered > > "broken kernel ABI" and not a Glibc bug. So there is nothing to be > > fixed here. > > > > Try to disable seccomp filter (I'm not sure if podman has an option to > > control it, but if not I'd be very surprised). > > > > > We have this policy on glibc code itself, so we can use any fallback safely > without the need to evaluate whether EPERM does make sense or if it should > be reported to caller. This symbol is not used internally, so filtering > is possible without much trouble. > > For tests I think it is feasible to work around Linux security filters and > we already have a bug report to track it [1]. As I said in last patch review > meeting, this kind of environment should be ok for CI/patchwork but we still > need to occasionally and specially on release workflow to run make check on > environment with maximum coverage to avoid having too much UNSUPPORTED > tests. > > Also, the personality syscall is a trick one because Linux kABI always > succeed and thus there is no easy way to correct filter it (filtering is > always broken on 32 bits for instance [2]). Frankly I've never considered seccomp a good containment mechanism... To me the if the other facilities (namespacing, cgroup, and the traditional UNIX permissions) are used correctly there is no need to seccomp things at all. And these facilities are much less "arbitrary" than seccomp. As an ICPC coach: the online judge system for our online programming competitions had used to rely on seccomp, but it just started to reject valid programs for **each** glibc or libstdc++ update and we needed to spend a lot of time testing and adjusting the seccomp whitelist. Now we've kicked seccomp out of the judge system. > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30603 > [2] https://patchwork.sourceware.org/project/glibc/patch/20230606164830.126052-1-adhemerval.zanella@linaro.org/
Am Donnerstag, 27. Juli 2023, 04:20:37 CEST schrieb Xi Ruoyao via Libc-alpha: > > Some "container environment" I guess. Note that personality is added in > Linux 1.1.20 so there is no way a Linux system does not have this > syscall today. > > To me we really should not try to support all these container > environments with too-clever seccomp filters. > > > It would be good to comment in the commit message the system or > > systems under which this occurs. > Documenting precisely which tests fail precisely where would be very useful indeed. I started a stub wiki page about it a few days ago, feel free to extend it: https://sourceware.org/glibc/wiki/Testing/Containers Also, it's rather trivial to mark specific tests as XFAIL in a build environment, see e.g. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r3.ebuild#n158 https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r3.ebuild#n1223
On Thu, Jul 27, 2023 at 04:20:40PM +0200, Andreas K. Huettel wrote: > Am Donnerstag, 27. Juli 2023, 04:20:37 CEST schrieb Xi Ruoyao via Libc-alpha: > > > > Some "container environment" I guess. Note that personality is added in > > Linux 1.1.20 so there is no way a Linux system does not have this > > syscall today. > > > > To me we really should not try to support all these container > > environments with too-clever seccomp filters. > > > > > It would be good to comment in the commit message the system or > > > systems under which this occurs. > > > > Documenting precisely which tests fail precisely where would be very useful > indeed. I started a stub wiki page about it a few days ago, feel free > to extend it: > > https://sourceware.org/glibc/wiki/Testing/Containers I've added some notes about my findings in Fedora podman containers. > > Also, it's rather trivial to mark specific tests as XFAIL in a build > environment, see e.g. > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r3.ebuild#n158 > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r3.ebuild#n1223 Thanks, this was helpful. Thanks, Joe
diff --git a/sysdeps/unix/sysv/linux/tst-personality.c b/sysdeps/unix/sysv/linux/tst-personality.c index 5e59627826..4b171ccae3 100644 --- a/sysdeps/unix/sysv/linux/tst-personality.c +++ b/sysdeps/unix/sysv/linux/tst-personality.c @@ -35,7 +35,7 @@ do_test (void) { /* The syscall argument might be filtered by kernel, so the test can not check for the bug issue. */ - if (errno == EPERM) + if (errno == EPERM || errno == ENOSYS) FAIL_UNSUPPORTED ("personality syscall argument are filtered"); FAIL_EXIT1 ("personality (%#x) failed: %m", test_persona); }