This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH v2] Linux/Alpha: don't use timeval32 system calls.
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Richard Henderson <rth at twiddle dot net>
- Date: Thu, 29 Aug 2019 22:36:53 +0200
- Subject: Re: [RFC PATCH v2] Linux/Alpha: don't use timeval32 system calls.
- References: <20190828153043.23644-1-zackw@panix.com> <CAK8P3a3oHbhRg4kSi1DMeNPMm4Ehev+kn+5NvDKANbJeppGjiQ@mail.gmail.com> <CAKCAbMhcpxvX847uDOX=HcZWK-x8kYda2U9yYYoZR6hxMrwcbw@mail.gmail.com>
On Thu, Aug 29, 2019 at 7:57 PM Zack Weinberg <zackw@panix.com> wrote:
> On Wed, Aug 28, 2019 at 11:58 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wed, Aug 28, 2019 at 5:30 PM Zack Weinberg <zackw@panix.com> wrote:
> > >
> > > * The patched glibc will NOT use system calls that involve 32-bit
> > > time_t to implement its compatibility symbols. This will make both
> > > our lives and the kernel maintainers' lives easier. The primary
> > > argument I've seen against it is that the kernel could warn about
> > > uses of the old system calls, helping people find old binaries that
> > > need to be recompiled. I think there are several other ways we
> > > could accomplish this, e.g. scripts to scan the filesystem for
> > > binaries with references to the old symbol versions, or issuing
> > > diagnostics ourselves.
> >
> > Another possible issue is seccomp filtering for a known set of
> > syscalls. The kernel vdso just got reverted so it no longer falls
> > back to the clock_gettime64() syscall to implement the
> > clock_gettime() vdso call when that is unavailable
>
> Yes, I'm aware that this is potentially a problem. In this specific
> case, recompiling the program with 64-bit time_t (however that's
> accomplished) would cause the program to change the set of syscalls it
> uses and the seccomp filter to break _anyway_, so I think it's an
> acceptable compatibility break.
The conclusion for the kernel vdso was different: obviously
using 64-bit time_t breaks a lot of things and it requires a
decision to be made by someone who can hopefully fix it.
However, just running an existing binary program on a newer
kernel (or a newer glibc in your case) is not normally expected
to break like this, and this broke the kernel's no-regression
rule.
OTOH, one can reasonably claim that the use of seccomp
by an application is the fundamental problem that glibc has
no way of solving -- relying on specific system call numbers
to be used inside of glibc is not that different from mixing
direct syscall() invocations with glibc calls, and this may also
result unexpected behavior. This is clearly not the first time
that the problem with seccomp has come up like that.
Arnd