linux-kernel - Re: [Y2038] [PATCH v4 06/25] time/posix-timers:Introduce {get, put}_timespec and {get, put}

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: <13035006.xRdC2jB7D9@wuerfel>
Date:	Thu, 04 Jun 2015 17:04:53 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Baolin Wang <baolin.wang@...aro.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [PATCH v4 06/25] time/posix-timers:Introduce {get, put}_timespec and {get, put}_itimerspec

On Tuesday 02 June 2015 21:20:08 Thomas Gleixner wrote:
> On Mon, 1 Jun 2015, Baolin Wang wrote:
> 
> > These are new helper functions that convert between a user timespec/
> > itimerspec and a kernel timespec64/itimerspec64 structure.
> 
> These are not functions, these are macros.
>  
> > These macros can change the types underneath from both ends and it
> > will work efficiently on both 32-bit and 64-bit that can avoid the
> > CONFIG_64BIT macro in syscall functions, and also it can make the
> > syscall functions more simple.
> 
> Lots of useless blurb which fails to explain WHY this works and WHY
> this magically converts the types.
> 
> And you fail to mention WHY dropping type safety is a good choice and
> WHY dropping the might_fault() check is a proper thing to do.
> 
> I also doubt the efficiency part as you replace a linear
> copy_to_user() with four seperate ones for an itimerspec.
>   
> This can be done proper with typesafe inline helpers, if you want to
> spare the ifdef in the syscall implementation.
> 

I suggested these macros on IRC, as a way to help coordinate Baolin's
series with my own patches that conver the entry points at first to
use __kernel_timespec equal to the normal timespec, and then changing
that type to be based on __kernel_time64_t.

Specifically, we otherwise need to deal with these combinations:

user timespec (32 bit), kernel timespec (32 bit)
user timespec (64 bit), kernel timespec (64 bit)
user timespec (32 bit), kernel timespec64 (64 bit)
user timespec (64 bit), kernel timespec64 (64 bit)
user __kernel_timespec (32 bit), kernel timespec (32 bit)
user __kernel_timespec (64 bit), kernel timespec (32 bit)
user __kernel_timespec (64 bit), kernel timespec (64 bit)
user __kernel_timespec (32 bit), kernel timespec64 (64 bit)
user __kernel_timespec (64 bit), kernel timespec64 (64 bit)

My existing patche series handles this with fully type-safe functions,
but causes more churn than using less safe functions, which can
handle all the combinations above.

We could also do untyped get/put functions based on copy_to_user
and copy_from_user, but I guess what you're after is more along the
lines of typed accessor functions like I had at first:

int get_timespec64(struct timespec64 *ts, const struct timespec __user *uts)
{
	struct timespec64 tmp;
	int ret;

	if (sizeof(tmp) == sizeof(*ts))
		return copy_from_user(&tmp, uts, sizeof(*ts)) ? -EFAULT : 0;

	ret = copy_from_user(&tmp, uts, sizeof(*ts));
	if (ret)
		return -EFAULT;

	ts->tv_sec = tmp.tv_sec;
	ts->tv_nsec = tmp.tv_nsec;

	return 0;
}

This works fine, but I'd have to change it to copy from a __user
__kernel_timespec instead of timespec in my system call series, and
in order to do that, we must ensure that I can change over all callers
at the same time, so with the function prototype above, we should not
start using get_timespec64 for anything outside of posix-timers.c.

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