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

On Fri, 04 Mar 2011 18:07:37 +0100, Oleg Nesterov wrote:
> Suppose that the tracee reports, say, a signal after PTRACE_SEIZE/INTERRUPT.
> And this is possible anyway if the debugger races with kill(). Why this
> is bad?

I was asking if it is possible or if it could be avoided.

When you check gdb-6.8.tar it asserts the first received signal is SIGSTOP or
in a different case it ignores the first signal (whatever it is).  This is
because if the programmer sees during the development the first signal that
comes is SIGSTOP (s)he automatically writes the code with that assumption.

When the tracer has a function to attach a task it should be a self-sufficient
function returning the tracee in some normal task like after other events.
So the attach operation should neither leave pending some excessive signals
nor it should eat some normal vital signals (like PTRACE_EVENT_FORK).

Sure the tracer can always handle it some way, ignore this signal, remember if
it has seen that signal etc.  But if we design a new ptrace interface it
should be simple to use and it should not suggest coding racy/buggy tracers.

Thanks,
Jan
--
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/