linux-kernel - Re: [RFC] Per-thread getrusage

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Jan 2008 17:14:13 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Vinay Sridhar <vinay@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
	drepper@...hat.com, wli@...omorphy.com, akpm@...ux-foundation.org,
	sripathik@...ibm.com
Subject: Re: [RFC] Per-thread getrusage

I agree that RUSAGE_THREAD is fine.  (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction, rather than duplicating it.  In fact, here you go (next posting).

As to getting arbitrary other threads' data, there are several problems
there.  Adding a syscall is often more trouble than it's worth.  Ulrich
cited the issues with that as the API.  You also didn't handle compat for
it correctly.  To warrant the code necessary to make this available by
whatever API, I think you need to say some more about what it's needed for.

Off hand, it seems most in keeping with other things to expose this via a
/proc file, i.e. /proc/tgid/task/tid/rusage and (/proc/tgid/rusage for the
RUSAGE_SELF behavior on a foreign process).  There we already have the
infrastructure for dealing with the security issues uniformly with how we
control other similar information.  Personally I tend to prefer a binary
interface, i.e. a virtual file whose contents are struct rusage; for that
you still need to do the extra compat work, since a 32-bit process should
have the 32-bit struct rusage layout in its /proc files.  If you put the
numbers into ascii text as some /proc interfaces do, you don't need any
special considerations for CONFIG_COMPAT.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/