linux-kernel - Re: [klibc] kernel/libc uapi changes for y2038

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: <5565E2AC.3070306@zytor.com>
Date:	Wed, 27 May 2015 08:28:44 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Arnd Bergmann <arnd@...db.de>, linux-api@...r.kernel.org
CC:	klibc@...or.com, libc-alpha@...rceware.org, y2038@...ts.linaro.org,
	musl@...ts.openwall.com, linux-kernel@...r.kernel.org,
	Rich Felker <dalias@...c.org>, cferris@...gle.com,
	enh@...gle.com, "Joseph S. Myers" <joseph@...esourcery.com>
Subject: Re: [klibc] kernel/libc uapi changes for y2038

On 05/18/2015 02:53 AM, Arnd Bergmann wrote:
> In the patch series I posted recently [1], I introduce new system calls to deal
> with modified data structures, but left the question open on how these should
> be best accessed from libc. The patches introduce a new __kernel_time64_t type
> and based on that five new data structured: struct __kernel_timespec,
> struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage,
> and struct __kernel_timex. This works fine for the case when all libc
> implementations provide their own definitions to user space, but not for
> the simplest case (e.g. klibc) where the user-visible structures come directly
> from the kernel uapi headers.
> 
> I still don't know what model the various libc developers prefer, so here is
> an alternative approach, as a patch on top of the previous series:
> 
> Now, we rename the original structures to struct __old_kernel_*, and use a
> macro to define either the __old_kernel_* or the __kernel_* structure name
> to the name we actually want in user space, based on a __KERNEL_TIME_BITS
> macro that can be set to either 32 or 64 for 32-bit architectures by
> the libc. Depending on that macro, the compiler will either see one
> of these combinations (for each of the five structures):
> 
> a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32:
> 
>    struct timespec              based on 32-bit __kernel_time_t
>    struct __kernel_timespec     based on 64-bit __kernel_time64_t
> 
> b) __BITS_PER_LONG == 64 && __KERNEL_TIME_BITS == 64:
> 
>    struct timespec              based on 64-bit __kernel_time_t
>    struct __kernel_timespec     based on 64-bit __kernel_time64_t
> 
> c) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 64:
> 
>    struct __old_kernel_timespec based on 32-bit __kernel_time_t
>    struct timespec              based on 64-bit __kernel_time64_t
> 
> Would this work for everyone?  Any alternative suggestions?
> 

It seems to work, except I don't really understand why there is a
difference between (b) and (c).

I also have no problem just having klibc contain its own definitions of
these structures, as long as one can prevent the kernel from defining them.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/