linux-kernel - Re: [PATCH 03/10] ptrace: implement PTRACE

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: <201105192031.33569.pedro@codesourcery.com>
Date:	Thu, 19 May 2011 20:31:33 +0100
From:	Pedro Alves <pedro@...esourcery.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>, oleg@...hat.com,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

On Thursday 19 May 2011 15:17:28, Tejun Heo wrote:
> But making SEIZE not trigger INTERRUPT and SETOPTIONS without
> requiring TRACED don't seem too difficult.  Jan, would that be enough?
> Oleg, what do you think?

UUIC, that opens a race where between SEIZEing and
SETOPTIONS(O_TRACE FORK|VFORK|EXEC...), the tracee can
fork/vfork/clone/exec, without the tracer getting the
nice corresponding PTRACE_EVENT_ events.

In GDBs case, GDB will want to poke at memory
right after attaching, to at least read the
loaded DSO list, so if you can't read tracee
memory without interrupting it, you won't get much
benefit from SEIZE not interrupting.
Not to say other users wouldn't benefit.

-- 
Pedro Alves
--
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/