linux-kernel - Re: Q: sys_futex() && timespec

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]

Date:	Fri, 25 Jun 2010 22:25:31 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ulrich Drepper <drepper@...hat.com>
cc:	Darren Hart <dvhltc@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andreas Schwab <schwab@...hat.com>,
	Danny Feng <dfeng@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>, linux-kernel@...r.kernel.org,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Q: sys_futex() && timespec_valid()

On Fri, 25 Jun 2010, Ulrich Drepper wrote:

> ----- "Thomas Gleixner" <tglx@...utronix.de> wrote:
> > tv->sec < 0 is definitely an invalid value for both CLOCK_REALTIME
> > and CLOCK_MONOTONIC.

> CLOCK_MONOTONIC is different but it's wrong for CLOCK_REALTIME.

Why is CLOCK_MONOTONIC any different ? According to you argumentation
it's just _BEFORE_ we started the system.

> Why would it be invalid?  Because times before Epoch will not be
> used?  By that logic you would have to declare all values before
> Linus' first running kernel as invalid.  None of this makes sense.

That's utter bullshit and you know that. Every system which does not
have an RTC starts with the EPOCH and the range check is correct in
the terms of the specification:

    Outside the valid range of the clock_id.

The kernel treats the range valid which it can theoretically hand back
to user space:

   EPOCH <= CLOCK_REALTIME <= Y2038_or_far_away

   0 <= CLOCK_MONOTONIC <= far_away

> The tv_sec in timespec is of type time_t and for absolute time
> values the same semantics as for naked time_t values applies.  The
> absolute time is
>   epoch + tv_sec + tv_nsec / 1000000000
> 
> If tv_sec is negative these are values before epoch.
> 
> If there are other interfaces with absolute timeouts they certainly
>  should be changed as well.

If we'd change that, then we'd need to allow negative relative
timeouts as well and not restrict it to CLOCK_REALTIME. 

If we'd change the notion of "valid" then we do it in a consistent
way for everything not just for a corner case of some glibc wreckage.

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/