[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200119163616.GE30412@brightrain.aerifal.cx>
Date: Sun, 19 Jan 2020 11:36:16 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: [RFC] removing __NR_clock_gettime / SYS_clock_gettime
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?
Note that there are lots of other syscalls that are unsafe to use
directly due to struct timespec/timeval mismatch between user and
kernel, but (1) clock_gettime is the only one that's widely used
because of the glibc -lrt mess, and (2) most of the others have valid
usage cases, e.g. if the times argument is just a timeout and you're
calling them without a timeout (null pointer). So I think it suffices
to do this just for clock_gettime.
Also note a possible variant: we could leave the definition but rename
it to SYS_clock_gettime32 so that code that's implementing its own
fallbacks with direct syscalls for whatever reasons still has access
to the syscall number if needed, but only if it's aware of the name
change.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
