[musl] [RFC] removing __NR_clock_gettime / SYS_clock_gettime

[musl] [RFC] removing __NR_clock_gettime / SYS_clock_gettime

[Rich Felker]

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

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

[Szabolcs Nagy]

* 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)

> 
> 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.

i'd ask the glibc folks if they want to do something about this
when building for the time64 abi.

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

[Rich Felker]

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.

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...

> > 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.
> 
> 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.

Rich

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

[Szabolcs Nagy]

* 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.

> 
> 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'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.

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

[Rich Felker]

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

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

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2020-01-19 13:53:34 -0500]:
> 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:
> > > > 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... :/

  --enable-libstdcxx-time

is the same as

  --enable-libstdcxx-time=yes

which does proper configure checks,

  --enable-libstdcxx-time=rt

also checks -lrt which is not needed on musl,
but harmless (i guess it's an option so by
default libstdc++ avoids the -lrt dependency).

the default is =auto which hard-codes some
nonsense based on glibc version, we can fix
that for gcc-11 and them musl works without
magic options.

[musl] [RFC] [PATCH] removing __NR_clock_gettime / SYS_clock_gettime

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Sun, Jan 19, 2020 at 11:36:16AM -0500, Rich Felker wrote:
> 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?

Patch attached.

Rich

[-- Attachment #2: remove_gtod32.diff --]
[-- Type: text/plain, Size: 7664 bytes --]

diff --git a/arch/arm/bits/syscall.h.in b/arch/arm/bits/syscall.h.in
index 8ab5df1d..4d844e57 100644
--- a/arch/arm/bits/syscall.h.in
+++ b/arch/arm/bits/syscall.h.in
@@ -55,7 +55,7 @@
 #define __NR_sethostname	74
 #define __NR_setrlimit	75
 #define __NR_getrusage	77
-#define __NR_gettimeofday	78
+#define __NR_gettimeofday_time32	78
 #define __NR_settimeofday	79
 #define __NR_getgroups	80
 #define __NR_setgroups	81
@@ -216,7 +216,7 @@
 #define __NR_timer_getoverrun	260
 #define __NR_timer_delete	261
 #define __NR_clock_settime	262
-#define __NR_clock_gettime	263
+#define __NR_clock_gettime32	263
 #define __NR_clock_getres	264
 #define __NR_clock_nanosleep	265
 #define __NR_statfs64	266
diff --git a/arch/i386/bits/syscall.h.in b/arch/i386/bits/syscall.h.in
index bb841677..a96317c0 100644
--- a/arch/i386/bits/syscall.h.in
+++ b/arch/i386/bits/syscall.h.in
@@ -76,7 +76,7 @@
 #define __NR_setrlimit		 75
 #define __NR_getrlimit		 76   /* Back compatible 2Gig limited rlimit */
 #define __NR_getrusage		 77
-#define __NR_gettimeofday	 78
+#define __NR_gettimeofday_time32	 78
 #define __NR_settimeofday	 79
 #define __NR_getgroups		 80
 #define __NR_setgroups		 81
@@ -262,7 +262,7 @@
 #define __NR_timer_getoverrun	(__NR_timer_create+3)
 #define __NR_timer_delete	(__NR_timer_create+4)
 #define __NR_clock_settime	(__NR_timer_create+5)
-#define __NR_clock_gettime	(__NR_timer_create+6)
+#define __NR_clock_gettime32	(__NR_timer_create+6)
 #define __NR_clock_getres	(__NR_timer_create+7)
 #define __NR_clock_nanosleep	(__NR_timer_create+8)
 #define __NR_statfs64		268
diff --git a/arch/m68k/bits/syscall.h.in b/arch/m68k/bits/syscall.h.in
index e7f71a5d..e70d3472 100644
--- a/arch/m68k/bits/syscall.h.in
+++ b/arch/m68k/bits/syscall.h.in
@@ -67,7 +67,7 @@
 #define __NR_setrlimit		 75
 #define __NR_getrlimit		 76
 #define __NR_getrusage		 77
-#define __NR_gettimeofday	 78
+#define __NR_gettimeofday_time32	 78
 #define __NR_settimeofday	 79
 #define __NR_getgroups		 80
 #define __NR_setgroups		 81
@@ -240,7 +240,7 @@
 #define __NR_timer_getoverrun	257
 #define __NR_timer_delete	258
 #define __NR_clock_settime	259
-#define __NR_clock_gettime	260
+#define __NR_clock_gettime32	260
 #define __NR_clock_getres	261
 #define __NR_clock_nanosleep	262
 #define __NR_statfs64		263
diff --git a/arch/microblaze/bits/syscall.h.in b/arch/microblaze/bits/syscall.h.in
index afefb354..b23fe6ef 100644
--- a/arch/microblaze/bits/syscall.h.in
+++ b/arch/microblaze/bits/syscall.h.in
@@ -76,7 +76,7 @@
 #define __NR_setrlimit 75
 #define __NR_getrlimit 76
 #define __NR_getrusage 77
-#define __NR_gettimeofday 78
+#define __NR_gettimeofday_time32 78
 #define __NR_settimeofday 79
 #define __NR_getgroups 80
 #define __NR_setgroups 81
@@ -260,7 +260,7 @@
 #define __NR_timer_getoverrun 262
 #define __NR_timer_delete 263
 #define __NR_clock_settime 264
-#define __NR_clock_gettime 265
+#define __NR_clock_gettime32 265
 #define __NR_clock_getres 266
 #define __NR_clock_nanosleep 267
 #define __NR_statfs64 268
diff --git a/arch/mips/bits/syscall.h.in b/arch/mips/bits/syscall.h.in
index 7f9afaab..e3f2de31 100644
--- a/arch/mips/bits/syscall.h.in
+++ b/arch/mips/bits/syscall.h.in
@@ -76,7 +76,7 @@
 #define __NR_setrlimit               4075
 #define __NR_getrlimit               4076
 #define __NR_getrusage               4077
-#define __NR_gettimeofday            4078
+#define __NR_gettimeofday_time32            4078
 #define __NR_settimeofday            4079
 #define __NR_getgroups               4080
 #define __NR_setgroups               4081
@@ -261,7 +261,7 @@
 #define __NR_timer_getoverrun        4260
 #define __NR_timer_delete            4261
 #define __NR_clock_settime           4262
-#define __NR_clock_gettime           4263
+#define __NR_clock_gettime32           4263
 #define __NR_clock_getres            4264
 #define __NR_clock_nanosleep         4265
 #define __NR_tgkill                  4266
diff --git a/arch/mipsn32/bits/syscall.h.in b/arch/mipsn32/bits/syscall.h.in
index 134a4f81..d13fda12 100644
--- a/arch/mipsn32/bits/syscall.h.in
+++ b/arch/mipsn32/bits/syscall.h.in
@@ -92,7 +92,7 @@
 #define __NR_fchown			6091
 #define __NR_lchown			6092
 #define __NR_umask			6093
-#define __NR_gettimeofday		6094
+#define __NR_gettimeofday_time32		6094
 #define __NR_getrlimit			6095
 #define __NR_getrusage			6096
 #define __NR_sysinfo			6097
@@ -224,7 +224,7 @@
 #define __NR_timer_getoverrun		6223
 #define __NR_timer_delete		6224
 #define __NR_clock_settime		6225
-#define __NR_clock_gettime		6226
+#define __NR_clock_gettime32		6226
 #define __NR_clock_getres		6227
 #define __NR_clock_nanosleep		6228
 #define __NR_tgkill			6229
diff --git a/arch/or1k/bits/syscall.h.in b/arch/or1k/bits/syscall.h.in
index eaa1a935..82d94b29 100644
--- a/arch/or1k/bits/syscall.h.in
+++ b/arch/or1k/bits/syscall.h.in
@@ -112,7 +112,7 @@
 #define __NR_timer_settime 110
 #define __NR_timer_delete 111
 #define __NR_clock_settime 112
-#define __NR_clock_gettime 113
+#define __NR_clock_gettime32 113
 #define __NR_clock_getres 114
 #define __NR_clock_nanosleep 115
 #define __NR_syslog 116
@@ -168,7 +168,7 @@
 #define __NR_umask 166
 #define __NR_prctl 167
 #define __NR_getcpu 168
-#define __NR_gettimeofday 169
+#define __NR_gettimeofday_time32 169
 #define __NR_settimeofday 170
 #define __NR_adjtimex 171
 #define __NR_getpid 172
diff --git a/arch/powerpc/bits/syscall.h.in b/arch/powerpc/bits/syscall.h.in
index d8b6a247..14cf79c6 100644
--- a/arch/powerpc/bits/syscall.h.in
+++ b/arch/powerpc/bits/syscall.h.in
@@ -76,7 +76,7 @@
 #define __NR_setrlimit               75
 #define __NR_getrlimit               76
 #define __NR_getrusage               77
-#define __NR_gettimeofday            78
+#define __NR_gettimeofday_time32            78
 #define __NR_settimeofday            79
 #define __NR_getgroups               80
 #define __NR_setgroups               81
@@ -243,7 +243,7 @@
 #define __NR_timer_getoverrun       243
 #define __NR_timer_delete           244
 #define __NR_clock_settime          245
-#define __NR_clock_gettime          246
+#define __NR_clock_gettime32          246
 #define __NR_clock_getres           247
 #define __NR_clock_nanosleep        248
 #define __NR_swapcontext            249
diff --git a/arch/sh/bits/syscall.h.in b/arch/sh/bits/syscall.h.in
index 4e9ae2e0..5c24f4a6 100644
--- a/arch/sh/bits/syscall.h.in
+++ b/arch/sh/bits/syscall.h.in
@@ -67,7 +67,7 @@
 #define __NR_setrlimit              75
 #define __NR_getrlimit              76
 #define __NR_getrusage              77
-#define __NR_gettimeofday           78
+#define __NR_gettimeofday_time32           78
 #define __NR_settimeofday           79
 #define __NR_getgroups              80
 #define __NR_setgroups              81
@@ -236,7 +236,7 @@
 #define __NR_timer_getoverrun       262
 #define __NR_timer_delete           263
 #define __NR_clock_settime          264
-#define __NR_clock_gettime          265
+#define __NR_clock_gettime32          265
 #define __NR_clock_getres           266
 #define __NR_clock_nanosleep        267
 #define __NR_statfs64               268
diff --git a/src/internal/syscall.h b/src/internal/syscall.h
index d768fb64..0b61f34e 100644
--- a/src/internal/syscall.h
+++ b/src/internal/syscall.h
@@ -193,6 +193,13 @@ hidden long __syscall_ret(unsigned long),
 #define SYS_sendfile SYS_sendfile64
 #endif
 
+#ifndef SYS_clock_gettime
+#define SYS_clock_gettime SYS_clock_gettime32
+#endif
+
+#ifndef SYS_gettimeofday
+#define SYS_gettimeofday SYS_gettimeofday_time32
+#endif
 
 /* Ensure that the plain syscall names are defined even for "time64-only"
  * archs. These facilitate callers passing null time arguments, and make