From: Oleg Nesterov <oleg@tv-sign.ru>
To: Pierre Morel <pmorel@linux.vnet.ibm.com>
Cc: sameske@linux.vnet.ibm.com,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
gregkh@suse.de, Heiko Carstens <heicars2@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
Dave Hansen <dave@linux.vnet.ibm.com>,
Daniel Lezcano <dlezcano@fr.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Roland McGrath <roland@redhat.com>
Subject: Re: [uml-devel] [PATCH 1/1] system call notification with self_ptrace
Date: Wed, 10 Sep 2008 20:20:08 +0400 [thread overview]
Message-ID: <20080910162008.GA401@tv-sign.ru> (raw)
In-Reply-To: <48C7E3A9.3060602@linux.vnet.ibm.com>
On 09/10, Pierre Morel wrote:
>
> Oleg Nesterov wrote:
> >
> >I still think this patch shouldn't change handle_signal().
> >
> >Once again. The signal handler for SIGSYS can first do
> >sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any
> >other syscall, so this change is not needed, afaics.
> >
> Yes it can but what if the application forget to do it?
> It is a security so that the application do not bounce for ever.
The (buggy) task can be killed, this has nothing to do with security.
From the security pov, this case doesn't differ from, say,
void sigh(int sig)
{
kill(getpid(), sig);
}
void main(void)
{
signal(SIGSYS, sigh);
kill(getpid(), SIGSYS);
}
Or I missed something?
> >So, PTRACE_SELF_XXX disables the "normal" ptrace. Not sure this is good.
> >
> I think that having two tracing system one over the other may be
> quite difficult to handle.
Yes I see.
But... well, I think we need Roland's opinion. I must admit, I am a bit
sceptical about this patch ;) I mean, I don't really understand why it
is useful. We can do the same with fork() + ptrace(). Yes, in that
case we need an "extra" context switch for any traced syscall. But,
do you have any "real life" example to demonstrate that the user-space
solution sucks? We can even use CLONE_MM to speedup the context switch.
Pierre, don't get me wrong. I never used debuggers for myself, I will
be happy to know I am wrong. I just don't understand.
As for ->instrumentation. If you are going to remove PTS_INSTRUMENTED,
we need only one bit. We could use PF_PTS_SELF, but ->flags is already
"contended". Perhaps you can do something like
--- include/linux/sched.h
+++ include/linux/sched.h
@@ -1088,6 +1088,7 @@ struct task_struct {
/* ??? */
unsigned int personality;
unsigned did_exec:1;
+ unsigned pts_self:1;
pid_t pid;
pid_t tgid;
Both did_exec and pts_self can only be changed by current, so it is
safe to share the same word. This way we don't enlarge task_struct.
Oleg.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@tv-sign.ru>
To: Pierre Morel <pmorel@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>,
Heiko Carstens <heicars2@linux.vnet.ibm.com>,
sameske@linux.vnet.ibm.com,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
gregkh@suse.de,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>,
Daniel Lezcano <dlezcano@fr.ibm.com>
Subject: Re: [PATCH 1/1] system call notification with self_ptrace
Date: Wed, 10 Sep 2008 20:20:08 +0400 [thread overview]
Message-ID: <20080910162008.GA401@tv-sign.ru> (raw)
In-Reply-To: <48C7E3A9.3060602@linux.vnet.ibm.com>
On 09/10, Pierre Morel wrote:
>
> Oleg Nesterov wrote:
> >
> >I still think this patch shouldn't change handle_signal().
> >
> >Once again. The signal handler for SIGSYS can first do
> >sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any
> >other syscall, so this change is not needed, afaics.
> >
> Yes it can but what if the application forget to do it?
> It is a security so that the application do not bounce for ever.
The (buggy) task can be killed, this has nothing to do with security.
>From the security pov, this case doesn't differ from, say,
void sigh(int sig)
{
kill(getpid(), sig);
}
void main(void)
{
signal(SIGSYS, sigh);
kill(getpid(), SIGSYS);
}
Or I missed something?
> >So, PTRACE_SELF_XXX disables the "normal" ptrace. Not sure this is good.
> >
> I think that having two tracing system one over the other may be
> quite difficult to handle.
Yes I see.
But... well, I think we need Roland's opinion. I must admit, I am a bit
sceptical about this patch ;) I mean, I don't really understand why it
is useful. We can do the same with fork() + ptrace(). Yes, in that
case we need an "extra" context switch for any traced syscall. But,
do you have any "real life" example to demonstrate that the user-space
solution sucks? We can even use CLONE_MM to speedup the context switch.
Pierre, don't get me wrong. I never used debuggers for myself, I will
be happy to know I am wrong. I just don't understand.
As for ->instrumentation. If you are going to remove PTS_INSTRUMENTED,
we need only one bit. We could use PF_PTS_SELF, but ->flags is already
"contended". Perhaps you can do something like
--- include/linux/sched.h
+++ include/linux/sched.h
@@ -1088,6 +1088,7 @@ struct task_struct {
/* ??? */
unsigned int personality;
unsigned did_exec:1;
+ unsigned pts_self:1;
pid_t pid;
pid_t tgid;
Both did_exec and pts_self can only be changed by current, so it is
safe to share the same word. This way we don't enlarge task_struct.
Oleg.
next prev parent reply other threads:[~2008-09-10 16:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 12:02 [uml-devel] [PATCH 1/1] system call notification with self_ptrace Pierre Morel
2008-09-08 12:02 ` Pierre Morel
2008-09-09 0:04 ` Andrew Morton
2008-09-09 0:04 ` [uml-devel] " Andrew Morton
2008-09-10 14:17 ` Pierre Morel
2008-09-10 14:17 ` [uml-devel] " Pierre Morel
2008-09-09 12:43 ` Oleg Nesterov
2008-09-09 12:43 ` Oleg Nesterov
2008-09-10 15:11 ` [uml-devel] " Pierre Morel
2008-09-10 15:11 ` Pierre Morel
2008-09-10 16:20 ` Oleg Nesterov [this message]
2008-09-10 16:20 ` Oleg Nesterov
2008-09-10 16:23 ` [uml-devel] " Dave Hansen
2008-09-10 16:23 ` Dave Hansen
2008-09-12 12:22 ` [uml-devel] " Pierre Morel
2008-09-12 12:22 ` Pierre Morel
2008-09-12 12:19 ` [uml-devel] " Pierre Morel
2008-09-12 12:19 ` Pierre Morel
2008-09-12 14:32 ` [uml-devel] " Oleg Nesterov
2008-09-12 14:32 ` Oleg Nesterov
2008-09-10 16:19 ` [uml-devel] " Dave Hansen
2008-09-10 16:19 ` Dave Hansen
2008-09-12 12:30 ` [uml-devel] " Pierre Morel
2008-09-12 12:30 ` Pierre Morel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080910162008.GA401@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=clg@fr.ibm.com \
--cc=dave@linux.vnet.ibm.com \
--cc=dlezcano@fr.ibm.com \
--cc=gregkh@suse.de \
--cc=heicars2@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pmorel@linux.vnet.ibm.com \
--cc=roland@redhat.com \
--cc=sameske@linux.vnet.ibm.com \
--cc=schwidefsky@de.ibm.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.