| Message ID | 5a093bb5-85af-7f76-0ee9-8a3f1d26d8ea@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add NEWS entry about 64-bit time_t syscall use on 32-bit targets | expand |
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
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?).
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.
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?)
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
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