diff mbox

Add NEWS entry about 64-bit time_t syscall use on 32-bit targets

Message ID 5a093bb5-85af-7f76-0ee9-8a3f1d26d8ea@arm.com
State Committed
Headers

Commit Message

Szabolcs Nagy Jan. 30, 2020, 11:02 a.m. UTC 
  i've seen this causing problems at various places
already so i'd like to add a note about it in 2.31

Comments

Siddhesh Poyarekar Jan. 30, 2020, 2:33 p.m. UTC | #1 
On 30/01/20 4:32 pm, Szabolcs Nagy wrote:
> i've seen this causing problems at various places
> already so i'd like to add a note about it in 2.31
>

How about the following wording:

* On 32-bit targets, wrappers for the new time64 system calls in the GNU
C Library call the older 32-bit time system calls as a fallback if the
new system call fails due to not being implemented in the currently
running kernel.  This may cause issues in environments that cannot
handle new Linux system calls gracefully by returning -ENOSYS. Seccomp
sandboxes are affected by this issue.

Siddhesh
Szabolcs Nagy Jan. 30, 2020, 4:05 p.m. UTC | #2 
On 30/01/2020 14:33, Siddhesh Poyarekar wrote:
> 

> 

> On 30/01/20 4:32 pm, Szabolcs Nagy wrote:

>> i've seen this causing problems at various places

>> already so i'd like to add a note about it in 2.31

>>

> 

> How about the following wording:

> 

> * On 32-bit targets, wrappers for the new time64 system calls in the GNU

> C Library call the older 32-bit time system calls as a fallback if the

> new system call fails due to not being implemented in the currently

> running kernel.  This may cause issues in environments that cannot

> handle new Linux system calls gracefully by returning -ENOSYS. Seccomp

> sandboxes are affected by this issue.


i don't want to bikeshed the news entry, but
this wording does not convey that the use of
time64 syscalls throughout glibc internally is
what is new, only that some fallback code has
known compatibility issues. (users don't know
what impact "wrappers for time64 syscalls" have)

in any case i'm happy if the issue is mentioned
in the news in one way or another (or maybe this
sort of thing goes into release notes on the wiki?).
Siddhesh Poyarekar Jan. 30, 2020, 4:36 p.m. UTC | #3 
On 30/01/20 9:35 pm, Szabolcs Nagy wrote:
> i don't want to bikeshed the news entry, but

I think it's important to get the colour of this bike shed right :)

> this wording does not convey that the use of
> time64 syscalls throughout glibc internally is
> what is new, only that some fallback code has
> known compatibility issues. (users don't know
> what impact "wrappers for time64 syscalls" have)

OK got it.  How is this then:

~~~
System call wrappers for time system calls now use the new time64 system
calls when available. On 32-bit targets, these wrappers attempt to call
the new system calls first and fall back to the older 32-bit time system
calls if they are not present.  This may cause issues in environments
that cannot handle unsupported system calls gracefully by returning
-ENOSYS. Seccomp sandboxes are affected by this issue.
~~~

> in any case i'm happy if the issue is mentioned
> in the news in one way or another (or maybe this
> sort of thing goes into release notes on the wiki?).
> 

The NEWS becomes part of the published release notes.
Szabolcs Nagy Jan. 31, 2020, 9:30 a.m. UTC | #4 
On 30/01/2020 16:36, Siddhesh Poyarekar wrote:
> OK got it.  How is this then:

> 

> ~~~

> System call wrappers for time system calls now use the new time64 system

> calls when available. On 32-bit targets, these wrappers attempt to call

> the new system calls first and fall back to the older 32-bit time system

> calls if they are not present.  This may cause issues in environments

> that cannot handle unsupported system calls gracefully by returning

> -ENOSYS. Seccomp sandboxes are affected by this issue.

> ~~~


looks ok to me.
thanks.
(will you do the commit?)
Siddhesh Poyarekar Jan. 31, 2020, 9:51 a.m. UTC | #5 
On 31/01/20 15:00, Szabolcs Nagy wrote:
> looks ok to me.
> thanks.
> (will you do the commit?)
> 

Please go ahead and commit, there's still a couple of hours for the freeze.

Thanks,
Siddhesh
diff mbox

Patch

From caabacea4e334b0eddc11f3a3b911fc8b482730f Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Thu, 30 Jan 2020 10:40:01 +0000
Subject: [PATCH] Add NEWS entry about 64-bit time_t syscall use on 32-bit
 targets

This internal change ideally should not affect the public API or ABI,
but there is a widespread use of seccomp sandboxes, even on 32-bit
targets, that don't handle new Linux syscall usage well, so it's
worth mentioning in the NEWS.
---
 NEWS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/NEWS b/NEWS
index 10814ef283..f0c6b2eb0f 100644
--- a/NEWS
+++ b/NEWS
@@ -124,6 +124,11 @@  Deprecated and removed features, and other changes affecting compatibility:
   The GNU C Library can be built with --enable-kernel=4.8.0 in order to keep a
   non-executable stack while dropping support for older kernels.
 
+* On 32-bit targets new time64 Linux syscalls may be used with fallback logic
+  if they are not available, this may cause issues in environments that don't
+  handle new Linux syscalls nor fail them with ENOSYS, e.g. seccomp sandboxes
+  can be affected.
+
 Changes to build and runtime requirements:
 
 * It is no longer necessary to have recent Linux kernel headers to build
-- 
2.17.1