Subject: Re: Veriexec broken on amd64?
To: Elad Efrat <elad@bsd.org.il>
From: Scott Ellis <scotte@warped.com>
List: current-users
Date: 02/16/2007 15:40:10
Elad Efrat wrote:
> 
> so please verify your process & report back to hq. :)
> 

Well, I had my doubts too, since the first test was w/o a make clean, so 
this time I nuked the .../compile/INTREPID.AMD64.DEBUG directory and 
rebuilt the kernel.

Unfortunately, no change in results.

The diff applies cleanly:

intrepid{.../sys/kern}% patch < /nbu/data/scotte/veriexec.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: kern_verifiedexec.c
|===================================================================
|RCS file: /usr/cvs/src/sys/kern/kern_verifiedexec.c,v
|retrieving revision 1.95
|diff -u -p -r1.95 kern_verifiedexec.c
|--- kern_verifiedexec.c        6 Feb 2007 01:09:48 -0000       1.95
|+++ kern_verifiedexec.c        9 Feb 2007 14:28:10 -0000
--------------------------
Patching file kern_verifiedexec.c using Plan A...
Hunk #1 succeeded at 818.
done
intrepid{.../sys/kern}% ls -l kern_veri*
-rw-r--r--  1 scotte  wheel  31020 Feb 16 15:13 kern_verifiedexec.c
-rw-r--r--  1 scotte  wheel  30971 Feb 16 15:13 kern_verifiedexec.c.orig
-rw-r--r--  1 scotte  wheel  30971 Feb 15 17:08 kern_verifiedexec.c.original
intrepid{.../sys/kern}%

And the kernel is the new one:

 >> NetBSD/amd64 BIOS Boot, Revision 3.3
 >> (scotte@intrepid, Fri Apr  7 19:53:08 PDT 2006)
 >> Memory: 637/1046784 k
Press return to boot now, any other key for boot menu
booting hd0a:netbsd - starting in 0
type "?" or "help" for help.
 > boot hd0a:netbsd.debug
booting hd0a:netbsd.debug
2667216+343264+277096 [255672+171938]=0x48c2e8
Loaded initial symtab at 0xffffffff80523748, strtab at 
0xffffffff80562340, # entries 10637
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
     2006, 2007
     The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.

NetBSD 4.99.9 (INTREPID.AMD64.DEBUG) #0: Fri Feb 16 15:21:41 PST 2007
 
scotte@intrepid:/nbu/source/netbsd/src/obj.amd64/nbu/source/netbsd/src/sys/arch/amd64/compile/INTREPID.AMD64.DEBUG
total memory = 1022 MB
avail memory = 979 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
mainbus0 (root)
[snip]

But the problem remains:

[snip]
Starting ntpd.
Starting powerd.
Starting sshd.
Restoring mixer settings: mixer0kernel: protection fault trap, code=0
Stopped in pid 478.1 (raidctl) at 
netbsd:specificdata_getspecific+0x12:   c
mpq     0(%rax),%rdx
db> bt
specificdata_getspecific() at netbsd:specificdata_getspecific+0x12
fileassoc_file_lookup() at netbsd:fileassoc_file_lookup+0x1c
fileassoc_lookup() at netbsd:fileassoc_lookup+0x13
veriexec_purge() at netbsd:veriexec_purge+0x9
fileassoc_table_run() at netbsd:fileassoc_table_run+0x66
veriexec_raw_cb() at netbsd:veriexec_raw_cb+0x155
kauth_authorize_action() at netbsd:kauth_authorize_action+0xa0
kauth_authorize_device_spec() at netbsd:kauth_authorize_device_spec+0x2f
spec_open() at netbsd:spec_open+0x16f
VOP_OPEN() at netbsd:VOP_OPEN+0x2a
vn_open() at netbsd:vn_open+0x264
sys_open() at netbsd:sys_open+0xeb
syscall_plain() at netbsd:syscall_plain+0x112
--- syscall (number 0) ---
0:
db>
db> sync
syncing disks... 12 3 done
unmounting file systems...
unmounting /dev/pts (ptyfs)...
unmounting /nbu/data (/dev/raid1h)...
unmounting /nbu (/dev/raid1g)...
unmounting /data (/dev/raid1f)...
unmounting /var (/dev/raid1e)...
unmounting /tmp (tmpfs)...
unmounting / (/dev/raid1a)...panic: lockmgr: draining against myself
Stopped in pid 478.1 (raidctl) at       netbsd:cpu_Debugger+0x5: 
leave
db>
db> sync

dumping to dev 18,17 offset 1051015
dump device bad

I'm not sure what else to try.

For kicks and giggles, I'mm cvs update (to pull in the massive newlock2 
changes) and give it another try (with and without the patch).  I've got 
no reason to believe it'll change things, but it'll at least be another 
data-point. :-)

	ScottE