lkml.org 
[lkml]   [2011]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Read THREAD_CPUTIME clock from other processes.
Date
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. 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.

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.

This can certainly be enhanced, but it opens some cans of worms about the
security question. It is probably still considered an unsafe information
leak to let every process examine every other process's thread clocks.
I'll leave that judgement to security folks. The intermediate route of
conversatism is to allow it only for processes owned by the same user,
which has some complexities with races between UID changes and clock/timer
calls.

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.


Thanks,
Roland


\
 
 \ /
  Last update: 2011-01-07 20:31    [from the cache]
©2003-2011 Jasper Spaans