linux-kernel - mmtimer - posixtimer abuse

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

Date:	Thu, 29 Sep 2011 00:33:35 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dimitri Sivanich <sivanich@....com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	John Stultz <johnstul@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject:  mmtimer - posixtimer abuse

Dimitry,

I'm fixing a few odds and ends in the posix timer code and stumbled
over drivers/char/mmtimer.c

I have seen lots of crap in my life, but this stuff is broken beyond
everything.

1) Locking issues vs. timer delivery, i.e. posix_timer_event() is
   called w/o tmr->it_lock held.

2) overrun accounting for periodic timers is completely broken

3) timer_del() can deadlock

4) clock_set()/clock_get()

   What the hell are you doing with that offset? It's just used in
   those functions - of course unlocked and has nothing to with the
   actual expiry time of the timers.

   What's the point of this ????

5) The whole notion of struct mmtimer is completely ass backwards

   Instead of adding the proper fields to k_itimer.it.mmtimer you
   allocate a separate data structure with separate lifetime rules.

   That makes you do a reverse lookup dance through the rbtree in
   timer_del() and random points where you actually kfree that extra
   thing.

6) As far as I can tell from looking at timer_set() this clock tries
   to resemble CLOCK_REALTIME, but lacks any checks of timers expiring
   early. It does not handle when the clock was set 

7) Periodic timers are subject to random rounding errors and the
   MMTIMER_INTERVAL_RETRY_INCREMENT_DEFAULT hackery which was
   introduced in commit dcade5ed16 just proves how broken that whole
   thing is. Why the hell does it not rearm the timers in the signal
   delivery path and do proper forwarding instead of using disgusting
   heuristics to work around the rounding problems.

7) Why is that using a tasklet? 

8) Why does it expire each timer seperately instead of looking at all
   expired timers and bulk expire them.

Is actually anyone using this trainwreck or can we simply kill it
entirely?

If it's used and wants to be supported, then please explain what the
properties of CLOCK_SGI should be, so we can fix that mess.

Please do that fast, as I don't see any reason to hold off
improvements and fixes for the core and the sane users for something
which should have never been merged in the first place.

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/