All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Jeff Dike <jdike@addtoit.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK
Date: Thu, 20 Apr 2006 16:17:28 +0200	[thread overview]
Message-ID: <444797F8.6020509@fujitsu-siemens.com> (raw)
In-Reply-To: <20060420090514.GA9452@osiris.boeblingen.de.ibm.com>

Heiko Carstens wrote:
>>Add PTRACE_SYSCALL_MASK, which allows system calls to be selectively
>>traced.  It takes a bitmask and a length.  A system call is traced
>>if its bit is one.  Otherwise, it executes normally, and is
>>invisible to the ptracing parent.
>>[...]
>>+int set_syscall_mask(struct task_struct *child, char __user *mask,
>>+		     unsigned long len)
>>+{
>>+	int i, n = (NR_syscalls + 7) / 8;
>>+	char c;
>>+
>>+	if(len > n){
>>+		for(i = NR_syscalls; i < len * 8; i++){
>>+			get_user(c, &mask[i / 8]);
>>+			if(!(c & (1 << (i % 8)))){
>>+				printk("Out of range syscall at %d\n", i);
>>+				return -EINVAL;
>>+			}
>>+		}
>>+
>>+		len = n;
>>+	}
> 
> 
> Since it's quite likely that len > n will be true (e.g. after installing the
> latest version of your debug tool) it would be better to silently ignore all
> bits not within the range of NR_syscalls.
> There is no point in flooding the console. The tracing process won't see any
> of the non existant syscalls it requested to see anyway.

Shouldn't 'len' better be the number of bits in the mask than the number of chars?
Assume a syscall newly added to UML would be a candidate for processing on the host,
but the incremented NR_syscalls still would result in the same number of bytes. Also
assume, host doesn't yet have that new syscall. Current implementation doesn't catch
the fact, that host can't execute that syscall.

OTOH, I think UML shouldn't send the entire mask, but relevant part only. The missing
end is filled with 0xff by host anyway. So it would be enough to send the mask up to the
highest bit representing a syscall, that needs to be executed by host. (currently, that
is __NR_gettimeofday). If UML would do so, no more problem results from UML having
a higher NR_syscall than the host (as long as the new syscalls are to be intercepted
and executed by UML)

A greater problem might be a process in UML, that calls an invalid syscall number. AFAICS
syscall number (orig_eax) isn't checked before it is used in do_syscall_trace to address
syscall_mask. This might result in a crash.

Bodo


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Jeff Dike <jdike@addtoit.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK
Date: Thu, 20 Apr 2006 16:17:28 +0200	[thread overview]
Message-ID: <444797F8.6020509@fujitsu-siemens.com> (raw)
In-Reply-To: <20060420090514.GA9452@osiris.boeblingen.de.ibm.com>

Heiko Carstens wrote:
>>Add PTRACE_SYSCALL_MASK, which allows system calls to be selectively
>>traced.  It takes a bitmask and a length.  A system call is traced
>>if its bit is one.  Otherwise, it executes normally, and is
>>invisible to the ptracing parent.
>>[...]
>>+int set_syscall_mask(struct task_struct *child, char __user *mask,
>>+		     unsigned long len)
>>+{
>>+	int i, n = (NR_syscalls + 7) / 8;
>>+	char c;
>>+
>>+	if(len > n){
>>+		for(i = NR_syscalls; i < len * 8; i++){
>>+			get_user(c, &mask[i / 8]);
>>+			if(!(c & (1 << (i % 8)))){
>>+				printk("Out of range syscall at %d\n", i);
>>+				return -EINVAL;
>>+			}
>>+		}
>>+
>>+		len = n;
>>+	}
> 
> 
> Since it's quite likely that len > n will be true (e.g. after installing the
> latest version of your debug tool) it would be better to silently ignore all
> bits not within the range of NR_syscalls.
> There is no point in flooding the console. The tracing process won't see any
> of the non existant syscalls it requested to see anyway.

Shouldn't 'len' better be the number of bits in the mask than the number of chars?
Assume a syscall newly added to UML would be a candidate for processing on the host,
but the incremented NR_syscalls still would result in the same number of bytes. Also
assume, host doesn't yet have that new syscall. Current implementation doesn't catch
the fact, that host can't execute that syscall.

OTOH, I think UML shouldn't send the entire mask, but relevant part only. The missing
end is filled with 0xff by host anyway. So it would be enough to send the mask up to the
highest bit representing a syscall, that needs to be executed by host. (currently, that
is __NR_gettimeofday). If UML would do so, no more problem results from UML having
a higher NR_syscall than the host (as long as the new syscalls are to be intercepted
and executed by UML)

A greater problem might be a process in UML, that calls an invalid syscall number. AFAICS
syscall number (orig_eax) isn't checked before it is used in do_syscall_trace to address
syscall_mask. This might result in a crash.

Bodo

  reply	other threads:[~2006-04-20 14:17 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13 17:20 [uml-devel] [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK Jeff Dike
2006-04-13 17:20 ` Jeff Dike
2006-04-18 12:57 ` [uml-devel] " Pavel Machek
2006-04-18 12:57   ` Pavel Machek
2006-04-26 18:38   ` [uml-devel] " Jeff Dike
2006-04-26 18:38     ` Jeff Dike
2006-04-20  9:05 ` [uml-devel] " Heiko Carstens
2006-04-20  9:05   ` Heiko Carstens
2006-04-20 14:17   ` Bodo Stroesser [this message]
2006-04-20 14:17     ` [uml-devel] " Bodo Stroesser
2006-04-25 18:32     ` Jeff Dike
2006-04-25 18:32       ` Jeff Dike
2006-04-26 20:26     ` Charles P. Wright
2006-04-26 20:26       ` Charles P. Wright
2006-04-26 19:40       ` Jeff Dike
2006-04-26 19:40         ` Jeff Dike
2006-04-26 21:29         ` Charles P. Wright
2006-04-26 21:29           ` Charles P. Wright
2006-04-21 18:16   ` Blaisorblade
2006-04-21 18:16     ` Blaisorblade
2006-04-21 18:38     ` Blaisorblade
2006-04-21 18:38       ` Blaisorblade
2006-04-22  7:06     ` Heiko Carstens
2006-04-22  7:06       ` Heiko Carstens
2006-04-22  8:32       ` Blaisorblade
2006-04-22  8:32         ` Blaisorblade
2006-04-25 15:59       ` Jeff Dike
2006-04-25 15:59         ` Jeff Dike
2006-04-21 18:34 ` [uml-devel] " Blaisorblade
2006-04-21 18:34   ` Blaisorblade
2006-04-25 16:29   ` Jeff Dike
2006-04-25 16:29     ` Jeff Dike
2006-04-26 15:47     ` Blaisorblade
2006-04-26 15:47       ` Blaisorblade
2006-04-26 15:46       ` Jeff Dike
2006-04-26 15:46         ` Jeff Dike
2006-04-28 20:28         ` Blaisorblade
2006-04-28 20:28           ` Blaisorblade
2006-04-29  1:49           ` Jeff Dike
2006-04-29  1:49             ` Jeff Dike
2006-05-01 13:51             ` Daniel Jacobowitz
2006-05-01 13:51               ` Daniel Jacobowitz
2006-05-01 13:45               ` Jeff Dike
2006-05-01 13:45                 ` Jeff Dike
2006-05-01 15:01                 ` Daniel Jacobowitz
2006-05-01 15:01                   ` Daniel Jacobowitz
2006-04-29  8:49           ` Heiko Carstens
2006-04-29  8:49             ` Heiko Carstens
2006-05-01 17:02             ` Jeff Dike
2006-05-01 17:02               ` Jeff Dike
2006-05-02  6:57               ` Heiko Carstens
2006-05-02  6:57                 ` Heiko Carstens

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=444797F8.6020509@fujitsu-siemens.com \
    --to=bstroesser@fujitsu-siemens.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.