linux-kernel - Re: [RFC 02/32] uapi: add struct __kernel

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: <5388E7A5.90308@zytor.com>
Date:	Fri, 30 May 2014 13:18:45 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
CC:	linux-arch@...r.kernel.org, joseph@...esourcery.com,
	john.stultz@...aro.org, hch@...radead.org, tglx@...utronix.de,
	geert@...ux-m68k.org, lftan@...era.com,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC 02/32] uapi: add struct __kernel_timespec{32,64}

On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> We cannot use time_t or any derived structures beyond the year
> 2038 in interfaces between kernel and user space, on 32-bit
> machines.
> 
> This is my suggestion for how to migrate syscall and ioctl
> interfaces: We completely phase out time_t, timeval and timespec
> from the uapi header files and replace them with types that are
> either explicitly safe (__kernel_timespec64), or explicitly
> unsafe (e.g. __kernel_timespec32). For each unsafe interface,
> there needs to be a safe replacement interface.
> 

This gets really messy for structures where this is ABI-dependent.  I'm
not sure this is a net win.

> +/*
> + * __kernel_timespec64 is the general type to be used for
> + * new user space interfaces passing a time argument.
> + * 64-bit nanoseconds is a bit silly, but the advantage is
> + * that it is compatible with the native 'struct timespec'
> + * on 64-bit user space. This simplifies the compat code.
> + */
> +struct __kernel_timespec64 {
> +	long long tv_sec;
> +	long long tv_nsec;
> +};

So it seems that it is not just POSIX that is drain bramaged with this,
but the "long" type for tv_nsec idiocy has made it into the C11
standard.  This unfortunately means that now there are two standards
bodies involved, at least one of which moves very slowly.

This makes me wonder if we don't need to deal with the problem in the
case of 32-bit ABIs with 64-bit time_t.  The logical thing seems to be
to EITHER:

a. ALWAYS ignore the upper 32 bits of tv_nsec when read from user space,
   but always set them to zero, or
b. Only ignore the upper 32 bits of tv_nsec when we are known to come
   from a 32-bit ABI context, but still always return zero.  These bits
   are already only used for validity checking.

   This most likely introduces a whole lot of new tests in deep paths,
   although we probably can centralize this in a single function, which
   otherwise ends up looking a lot like compat_get_timespec().

Getting rid of struct timespec on the kernel/user boundary is probably
not really feasible.

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