--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Feb 09, 2007 at 12:04:33PM +0200, Elad Efrat wrote:
> Scott Ellis wrote:
> > I'm having a problem with using Veriexec on -current for amd64.  Back on
> > December 20th -current, everything worked fine.  I updated -current on
> > Feb 4th, and found that I get the following shortly after going
> > multiuser (yes, that bad formatting really is how it looks on boot!):
> 
> the veriexec warnings you get (you really shouldn't get them on console
> since we no longer use printf) are because you have not properly
> configured it. /bin/sh is accessed both directly and indirectly, so I'm
> guessing you need to add the 'indirect' flag to your config file.

Thanks.  I figured that was the case, since I generated my signatures file
with a naive run of veriexecgen.  I'm not really too worried about those
warnings for sh and perl, since I'm just monitoring things at the moment
(and easily filter those messages out!).

> 
> other errors are problems with other stuff; in strict level 0, other
> than printing, veriexec doesn't really do anything.

Right.  I'm using level 0, and it's doing what I expect (except for that
whole crashing thing).

> 
> phyre:elad {1} uname -pmr
> 4.99.9 amd64 x86_64

Identical here

> phyre:elad {2} sysctl kern.veriexec
> kern.veriexec.verbose = 1
> kern.veriexec.strict = 1
> kern.veriexec.algorithms = RMD160 SHA256 SHA384 SHA512 SHA1 MD5
> kern.veriexec.count.table0.mntpt = /
> kern.veriexec.count.table0.fstype = ffs
> kern.veriexec.count.table0.nentries = 148
> kern.veriexec.count.table1.mntpt = /usr
> kern.veriexec.count.table1.fstype = ffs
> kern.veriexec.count.table1.nentries = 880
> phyre:elad {3}

intrepid{~}% sysctl kern.veriexec
kern.veriexec.verbose = 0
kern.veriexec.strict = 0
kern.veriexec.algorithms = SHA256

(obviously I can't do this with veriexec running at the moment!)

> 
> so I'm not sure how broken it is on amd64. what's interesting is that
> the fault is in mixerctl rather. how are you building? what are the
> relevant file versions in the kernel you're using?

I'm building using build.sh.  Specifically, I'm doing:

./build.sh -M obj.amd64 -D $prefix/destdir -T $prefix/tooldir -R $prefix/release
dir release >&buildlog.amd64

(where $prefix is set to an absolute path, and I forcefully rm destdir, tooldir,
and releasedir contents prior to building.)

/* $NetBSD: kern_fileassoc.c,v 1.24 2007/02/08 16:06:58 elad Exp $ */
/*      $NetBSD: kern_verifiedexec.c,v 1.95 2007/02/06 01:09:48 elad Exp $

(not sure what else you think might be relevant)

It is strange that mixerctl is where it seems to happen.  I'm not sure if this
is a fluke, and it's timing related, or if there really is something
"special" about mixerctl.

I'm attaching my mk.conf, in case it shows anything enlightening.  I'm not
really sure how to proceed.  Should I build a debug kernel and give you
a backtrace?

	ScottE


--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="mk.conf"

# Don't build other stuff
MKDOC=no
MKLINT=no
MKINFO=no
MKUUCP=no
MKPROFILE=no
#MKPICINSTALL=no
# Don't build Auth methods we don't need
MKKERBEROS=no
MKKERBEROS4=no
MKHESIOD=no
MKSKEY=no
MKYP=no
# I don't use sendmail or postfix
MKSENDMAIL=no
MKPOSTFIX=no
# I don't want IPV6
MKINET6=no
# I don't want IPFilter
MKIPFILTER=no
# Don't build X stuff
MKX11=no
# Misc Stuff
# Set compiler options.
CFLAGS += -pipe
CPUFLAGS = -march=k8
#SHAREDSTRINGS currently breaks build...file PR
#SHAREDSTRINGS=yes
STRIPFLAG = -s
# Don't fail on 'release'
CHECKFLIST_FLAGS = -e -m
# Misc
HAVE_GDB=6
# Security
USE_SSP=yes

--Qxx1br4bt0+wmkIi--