linux-kernel - Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and group stop notification, take#4

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:	Fri, 3 Jun 2011 10:24:45 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Oleg Nesterov <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,
	pedro@...esourcery.com
Subject: Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT and
 group stop notification, take#4

Hey, Denys.

On Thu, Jun 02, 2011 at 04:51:48PM +0200, Denys Vlasenko wrote:
> SIGSTOP/TSTP/TTIN/TTOU on entering group-stop,
> SIGCONT on leaving group-stop.

Yeah and SIGTRAP on INTERRUPT.  It makes sense.

> > * Implicit signal on clone.
> 
> Best if it is converted to STOP trap (the same is one caused by INTERRUPT).
> 
> I guess this may be optionally changed
> (similar to how PTRACE_O_TRACEEXEC
> changes post-execve SIGTRAP into PTRACE_EVENT_EXEC).
> 
> Why not turn it on *unconditionally* on SEIZE?
> Because otherwise ptrace users will turn into
> 
> if (we_used_SEIZE)
>     do_something;
> else
>     do_something_else;
> 
> maze, which is maintenance nightmare.
> It's possible users will opt to not use new functionality at all
> instead of going that way.

Hmmm... I see.  The other side of the argument is that some level of
"if (SEIZEd)" is inevitable anyway and in the longer run we would be
better off defaulting to the better behavior than making things
optional.

> If everything is monolithically tied into SEIZE, users won't be able
> to opt to use only easy parts of new functionality (such as
> PTRACE_INTERRUPT and PTRACE_LISTEN) if this *forces* them
> to also use harder parts of new functionality, in this case
> forces them to double and obfuscate their existing code
> which handles SIGSTOP-on-child-auto-attach. They don't really
> want to, since this SIGSTOP *in practice* isn't that problematic.

Anyways, let's think about that, but SIGSTOP on clone is closely
linked to why SEIZE is used in the first place and I currently lean
toward tying it to SEIZE.

> > * What to do about events which are reported by genuine SIGTRAP
> >  generation?
> 
> I don't understand what you meant here. Example(s)?

The syscall, breakpoint, single step SIGTRAPs which can't be
distinguished from userland generated SIGTRAPs and may be mixed and/or
lost.  Maybe it's best to leave them alone or maybe we can add some
way to distinguish them which is mostly backward compatible (which is
enabled w/ SEIZE and hopefully doesn't require noticeable userland
changes).

> > * Group leader exit issue.
> 
> Ohhh this is an ugly one. It turns out it is linked to the question
> of "how execve works under ptrace", in a non-obvious way.
> I will respond in the second thread, with an example of current
> kernel's breakage.

I haven't followed the thread yet.  Let's talk about it in that
thread.

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/