Messages in this thread | | | Subject | Re: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK | From | "Charles P. Wright" <> | Date | Wed, 26 Apr 2006 16:26:42 -0400 |
| |
On Thu, 2006-04-20 at 16:17 +0200, Bodo Stroesser wrote: > 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. I have a similar local patch that I've been using. I think it would be worthwhile to have an extra bit in the bitmap that says what to do with calls that fall outside the range [0, __NR_syscall]. That way the ptrace monitor can decide whether it is useful to get informed of these "bogus" calls.
Charles
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |