linux-kernel - Re: [RFC] Proposal for ptrace improvements

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, 4 Mar 2011 15:07:45 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

Hello,

On Fri, Mar 04, 2011 at 02:59:32PM +0100, Denys Vlasenko wrote:
> I would rather speed strace up than slow it down further, even if
> slightly.

The question to ask is at what cost?  If mostly unnoticeable slow down
makes the API cleaner, I'll go that way.  Everything is a tradeoff.

> > it might really not fit there.  I'd like to avoid twisting debugging
> > API
> 
> It is *already* twisted that way. Other ptrace stops *already*
> return extra information in waitpid status: run "man ptrace"
> and read PTRACE_SETOPTIONS section. For example:
> 
>       "PTRACE_O_TRACEEXEC (since Linux 2.5.46)
>              Stop  the  child  at  the next execve(2) call with
>              SIGTRAP | PTRACE_EVENT_EXEC << 8."
> 
> I don't see why adding another PTRACE_EVENT_foo
> is a big deal.

No, I wasn't talking about that.  My concern was that.  Let's say, we
need a flag somewhere to indicate group stop state (because the state
is necessary regardless of which trap is taken) and then we can't or
that to SIGTRAP transparently because that would change it for the
existing events and at the same time I don't want to make the
information available in two separate forms.

That said, I think, for strace, it should be okay.  Unless the tracer
resumes the tracee while job control stop is in effect, the trap which
is taken after SIGCONT emission will be a new distinguishible trap
which will be assigned a separate PTRACE_EVENT_*, so it wouldn't have
to depend on siginfo.

Anyways, I'll keep the distinction performance on mind but if it comes
down to API convolution, I don't think bending that way is a good
idea.  If we're gonna bend, there should be numbers justifying the
bending.

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/