Re: [musl] [RFC] removing __NR_clock_gettime / SYS_clock_gettime

[Rich Felker <dalias@libc.org>]

On Sun, Jan 19, 2020 at 07:42:26PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2020-01-19 13:16:43 -0500]:
> > On Sun, Jan 19, 2020 at 06:51:17PM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@libc.org> [2020-01-19 11:36:16 -0500]:
> > > > Today we discovered that libstdc++ std::chrono is broken because it's
> > > > making direct syscalls to SYS_clock_gettime to work around glibc
> > > > putting clock_gettime in librt. This is exactly the same issue as
> > > > busybox https://bugs.busybox.net/show_bug.cgi?id=12091 and I would not
> > > > be surprised if it exists in more software. It's a silent bug that's
> > > > easy to find and fix if you know what to look for, but very confusing
> > > > and hard to find if you don't, and it can easily slip into software
> > > > that's not well-tested on time64.
> > > > 
> > > > What I'd like to propose doing is removing __NR_clock_gettime and
> > > > SYS_clock_gettime from the public sys/syscall.h (via bits headers) on
> > > > 32-bit archs, and moving SYS_clock_gettime to
> > > > arch/$(ARCH)/syscall_arch.h for musl-internal use. This would make it
> > > > a hard compile-time error for any software attempting to use the
> > > > syscall directly, and in the case of libstdc++ I think it would even
> > > > fix the problem without patching gcc, since they have a configure
> > > > check for the syscall.
> > > > 
> > > > Thoughts? Is this too big a hammer?
> > > 
> > > i think you should build gcc with --enable-libstdcxx-time so
> > > it does not try to do raw syscalls (which is bad on 64bit
> > > targets too, not just for time64, i thought distros already
> > > do this or patch out that entire thing)
> > 
> > It does raw syscalls with that as I understand it. You need =rt to
> > make it do the right thing.
> 
> --enable-libstdcxx-time is default in mcm since
> 
> commit 0291cc44eee410270a97efb6258394c1f1f8352a
> Commit:     Rich Felker <dalias@aerifal.cx>
> CommitDate: 2016-05-06 18:37:09 +0000
> 
> and the libstdc++ i built with that only has SYS_futex
> syscalls in it on all targets.
> 
> now i see that alpine libstdc++ has a raw clock_gettime
> syscall in it too, alpine should fix that.

Oh, the --enable-libstdcxx-time we already had was sufficient? I
thought --enable-libstdcxx-time and --enable-libstdcxx-time=rt were
different. Latest commit message may be nonsense then... :/

> > But we know how to fix this for gcc now. I'm more concerned that if we
> > already caught busybox and libstdc++ doing this, there may be lots
> > more apps doing it that we don't know about...
> 
> i see,
> i'm not sure what's the right solution.
> we can try to fix them or break their build.
> some usage may be valid though.

I don't think valid usage of SYS_clock_gettime is possible without
knowing old_time_t which libc does not expose. For example a program
using it and assuming it's long will break on x32.

It could be valid in arch-specific files or with arch-specific
preprocessor or runtime conditionals (i.e. hard-coding knowledge of
what old_time_t was for the arch).

> > > i'd ask the glibc folks if they want to do something about this
> > > when building for the time64 abi.
> > 
> > I think they just use the kernel headers to provide sys/syscall.h.
> 
> well if there are really raw syscall users with
> libc type then glibc will have a problem too,
> so either the user code gets fixed or glibc
> does some workaround.

Indeed, the code needs to get fixed. The question is whether it ends
up happening by people finding and reporting bugs, or by erroring out
at build time.

If musl doesn't itself take action to break it at build time, I think
distros still could use #pragma GCC poison or #undef in their default
build flags to catch the error.

Rich