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, 26 May 2011 16:55:45 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Pedro Alves <pedro@...esourcery.com>,
	Denys Vlasenko <vda.linux@...glemail.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 05/26, Tejun Heo wrote:
>
> This reminded me of another issue.  Currently we have two different
> methods of reporting debug events.  One is direct ptrace event trap,
> which ends up in ptrace_stop() from the event site and thus is
> synchronous.  The other is sending SIGTRAP, literally.  Besides the
> usual problems related with implicitly sending signals, this also
> makes it difficult to determine which event is happening exactly and
> makes the whole signal delivery/injection thing much worse.
>
> I suspect that all ptrace traps probably started as actual SIGTRAPs
> and so all the events were reported via signal delivery path and so
> the signal "injection" worked; however, now we have synchronous traps
> and some SIGTRAPs, which are confusing and unreliable.  I don't see
> any reason why the events which are currently reported via SIGTRAPs
> can't be reported via ptrace traps with unique PTRACE_EVENT_*.  I
> don't think we can take synchronous traps directly but we can schedule
> them, record relevant information in preallocated area and just set
> TIF_SIGPENDING and let the signal delivery path report the trap.  This
> will make all the events reliable and easily distinguishible and we
> can fix the SIGTRAP signal problem.  What do you think?

Agreed, it would be nice to avoid SIGTRAP's. Although right now it is
not clear to me how we can do this. The problematic case is the
single-stepping, afaics. Say, int3. Even if the task is ptraced, we
can't know why do we hit this insn. It is possible that this task
auto-debugs itself and thus we should send SIGTRAP. Even the
X86_EFLAGS_TF case is not that simple although we can probably take
TIF_SINGLESTEP into account. But again, the task can set X86_EFLAGS_TF
itself.

Oleg.

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