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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Aug 2008 14:03:58 +0200
From:	Pierre Morel <pmorel@...ux.vnet.ibm.com>
To:	Oleg Nesterov <oleg@...sign.ru>
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

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

I see this more like a security, the "bouncing" feature
is only enabled until next syscall or signal, never more.

This instrumentation method allows with this little patch to do
all the syscall and signal instrumentation in userland and inside the
address space of the instrumented application.

I expect we will  have a big improvement of instrumenting tools like
 - debugger, tracing tool,
 - virtualization applications like UML
 - High availability: checkpoint and restart, record and replay.
because of the reduction of IPC and task switch overhead.

Pierre

-- 
=============
Pierre Morel
RTOS and Embedded Linux

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