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]

Date:	Thu, 19 May 2011 16:17:28 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	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

Hello,

On Wed, May 18, 2011 at 11:55:39AM +0200, Tejun Heo wrote:
> I've been thinking about Jan's suggestion to make ATTACH and DETACH
> not require tracee to trap.  We already have this for DETACH for cases
> where the tracer is killed and it seems it wouldn't be too difficult
> to make that happen for ATTACH either and for that to be truly useful
> I suppose PTRACE_SETOPTIONS shouldn't require trapped state either.
> Jan, would that be enough for the use cases you have on mind?

I've been trying this and clean DETACH requires the tracee to be
trapped (or not running).  The arch detach hook, which BTW is not
executed when the tracer is killed, modifies tracee state expecting it
to be off-cpu.

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?

Thanks.

-- 
tejun
--
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/