linux-kernel - Re: [RFC] [Patch 1/1] [Self Ptrace] System call notification with self

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, 28 Aug 2008 16:32:42 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Pierre Morel <pmorel@...ux.vnet.ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>,
	Heiko Carstens <heicars2@...ux.vnet.ibm.com>,
	sameske@...ux.vnet.ibm.com,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [RFC] [Patch 1/1] [Self Ptrace] System call notification with self_ptrace

On 08/28, Pierre Morel wrote:
>
> Oleg Nesterov wrote:
> >On 08/27, Pierre Morel wrote:
> >
> >>Oleg Nesterov wrote:
> >>
> >>
> >>>On s390 the patch changes handle_signal(), this is not clear to me too.
> >>>
> >>>
> >>The patch clears the trace flags before delivering the signal so
> >>that the signal handler can use system call without bouncing again.
> >>
> >
> >Yes I see. But the signal handler for SIGSYS can fisrt do
> >sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any
> >other syscall.
> >
> It is right but brings the overhead of a syscall.

Well, this overhead is very small compared to the signal delivery.

> >With this patch PT_SELF is cleared on any signal. This doesn't look
> >right. Let's suppose that another signal comes in parallel with SIGSYS.
> >It is very possible that the handler for that another signal will be
> >called first, this handler can do some syscall which will be "missed".
> >
>
> If the tracing application catches all signals before delivering
> them to the instrumented original handler there is no problem,
> the catching code can reset PTRACE_SELF_ON before calling the
> instrumented application's original handler.
> The instrumented code will then bounce as expected.

Sorry, can't understand the text above :(

OK, let's suppose the application does

	ptrace(PTRACE_SELF_ON);
	...
	syscall();

This "syscall()" above should trigger the handler for SIGSYS.
But what if another signal (with handler) comes in between?
In that case handle_signal() clears PT_SELF/TIF_SYSCALL_TRACE,
this syscall() (or any other) doesn't send SIGSYS.

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/