Re: DPT revision....(broken drivers in -STABLE)

[Matthew N. Dodd]

On Thu, 24 Aug 2000, Visigoth wrote:
 dpt0: DPT Caching SCSI RAID Controller port 0xdc60-0xdc7f irq 16 at
 device 8.0 on pci 2
 
 even though bios asigned it irq 9...  hmmm

Is this an SMP box or a UP box in APIC mode or something strange?

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb bug w/ dlopen()ed images

[Max Khon]

hi, there!

On Fri, 25 Aug 2000, John DeBoskey wrote:

There appears to be a problem with gdb when debugging
 dynamically loaded images. On 5.0-current with
 sources current and built as of this evenning and a
 4.1-STABLE system, the following incorrect result is seen:

PR/20373

Solution: apply patch 1.8-1.9 for bfd/elf32-i386.c from binutils source
tree (their cvsweb is somewhere at http://sources.redhat.com/binutils/)
to src/contrib/binutils/bfd/elf32-i386.c and rebuild
src/gnu/usr.bin/binutils/libbfd and
src/gnu/usr.bin/binutils/ld

Unfortunately for some reason I cannot post follow-up for this PR. 
David O'Brien has all the information.

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: devfs, moused and rc.devfs position in rc

[Sheldon Hearn]

On Thu, 24 Aug 2000 10:29:03 MST, Jos Backus wrote:

 In /etc/rc, rc.i386 is invoked before rc.devfs. This causes moused to fail to
 start for those people who use a link from /dev/mousedev to /dev/mouse.  The
 fix seems to be to switch the order of invocation:

Your problem raises another interesting problem.  Takea look at the
bottom of rc.diskless2, where /dev is mounted in mfs.  That operation
needs to be conditionalized on the presence of DEFVS.

What we really need is for someone who runs a diskless environment to
try placing the call to rc.devfs immediately before the call to
rc.diskless1 and to apply something like the following patch to
rc.diskless2:

Index: rc.diskless2
===
RCS file: /home/ncvs/src/etc/rc.diskless2,v
retrieving revision 1.6
diff -u -d -r1.6 rc.diskless2
--- rc.diskless22000/04/27 08:43:48 1.6
+++ rc.diskless22000/08/25 08:51:20
@@ -34,6 +34,8 @@
 fi
 
 # extract a list of device entries, then copy them to a writable partition
-(cd /; find -x dev | cpio -o -H newc)  /tmp/dev.tmp
-mount_mfs -s 4096 -i 512 -T qp120at dummy /dev
-(cd /; cpio -i -H newc -d  /tmp/dev.tmp)
+if ! mount | grep -q 'devfs on /dev'; then
+   (cd /; find -x dev | cpio -o -H newc)  /tmp/dev.tmp
+   mount_mfs -s 4096 -i 512 -T qp120at dummy /dev
+   (cd /; cpio -i -H newc -d  /tmp/dev.tmp)
+fi

Feedback from such a person would be most useful, I think.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

$BF)2a5!G=IU%G%8%+%a1#$7;#$j%-%C%HHNGd(B

[Cosmo21]

$B%Y%k%H$N%P%C%/%k$K;E9~$s$@%l%s%:$+$iK\BN!J3s$J$I!K$K(B
$BEEGH$rHt$P$9J}<0$G$9!#=D(B1440$B!_2#(B960$B%T%/%;%k!##A#4MQ;f(B
$B=D$G>/$7:81&$KM>Gr$reH>?H!&2?H$NA*Br$r85$K$"$i$+$8$a%l%s(B
$B%:3QEY!"%:!<%`N($rD4@a8GDj!#$"$H$O%P%C%/%k$r?($k$h$&$K(B
$B%7%c%C%?!]J*$r#2!?#3$NHO0O(B
$B$K<}$a$k$3$H$,$G$-$^$9!#5^B.%*!<%H%U%)!<%+%9$G$9$N$G!"(B
$BN)$A;_$^$C$?Aj5CN$/$@$5$$!#(B
$B5-O?$O%9%^!<%H%a%G%#%"!J#8(BMB$BE:IU!"#2#0Kg5-O?2D!K$G!"K\BN$N(B
$B#2%$%s%A1U>=!"%F%l%S@\B3$G8+$i$l$k$[$+!"#1K|1_DxEY$N%U%i%C(B
$B%7%e%Q%9$+%9%^!<%H%a%G%#%"%j!<%@$rGc$($P%Q%=%3%s$K$b3Q%m!<%^;z!J=g=x$OF|K\8l<0$G2D!K$G$*CN$i$;(B
$B4j$$$^$9!#3NG'8eLs=54V$GH/Aw$7$^$9!#H/AwF|;XDj!":-Jq$=$NB>4uK>(B
$B$O8=6b=qN1$KJ;5-$7$F$/$@$5$$!#(B
$B")(B112$B!!El5~!!>.@P@nM9JX6I;_$a!!%3%9%b#2#1(B
$BDy$a@Z$jD62a8e$N$*?=$79~$_!"$*Ld$$9g$o$;$=$NB>$O0l@Z1~$8$+$M$^$9!#(B





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Linux Netscape

[Sean-Paul Rees]

Under my 5.0-C setup here, the Linux netscape takes AGES to load (5min) and 
is so unresponsive, I have to kill it.

I experienced a similar problem with StarOffice 5.2, where performance was just
dog slow. Is the Linuxulator broken?

-- 
Cheers,
Sean

Sean-Paul Rees ([EMAIL PROTECTED])
Web: http://www.seanrees.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

kernel hash table implementation?

[Archie Cobbs]

Is there a generic hash table implementation in the kernel somewhere?
If not, is there any interest in creating one?

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Review requested for i386 debug register helper functions

[Brian Dean]

On Thu, 24 Aug 2000, Brian Dean wrote:

 If you have the time, I would very much appreciate any reviews on a
 couple of helper functions that I've put together for manipulating the
 i386 debug registers:
 
   http://people.freebsd.org/~bsd/i386watch/

Just a note to reviewers, I've simplified the i386_set_watch()
function a bit as of Aug 25 @ 5:15 PDT.

-Brian



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

yarrow /dev/random

[Adam Back]

[try again this foobared the first time -- apologies for duplicates]

[If this bounces because I am not a list member, could I trouble one
of you to forward it to the list? -- Thanks]

Hi all

We've been implementing yarrow at zeroknowledge also.  I just read
through the freebsed-current archives searching for "yarrow", and I
share some of the concerns raised by Kris Kennaway:

Kris Kennaway [EMAIL PROTECTED]
 [...]  

 I'm not bothered about this. My point is that, by design, Yarrow is not 
 suitable as a replacement for /dev/random (/dev/urandom, yes).

and Jeroen van Gelderen [EMAIL PROTECTED]:
 [...] At a more fundamental level we will need to answer the
 question: "Do we need to preserve the current /dev/random semantics
 or can we decide to change 'em? [1]". And how will this affect our
 applications *in practice*.   

 So let's concentrate this discussion on the practical issues
 and explain why you think backing /dev/random with Yarrow and
 changing the semantics is justifyable or even a good thing.

and several others I saw.

I've been talking with John Kelsey (one of the Yarrow authors) about
changing yarrow to support /dev/random for the very same reason (I had
not read this discussion -- but the same objection independently
occured to me in connection with linux which has the same Ted T'so
/dev/random code).

John Kelsey has also been working on a Yarrow-160-A which simplifies
some of the design.  I'm hoping to persuade the yarrow designers of
the importance of supporting /dev/random semantics for the unix
community acceptance.  John Kelsey and I had some discussions along
the lines of feeding /dev/random output into yarrow, which I notice
someone on here considered.  (Sorry I forgot who said that).

Perhaps I could encourage some of you to subscribe to the yarrow list
we have setup at [EMAIL PROTECTED] (send mail to
[EMAIL PROTECTED]).  Peter Gutmann is subscribed (I see
some references to his paper), and I expect some of the yarrow authors
will when they get back from Crypto.  It might help the cause of
preserving /dev/random semantics, if those of you participating in
this discussion back in July chipped in to support my similar
predictions about community acceptance on this basis -- OS
implementors are after all the target audience for yarrow.

There are several implementors on board -- RST have an implementation
tracking the changes in yarrow-160-A they plan to release soon, we
have the 160 implementation I wrote (current tar ball at:
http://opensource.zeroknowledge.com).

I must say I think it is important with cryptographic primitives to
have test vectors, so that you know your implementation is correct and
conforms to the specification.  It's very difficult to notice errors
in a PRNG -- the output still looks random.  So the aim of the yarrow
list is to collectively work on deriving test vectors.

I had a quick look at Mark's yarrow implementation and there are a
things which I'd caution about:

- the hash function constructed from using Blowfish in CBC mode you --
  have to be careful how you use block ciphers to construct hash
  functions -- they have quite different properties.  For example
  collision resistance is not generally important for a block cipher,
  but is all-important for a hash function

- yarrow design specifically calls for a hash function and a block
  cipher -- you may easily be violating some of it's security
  assumptions by plugging in the above.

- blowfish has an expensive key-schedule, so depending on your Pg
  value it might be faster to use 3DES as specified by yarrow-160.

- a minor coding question: it doens't look to me like the IV is
  initialised -- is there something assuring that the ivec local
  variable will hold zeros -- otherwise your RNG may have non
  repeatable output - making testing difficult.

Adam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

MACs vs Hash fns. and collision resistance

[adam]

[I see my post made it]

To expand briefly on my comment about collision resistance

 - the hash function constructed from using Blowfish in CBC mode you --
   have to be careful how you use block ciphers to construct hash
   functions -- they have quite different properties.  For example
   collision resistance is not generally important for a block cipher,
   but is all-important for a hash function

-- I haven't looked in detail at what the code does, but I think I can
guess from the description:

CBC mode means you start with y_0 = IV, and compute ciphertext y_i =
E_k( x_i ^ y_{i-1} ).  In this case I see y_0 is set to zero (or
perhaps left undefined).  (^ = xor)

A CBC-MAC is where you use IV = 0, a MAC key k and you output the last
block of the MAC.  However you can't use a raw CBC-MAC as a variable
length MAC, without using one of the padding options.

The collision resistance property of a hash function (which SHA1 and
MD5 exhibit) is that it should be computationally expensive for an
attacker to find h( x ) == h( y ) st x != y.

The birthday attack is when you try to find any x and y hashing to the
same value, and a targetted collsiion is when you have a given x and
you want to find a y with the same hash value.

Your hash function is optimally collision resistant if you can't find
targetted collisions any more cheaply than 2^|output_size-1| average
tries, and can't find birthday collision in less than average
2^|output_size/2-1| tries.

So if we take the 256 bit CBC hash with an unknown key k, lets say
with input string x_1 || x_2 then the following computes a collision:

h1 = h( x1 )
h2 = h( x1 || x2 ) = h( x1 || x2 || h2 ^ h1 ^ x2 )

and you don't even need to know the key K to find this collision.  So
ok that's using different length messages, but if you have the key you
can construct more arbitrary collisions.

Yarrow calls for a (keyless) hash function rather than a MAC, so using
a MAC with a key related to inputs or related to K from yarrow may
invalidate some assumptions they are making.

This is not to say what you have isn't safe -- I haven't really
looked at it closely to see if this is a problem in practice -- but I
just wanted to point out it's not a good idea to just swap out
constructs without being sure the designers weren't relying on a
property you have removed.

And also, even if it turns out to be secure, once it's finished you
can't in fairness to the authors call it yarrow, so you lose the
ability to say "freeBSD uses yarrow", the closest you could come would
be to say it uses a "variant of yarrow with a blowfish-CBC-MAC instead
of a hash function" and then justify all of the assumptions and
reasons why you think it's still secure and does't violate any
assumptions the yarrow authors were making that matter to it's
security.

Adam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

IDE RAID (HPT-370/Abit KT7-RAID) install questions..

[Thomas Stromberg]

(excuse complete ignorance as far as IDE RAID below)

For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID
suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard
Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it.

So after a long day of hacking at getting Cyclone Interchange to run under
FreeBSD, I decided to go for the install today w/
2820-CURRENT. I set up the RAID BIOS to stripe together both of
the drives, each as a master on their own channel. The controller shows up
in the FreeBSD bootup, as well as the drives with UDMA100, but..

While "lsdev" from the boot floppy shows one drive, in FreeBSD  fdisk 
they show up as two 15G drives (ad4s1  ad6s1) rather then a 30G
concatanated one. 

Am I missing something here? I've never done IDE RAID, let alone on-board
RAID. Are they striped, but show up as seperate due to the lack of
emulation?

I went ahead and installed FreeBSD as a 6G partition.. and everything
looked good (and fast!), but when I rebooted, BootEasy saw the FreeBSD
bootblock, but it compained that it couldn't find any ufs
partition. However, "lsdev" from the floppies saw a ufs and swap
partition when checked.

Do I have to install / on a non-RAIDed drive so that the boot loader has a
chance?

In any case, much thanks goes to Soren for adding support for the
HPT-370 (and for the ATA drivers in general). I don't owe him just a
beer, but probably a keg or two for all the IDE boxes that I've installed
FreeBSD on :)


thomas r. stromberg  [EMAIL PROTECTED]
senior systems administratorhttp://www.afterthought.org/
research triangle commerce, inc.  1.919.657.1317




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kernel hash table implementation?

[Boris Popov]

On Fri, 25 Aug 2000, Archie Cobbs wrote:

 Is there a generic hash table implementation in the kernel somewhere?

Yes, see kern/kern_subr.c for hashinit() function.

--
Boris Popov
http://www.butya.kz/~bp/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: perlcc in current - xs_init and boot_DynaLoader

[Mark Murray]

 If i do a perlcc test.pl i get the folllowing , in CURRENT ?
 Must i define something beforehand, or is it broken ?

I'll take a look...

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

perlcc in current - xs_init and boot_DynaLoader

[Johan Kruger]

If i do a perlcc test.pl i get the folllowing , in CURRENT ?
Must i define something beforehand, or is it broken ?

-Wl,-E -lperl -lm  -L/usr/libdata/perl/5.6.0/mach/CORE -lperl -lm -lc -lcrypt
/usr/libdata/perl/5.6.0/mach/auto/IO/IO.so
/usr/libdata/perl/5.6.0/mach/auto/Fcntl/Fcntl.so
/tmp/ccJ97508.o: In function `xs_init':
/tmp/ccJ97508.o(.text+0x33a4): undefined reference to `boot_DynaLoader'
ERROR: In compiling code for test.pl.c !

--
Unix Software Developer/Engineer
E-Mail: Johan Kruger [EMAIL PROTECTED]
Date: 25-Aug-00
Time: 11:53:40

All good things come to those who ... runs FreeBSD
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message