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 363f9b58 for ; Sun, 19 Jan 2020 18:53:50 +0000 (UTC) Received: (qmail 4032 invoked by uid 550); 19 Jan 2020 18:53:48 -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 4011 invoked from network); 19 Jan 2020 18:53:47 -0000 Date: Sun, 19 Jan 2020 13:53:34 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200119185334.GJ30412@brightrain.aerifal.cx> References: <20200119163616.GE30412@brightrain.aerifal.cx> <20200119175117.GL23985@port70.net> <20200119181643.GI30412@brightrain.aerifal.cx> <20200119184225.GM23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200119184225.GM23985@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [RFC] removing __NR_clock_gettime / SYS_clock_gettime On Sun, Jan 19, 2020 at 07:42:26PM +0100, Szabolcs Nagy wrote: > * Rich Felker [2020-01-19 13:16:43 -0500]: > > On Sun, Jan 19, 2020 at 06:51:17PM +0100, Szabolcs Nagy wrote: > > > * Rich Felker [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 > 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