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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 08 Jan 2011 12:12:23 +0100
From:	Dario Faggioli <raistlin@...ux.it>
To:	Roland McGrath <roland@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	torbenh <torbenh@....de>, oleg <oleg@...hat.com>,
	john.stultz@...aro.org, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] Read THREAD_CPUTIME clock from other  processes.

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@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)