linux-kernel - Re: [PATCH] atmel_tc clocksource/clockevent code

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:	Wed, 5 Mar 2008 23:35:20 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Thomas Gleixner" <tglx@...utronix.de>
Cc:	"David Brownell" <david-b@...bell.net>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>,
	akpm@...ux-foundation.org, LKML <linux-kernel@...r.kernel.org>,
	"David Brownell" <dbrownell@...rs.sourceforge.net>,
	"Nicolas Ferre" <nicolas.ferre@....atmel.com>,
	"Andrew Victor" <linux@...im.org.za>,
	"john stultz" <johnstul@...ibm.com>
Subject: Re: [PATCH] atmel_tc clocksource/clockevent code

Hello Thomas,

>  > Attached I have put a screendump of my ETM debugger. It shows a
>  > complete flow of kernel function-calls of what happens on a timer
>  > interrupt. In this example the complete sequence takes about 154 us.
>  > Notice that the ETM is non-intrusive, and that the times are real and
>  > accurate in this trace. (you can even see the effects of CPU-caches,
>  > sometimes the same code just runs faster)
>
> Is there any chance to convert this to a text table? Following that
>  png is pretty hard.

I will see what I can do, but this was the easiest way (it was just a
print-screen;-) )
But, will text-dump make it more clear? It could also contain the time
each assembler instruction will take behind the routines...
But, I will look into that tomorrow. (approx. 12 hours from now)

>  > So, hires timestamps -> really really welcome.
>  > hires timers -> there should be a (configurable) minimal resolution
>  > that fits the hardware to not overload the CPU.
>
> clockevents let you set a minimum delta already. This can be set at
>  runtime before registering the device.

But, I want to expose a bigger risk here.
Apparently it is possible that a non privileged user can overload the
system easily, by starting a high frequency periodic timer. The system
will be that busy handling that timer that the system stops
responding, thus it will result in some kind of Denial-of-Service
situation, even on X86.

I think that there should be a hard limit to prevent starting timers
at higher frequencies than they can be handled by the platform,
included the scheduler overhead.

David has proposed a solution via the kernel-commandline, but I think
it should be a hard coded limit, to prevent that it is forgotten by
the end-user to put it on the kernel-cmd-line. Maybe a sub-option that
gets visible when HRT is enabled in menuconfig, this option should be
default very conservative, and the user should think about the lower
bound he really needs before he really gets HRT enabled.

What do you think of this? (I can propose a patch for this tomorrow)

Kind Regards,

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