linux-kernel - Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k

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: <alpine.DEB.2.11.1504211528040.13914@nanos>
Date:	Tue, 21 Apr 2015 16:14:26 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	y2038@...ts.linaro.org, Baolin Wang <baolin.wang@...aro.org>,
	pang.xunlei@...aro.org, peterz@...radead.org,
	benh@...nel.crashing.org, heiko.carstens@...ibm.com,
	paulus@...ba.org, cl@...ux.com, heenasirwani@...il.com,
	linux-arch@...r.kernel.org, linux-s390@...r.kernel.org,
	mpe@...erman.id.au, rafael.j.wysocki@...el.com, ahh@...gle.com,
	fweisbec@...il.com, pjt@...gle.com, riel@...hat.com,
	richardcochran@...il.com, schwidefsky@...ibm.com,
	john.stultz@...aro.org, rth@...ddle.net,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, tj@...nel.org, linux390@...ibm.com,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods
 with timespec64 type for k_clock structure

On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > COMPAT_SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
> >                        struct compat_itimerspec __user *, setting)
> 
> As a side note, I want to kill off the get_fs()/set_fs() calls in
> the process. These always make me dizzy when I try to work out whether
> there is a potential security hole (there is not in this case), and
> they can be slow on some architectures.

Yeah. I have to take a deep breath every time I look at those :)
 
> My preferred solution is one where we end up with the same syscalls
> for both 32-bit and 64-bit, and basically use the
> compat_sys_timer_gettime() implementation (or a simplified version)
> for the existing , something like this:

No objections from my side. I was not looking into the syscall magic
yet. I just wanted to avoid the code churn and have the guts of the
syscalls factored out for simple reusage.

....
 
> Note the use of a separate __kernel_itimerspec64 for the user interface
> here, which I think will be needed to hide the differences between the
> normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit
> platforms that will be defined differently (using 'long long').

Confused.

timespec64 / itimerspec64 should be the same independent of 64bit and
32bit. So why do we need another variant ?

> I would also prefer not too many people to work on the syscalls, and
> would rather have Baolin not touch any of the syscall prototypes for
> the moment.

I did not ask him to change any of the syscall prototypes. I just
wanted him to split out the guts of the syscall into a seperate static
function to avoid all that code churn.

Thanks,

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