From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SUBJ_OBFU_PUNCT_FEW,SUBJ_OBFU_PUNCT_MANY autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id b27af65e for ; Sun, 19 Jan 2020 16:36:30 +0000 (UTC) Received: (qmail 13807 invoked by uid 550); 19 Jan 2020 16:36:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13772 invoked from network); 19 Jan 2020 16:36:28 -0000 Date: Sun, 19 Jan 2020 11:36:16 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200119163616.GE30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: [musl] [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