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:	Wed, 18 May 2011 11:55:39 +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, Denys.

On Wed, May 18, 2011 at 02:40:56AM +0200, Denys Vlasenko wrote:
> This makes PTRACE_EVENT_STOP similar to other PTRACE_EVENTs.
> The only difference is that it can't be set by PTRACE_SETOPTIONS
> as other events do, but activated implicitly by PTRACE_SEIZE.

Also by PTRACE_INTERRUPT and group stop.

> This made me thinking.
> 
> How about making API even more similar to existing one?
> 
> Create PTRACE_O_TRACESTOP, make it settable by PTRACE_SETOPTIONS too.
> 
> Make PTRACE_SEIZE take the mask of PTRACE_O_xyz flags
> as data argument.
> If PTRACE_O_TRACESTOP is set, it works as you described above.
> If PTRACE_O_TRACESTOP is not set, then it works as good old PTRACE_ATTACH.
> In both cases, immediately at attach it sets opts a-la PTRACE_SETOPTIONS.
>
> We can even avoid introducing PTRACE_SEIZE at all, because
> currently PTRACE_ATTACH ignores its data argument.
> 
> I know, I know, "this changes API", but did we ever promise
> that PTRACE_ATTACH with nonzero data arg is a valid usage?
> Also, I perused first 10 pages of google code search results
> and I see that everybody passes 0 or NULL.

But as SEIZE introduces behavior differences throughout ptrace
operation, I think it's actually beneficial to use a distinctively new
request.  It's not like it costs anything or we're short on request
number space.

Similar issue with PTRACE_O_TRACESTOP.  It won't only enable TRACESTOP
it will change other behaviors too and I think allowing clearing the
option while attached would open up a lot of new issues without much
benefit.  Making it a PTRACE_O_ flag and not allowing clearing is
weird too.

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?

So, if we do that, there would be a clear separation between SEIZE and
INTERRUPT and there wouldn't be any reason to make SEIZE to set
PTRACE_O_ options or whatever.  It just attaches and the rest can be
done with appropriate requests.  SEIZE might not be the best name with
this functionality but I think ATTACH_NOINTERRUPT would be too
confusing in that it implies that the only difference is not
interrupting.  Can somebody think of a better verb?

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/