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: <7c86c4470811270622s540a17d8r73462dfa93d1bc6d@mail.gmail.com>
Date:	Thu, 27 Nov 2008 15:22:29 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	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

Ingo,

On Wed, Nov 26, 2008 at 3:00 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> Thirdly, the check for ->exit_state in pfm_task_incompatible() is not
> needed: we've just passed ptrace_check_attach() so we know we just
> transitioned the task to task->state == TASK_TRACED.
>
> If you _ever_ see a task exit TASK_TRACED and go zombie or dead from
> there without this code allowing it that means the whole state machine
> with ptrace is borked up by perfmon. For example i dont see where the
> perfmon-control task parents itself as the exclusive debugger (parent)
> of the debuggee-task.
>

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. But when the monitored thread runs, it does not have to
remain under the control of ptrace. All that is needed  is that the thread
is stopped while we are in the perfmon syscall. I think ptrace allows this
today. We will be able to drop ptrace()  once we switch to utrace in which
case, the kernel will be able to easily stop the thread when entering the
perfmon syscalls. I guess I don't quite understand the meaning of your
last sentence.
--
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/