linux-kernel - Re: [PATCH 1/7] tools/nolibc: remove __nolibc_enosys() fallback from time64-related functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5b8344e-8214-4946-8344-f34e969d30b2@t-8ch.de>
Date: Mon, 6 Oct 2025 22:14:26 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Arnd Bergmann <arnd@...db.de>
Cc: Willy Tarreau <w@....eu>, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, shuah <shuah@...nel.org>, Mark Brown <broonie@...nel.org>, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 1/7] tools/nolibc: remove __nolibc_enosys() fallback from
 time64-related functions

Hi Arnd,

On 2025-10-01 09:43:37+0200, Arnd Bergmann wrote:
> On Thu, Aug 21, 2025, at 17:40, Thomas Weißschuh wrote:
> > These fallbacks where added when no explicit fallbacks for time64 was
> > implemented. Now that these fallbacks are in place, the additional
> > fallback to __nolibc_enosys() is superfluous.
> >
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> 
> I just saw these fly by as they made it into mainline and
> I noticed that there is still something wrong here:
> 
> > @@ -39,10 +39,8 @@ int sys_poll(struct pollfd *fds, int nfds, int 
> > timeout)
> >  		t.tv_nsec = (timeout % 1000) * 1000000;
> >  	}
> >  	return my_syscall5(__NR_ppoll_time64, fds, nfds, (timeout >= 0) ? &t 
> > : NULL, NULL, 0);
> > -#elif defined(__NR_poll)
> > -	return my_syscall3(__NR_poll, fds, nfds, timeout);
> >  #else
> > -	return __nolibc_enosys(__func__, fds, nfds, timeout);
> > +	return my_syscall3(__NR_poll, fds, nfds, timeout);
> >  #endif
> >  }
> 
> The change is fine, as there is always at least one of the
> time64 or the old syscalls implemented, for any of the affected
> calls.
> 
> However, the problem here is the default to the old time
> types on 32-bit targets, for two reasons:
> 
>  - this fails when turning off CONFIG_COMPAT_32BIT_TIME

Good point.

>  - the old types are often too short, both for the y2038
>    overflow and for the file system types.

So far this was not something we actively tried to support,
especially with the restriction mentioned below.

> I suspect the problem is that the kernel's uapi/linux/time.h
> still defines the old types as the default, and nolibc
> historically just picks it up from there.

So far we have tried to keep nolibc compatible with the kernel UAPI when
included in any order. This forced us to use 'struct timespec' from
uapi/linux/time.h. With the upcoming implementation of signals in nolibc
this guideline is relaxed a bit, so we should be able to use our own
always-64-bit 'struct timespec'.

> The proper solution I think would be to do the same thing
> that klibc has and use sane defaults for all the types
> along with the modern syscalls. At least __kernel_time_t,
> __kernel_timespec, __kernel_ino_t, __kernel_loff_t and
> probably a few more.

Thanks for the pointers and ack to all of them.
I'll take a look at those.

> We should also consider drop the
> legacy type definitions from uapi/linux/time.h and
> require each libc to define their own.

Can we even just drop them? Or should they also get some backwards
compat guards?


Thomas