mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: [musl] [RFC] removing __NR_clock_gettime / SYS_clock_gettime
Date: Sun, 19 Jan 2020 11:36:16 -0500	[thread overview]
Message-ID: <20200119163616.GE30412@brightrain.aerifal.cx> (raw)

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

             reply	other threads:[~2020-01-19 16:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-19 16:36 Rich Felker [this message]
2020-01-19 17:51 ` Szabolcs Nagy
2020-01-19 18:16   ` Rich Felker
2020-01-19 18:42     ` Szabolcs Nagy
2020-01-19 18:53       ` Rich Felker
2020-01-19 19:30         ` Szabolcs Nagy
2020-01-21 18:49 ` [musl] [RFC] [PATCH] " Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200119163616.GE30412@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).