linux-kernel - Re: [patch 20/24] perfmon: system calls interface

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]

Message-ID: <7c86c4470811302205v86cf2e6j4e6d3131a8292cc4@mail.gmail.com>
Date:	Mon, 1 Dec 2008 07:05:21 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Paul Mackerras" <paulus@...ba.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, x86@...nel.org, andi@...stfloor.org,
	sfr@...b.auug.org.au, "Roland McGrath" <roland@...hat.com>,
	"Oleg Nesterov" <oleg@...hat.com>
Subject: Re: [patch 20/24] perfmon: system calls interface

Paul,

On Mon, Dec 1, 2008 at 1:49 AM, Paul Mackerras <paulus@...ba.org> wrote:
> stephane eranian writes:
>
>> Perfmon requires ptrace ONLY to stop the thread you want to operate
>> on. For instance, to read the counters in a thread via pfm_read(), you
>> need to have that thread stopped, so perfmon can extract the machine
>> state safely.
>
> What would happen if the thread wasn't stopped?  Is it just that the
> numbers would be inaccurate, or is there some kind of security
> exposure?
>
There are certain operations which cannot be performed, for instance
attaching/detaching.

As for read and write, sure you could never touch the PMU directly if you were
not self-monitoring. But then there is question as what does the
interface guarantee
in terms of execution of the actions. With read, you'd have to say the
interface does
not guarantee the value returned is up-to-date. For applications which
never context
switch, for instance, there the values read from the software state
maybe totally stale.

> If it's just that the numbers would be inaccurate, then I don't think
> the kernel needs to enforce it.  The monitoring program *should*
> ensure that the thread is stopped or blocked, one way or another, but
> it could do that simply by sending a SIGSTOP to the thread.  I don't
> see that it would necessarily have to use ptrace.
>
Because ptrace provides the additional guarantees, for instance,
nobody can do  a SIGCONT
while you are operating on the ptraced thread, nobody else can do the
PTRACE_DETATCH.
Now, I don't think bad things could actually happen if a SIGCONT were
to happen, because
the context is locked during all operations and the context switch in
routine tries to grab that
lock. There may be difficulties if you hold the lock and then you need
to release it for one operation
and then you grab it again. There may be a couple of places where we do that.

Also sending SIGSTOP is not enough to guarantee the thread is off of
the CPU. You need to wait
until it is actually off, i.e., all the state has been saved. I don't
think you can test that from userland.


Note that I am not arguing that we will have to use ptrace forever. In
fact, utrace provides the mechanisms
and the guarantees to avoid using ptrace alltogether. With utrace,
applications would directly call into the
kernel and then, if needed, the kernel would use utrace to stop the
other thread. I have played with that several
months ago and it worked fine. The problem is that utrace is still not in.
--
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/