lkml.org 
[lkml]   [2011]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Read THREAD_CPUTIME clock from other processes.
From
Date
On Fri, 2011-01-07 at 11:28 -0800, Roland McGrath wrote: 
> clock_getcpuclockid is the POSIX interface for using a process-wide CPU
> clock. pthread_getcpuclockid is the POSIX interface for using a
> thread-specific CPU clock. There is no POSIX interface for using the
> thread-specific clock of a thread in a different process because POSIX does
> not have the notion of global identification of threads at all.
>
Sure, even just the fact that the tid is involved makes it unequivocally
a Linux extension to such interface.

> The very
> idea that you could know anything about an individual thread in a different
> process is a Linuxism. If you want to do something like that, then there
> is no reason to use the POSIX standard interfaces rather than just using
> the Linux-specific clockid_t generation macros in the first place.
>
And I'm perfectly fine with this, if there's a consensus around it! :-)

The whole point is that this is not possible right now, since the
clockid_t generators are not accessible from userspace... Should I go
for this?

> When the CPU clock interfaces were introduced to the kernel, it was
> considered a potential security issue (information leak) to be able to
> access the thread clocks of another process, because there had never been a
> way for one process to access such information from another process before.
> We took the conservative route of permitting it only within the same
> process.
>
That crossed my mind as well (I think I mentioned at least in one of the
e-mail if not in the changelog). Then I thought that if it's possible to
access an arbitrary process' CPU timer, why it shouldn't be possible to
access the one of an arbitrary thread... But, as you, I'm not a
"security guy", and I would be the first one to suggest to drop this if
it is considered a security risk! :-)

> As well as the information leak, it is most certainly a DoS attack vector
> to allow one process to set CPU timers an another process or its threads.
> Setting timers causes the timed thread itself to do work proportional to
> the number of timers set.
>
Yep, but as said, no room for timer setting, neither with or without the
patch, due to the nature of the clock itlsef.

Thanks,
Dario

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)

http://retis.sssup.it/people/faggioli -- dario.faggioli@jabber.org
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2011-01-08 12:41    [W:0.174 / U:1.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site