Messages in this thread | | | Subject | Re: [PATCH] Read THREAD_CPUTIME clock from other processes. | From | Dario Faggioli <> | Date | Sat, 08 Jan 2011 12:12:23 +0100 |
| |
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] | |