[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [uml-devel] Re: [RFC] PATCH 3/4 - Time virtualization : PTRACE_SYSCALL_MASK
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-26 22:29    [W:0.024 / U:11.500 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site