From: Roland McGrath <roland@redhat.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
torbenh <torbenh@gmx.de>, oleg <oleg@redhat.com>,
john.stultz@linaro.org, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] Read THREAD_CPUTIME clock from other processes.
Date: Fri, 7 Jan 2011 11:28:08 -0800 (PST) [thread overview]
Message-ID: <20110107192809.05CFF40467@magilla.sf.frob.com> (raw)
In-Reply-To: Dario Faggioli's message of Thursday, 23 December 2010 17:21:43 +0100 <1293121303.3390.185.camel@Palantir>
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
next prev parent reply other threads:[~2011-01-07 19:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-23 16:21 Dario Faggioli
2010-12-23 16:44 ` Oleg Nesterov
2010-12-23 17:38 ` Dario Faggioli
2010-12-23 18:12 ` Oleg Nesterov
2010-12-24 11:36 ` Dario Faggioli
2010-12-23 17:21 ` Randy Dunlap
2010-12-23 17:43 ` Dario Faggioli
2010-12-28 10:55 ` [PATCH resend] Reading POSIX CPU timer from outside the process Dario Faggioli
2010-12-28 16:38 ` Oleg Nesterov
2010-12-28 21:38 ` Dario Faggioli
2010-12-29 13:21 ` Oleg Nesterov
2010-12-29 14:10 ` Dario Faggioli
2010-12-29 18:30 ` Oleg Nesterov
2010-12-30 17:45 ` torbenh
2011-01-04 11:01 ` Dario Faggioli
2011-01-06 16:06 ` torbenh
2011-01-07 19:28 ` Roland McGrath [this message]
2011-01-07 19:35 ` [PATCH] Read THREAD_CPUTIME clock from other processes Oleg Nesterov
2011-01-07 19:50 ` Roland McGrath
2011-01-07 19:49 ` Oleg Nesterov
2011-01-07 19:58 ` Roland McGrath
2011-01-07 19:56 ` Peter Zijlstra
2011-01-08 11:12 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110107192809.05CFF40467@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
--cc=tglx@linutronix.de \
--cc=torbenh@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®