Re: veriexecctl(8) segfaults when no argument is given

["Stathis Kamperis" <ekamperi%gmail.com@localhost>]

2008/9/8, Elad Efrat <elad%netbsd.org@localhost>:
> Hey guys,
>
>  Sorry it took me a while to reply.

Hi Elad :)

>  Stathis Kamperis wrote:
>
>
> > * I've come up with some locking issues. Veriexecctl goes into tstile
> > state and renders the whole system unusable, ie all processes
> > gradually become unresponsive and go into tstile state as well. It's
> > 100% reproducible for me (only) under X environment: run an xterm and
> > type 'veriexecctl load' a dozen consecutive times until it hangs. I'll
> > come back with a useful trace.
> >
>
>  It's because we don't release the lock we're taking in veriexec_renamechk()
> in the case we have neither "vfe" or "tvfe".
>
>  Also, it looks like in veriexec_file_add(), in the block handling
>  "eval-on-load", we use "goto out" instead of "goto unlock_out" in the
>  error case for veriexec_fp_calc().
>
>  The attached diff addresses both issues.
>
> Index: kern_verifiedexec.c
> ===================================================================
>  RCS file: /usr/cvs/src/sys/kern/kern_verifiedexec.c,v
>  retrieving revision 1.109
>  diff -u -p -r1.109 kern_verifiedexec.c
>  --- kern_verifiedexec.c 20 Jul 2008 08:50:20 -0000      1.109
>  +++ kern_verifiedexec.c 7 Sep 2008 14:12:34 -0000
>  @@ -930,7 +930,8 @@ veriexec_renamechk(struct lwp *l, struct
>                 if (tvfe != NULL)
>                         (void)veriexec_file_delete(l, tovp);
>
>  -       }
>  +       } else
>  +               rw_exit(&veriexec_op_lock);
>
>         return (0);
>   }
>  @@ -1312,7 +1313,7 @@ veriexec_file_add(struct lwp *l, prop_di
>                                          vfe, digest);
>                 if (error) {
>                         kmem_free(digest, vfe->ops->hash_len);
>  -                       goto out;
>  +                       goto unlock_out;
>                 }
>
>                 if (veriexec_fp_cmp(vfe->ops, vfe->fp, digest) == 0)
>
>
>

I applied your patch and now veriexecctl doesn't go into `tstile'
state nor does it bring the system down (under X). Thanks !

On the other hand, if I compile a kernel with your patch + LOCKDEBUG,
when I try to startX, I get a panic and here is the associated
backtrace:

#0  0xc05a4bc2 in cpu_reboot (howto=260, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:883
883                     dumpsys();
(gdb) bt
#0  0xc05a4bc2 in cpu_reboot (howto=260, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:883
#1  0xc01de298 in db_reboot_cmd (addr=-1061806035, have_addr=false,
    count=-1061806048, modif=0xcbebf870 " øëË+ ¶À, ¶À4")
    at /usr/src/sys/ddb/db_command.c:1318
#2  0xc01ddda8 in db_command (last_cmdp=0xc0ae23bc)
    at /usr/src/sys/ddb/db_command.c:933
#3  0xc01de0f2 in db_command_loop () at /usr/src/sys/ddb/db_command.c:578
#4  0xc01e1000 in db_trap (type=1, code=0) at /usr/src/sys/ddb/db_trap.c:101
#5  0xc059fb7b in kdb_trap (type=1, code=0, regs=0xcbebfa9c)
    at /usr/src/sys/arch/i386/i386/db_interface.c:229
#6  0xc05a79a3 in trap (frame=0xcbebfa9c)
    at /usr/src/sys/arch/i386/i386/trap.c:352
#7  0xc010cc76 in calltrap ()
#8  0xc059e29c in breakpoint ()
#9  0xc04d73f8 in panic (
    fmt=0xc0a825ac "lockdebug_lookup: uninitialized lock (lock=%p)")
    at /usr/src/sys/kern/subr_prf.c:255
#10 0xc04d0ad1 in lockdebug_abort (lock=0xcbebfc50, ops=0xc0aee658,
    func=0xc087133a "rw_vector_exit",
    msg=0xc0a7f084 "assertion failed: RW_OWNER(rw) == curthread")
    at /usr/src/sys/kern/subr_lockdebug.c:193
#11 0xc04b011a in rw_abort (rw=0x1, func=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
    msg=0x8 <Address 0x8 out of bounds>) at /usr/src/sys/kern/kern_rwlock.c:192
#12 0xc04b0e27 in rw_vector_exit (rw=0xcbebfc50)
    at /usr/src/sys/kern/kern_rwlock.c:443
#13 0xc03654ac in veriexec_verify (l=0xcbff7a60, vp=0xcbb2d17c,
    name=0xc0a76f3d "(mmap)", flag=2, found=0x0)
    at /usr/src/sys/kern/kern_verifiedexec.c:732
#14 0xc0451344 in sys_mmap (l=0xcbff7a60, uap=0xcbebfd00, retval=0xcbebfd28)
    at /usr/src/sys/uvm/uvm_mmap.c:532
#15 0xc05a72bb in syscall (frame=0xcbebfd48)
    at /usr/src/sys/arch/i386/i386/syscall.c:102
#16 0xc010057d in syscall1 ()
(gdb)

Thanks for bothering.

Best regards,
Stathis Kamperis