linux-kernel - Re: [PATCH] [RFC] time: Improve negative offset handling in timekeeping_inject

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] [day] [month] [year] [list]

Date:	Tue, 25 Feb 2014 10:14:52 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Prarit Bhargava <prarit@...hat.com>
Subject: Re: [PATCH] [RFC] time: Improve negative offset handling in
 timekeeping_inject_offset

On Fri, Feb 21, 2014 at 11:54:35PM +0100, Thomas Gleixner wrote:
> To be honest, it's not the prettiest thing, but timespec is not pretty
> to begin with.

yes...

> Sure our normalize function can cope with that, but where is the
> point?

and yes...

> Now if we allow that we also need to allow
> 
>         5, -987654321
> 
> versus
> 
> 	4,   12345679
> 
> It's all unreadable in one way or the other. 

and again yes...

> Aside of that, if we allow that for adjtimex, then how do we argue the
> restriction on all other timespec related interfaces?

(John already heard my opinion off list, but I would so much like to
state it again ;)

The timespec was already an ugly thing, even before we added the
ADJ_SETOFFSET. Our addition means that timespecs can also be negative
values, but no matter how you define it, someone will think another
way is more natural.

When implementing the clock shifting code in linuxptp, I simply followed
the existing "rule" that tv_nsec is non-negative, and so that program
just normalizes the timespec to make the kernel happy.

I think we should just leave the kernel/user interfaces as is because,

1. Applications can deal with the "rule" as is. It isn't hard. After
   all, making the clock jump is an unusual thing to do in any case.
2. The "rule" is consistent with existing posix interfaces.
3. The kernel actually outputs timespecs in this way.

When I first looked at this from the user space POV, I took the
trouble to shift the clock back before 1970 in order to watch the
kernel timespecs counting down (or up?). Yes, it is weird, but the
nanoseconds field decreases as time goes forward.

[ You used to be able to do this before:
  4e8b1452 "time: Improve sanity checking of timekeeping inputs" ]

My two Euro-Cents,
Richard
--
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/