Re: [PATCH] Read THREAD_CPUTIME clock from other processes.

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]