[PATCH] tst-personality: Check for ENOSYS

[PATCH] tst-personality: Check for ENOSYS

[Joe Simmons-Talbott]

Return UNSUPPORTED if personality fails with ENOSYS.
---
 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);
     }
-- 
2.39.2

Re: [PATCH] tst-personality: Check for ENOSYS

[Carlos O'Donell]

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);
>      }

-- 
Cheers,
Carlos.

Re: [PATCH] tst-personality: Check for ENOSYS

[Xi Ruoyao]

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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] tst-personality: Check for ENOSYS

[Joe Simmons-Talbott]

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

Re: [PATCH] tst-personality: Check for ENOSYS

[Xi Ruoyao]

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

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] tst-personality: Check for ENOSYS

[Adhemerval Zanella Netto]

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/

Re: [PATCH] tst-personality: Check for ENOSYS

[Xi Ruoyao]

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/

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] tst-personality: Check for ENOSYS

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

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

-- 
PD Dr. Andreas K. Huettel
Institute for Experimental and Applied Physics
University of Regensburg
93040 Regensburg
Germany

tel. +49 151 241 67748 (mobile)
tel. +49 941 943 1618 (office)
e-mail andreas.huettel@ur.de
https://www.akhuettel.de/
https://www.akhuettel.de/group/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [PATCH] tst-personality: Check for ENOSYS

[Joe Simmons-Talbott]

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