Re: yarrow /dev/random
Mark writes: [...] FreeBSD is using an earlier version of T'so's code; I beiieve he improved it later, but it has no (or little) backtracking protection, and can be too easily attacked "from both sides". OK, I agree that that's an area where yarrow offers better protection. But it's not like Ted's code is broken or anything. We would break things using /dev/random by switching as is to yarrow, so this is why I don't like it: we're trying to improve things (Yarrows protection aginst the attacks you describe), but in order to do this we're doing some other damage. We should at least do no damage: we're improving one thing and breaking something else. Again, I'm not so sure; Yarrow goes to great trouble to protect its internal state; by blocking, I have this very nasty suspicion that this carefully guarded state is being disclosed. The moment you block, you are confiding in the fact that you have no updating entropy, and as a result /dev/urandom gan be attacked to get the internal state. The solution as I see it is to modify yarrow to bypass the yarrow output function and grab raw de-skewing function output for /dev/random output. You'd also want to do what John Kelsey was suggesting and XOR the bypassed de-skewing function output with /dev/urandom output as an additional safety measure. I'll look that up; It sounds like quite a departure from yarrow to me though; that makes me nervous. Well you leave most of yarrow alone, you just add the ability to reserve de-skewing function outputs for /dev/random. /dev/urandom still goes through the normal yarrow output function. OK - reasonable. ...there may not be a suitable monkey at the keyboard. What about a server in an unattended colo? MHO - hardware RNG. Unattended servers are a problem alright. One thing you can do is if your server has any private keys -- and it generally will have if it's doing crypto -- is mix the private key into the random pool along with the curren time. As the attacker doesn't know your private key (if he does it's game over anyway), you get a /dev/urandom which is secure. That works with what I already have: cat $privatekey /dev/random :-) The other thing you can do is mix in encrypted IVs people connecting to your server send you -- for example SSL, SSH, and PGP and so on tend to do this. It can't hurt because you're only mixing, and you can't destroy entropy with a good mixing function; and if you presume the collection of people who connect to you aren't colluding it helps. (If there is only one person communicating with you, it doesn't matter anyway, because they have their own plaintext.) We should encourage people to do these two things. I agree. we also need a device driver for Intel's harware RNG. I have some example code. 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
Re: PATCH: devfs mkIII test review please.
In message [EMAIL PROTECTED], Boris Popov writes: On Fri, 18 Aug 2000, Poul-Henning Kamp wrote: Missing: Rename Subdirs. Close some race conditions using guaranteed atomic operations. Mountoption (ro ?) to prevent new devices from appearing in an instance. All uses of cdevsw_add() needs to be use devfs_clone() instead. How should 3rd party KLDs implement cloning function ? For now it seems to be impossible to use a single binary for DEVFS and non-DEVFS case. Once the code has been shaken out, the cloning stuff will be standard. Right now I prefer to keep as much as possible under #ifdef DEVFS. See kern/vfs_conf.c for another good reason (besides KLD) to make the cloning stuff standard. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: official devfs patch for review
In message [EMAIL PROTECTED], Chris Costello writes: On Sunday, August 27, 2000, Boris Popov wrote: No, not all bits are incorporated. At least you've missed two important things. First: # cd /dev/fd # ls 0 1 2 # cd .. # ls 0 1 2 And second - directory names supplied by readdir() function contains junk characters at the end. I'm going to commit some fdescfs-related patches sometime soon next week. If you're not using the fdescfs code already, I can probably integrate my work into devfs, since that was the point of my work on fdescfs. I'm not quite ready to embrace fdescfs yet, I want to get devfs fully debugged first. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
At 11:07 PM -0700 2000/8/26, Mike Smith wrote: The Linux driver for the V and VI cards is (according to a reliable source) pretty awful. I've had to keep making modifications to them to get them to compile with newer and newer versions of the kernel, and while I keep contributing those changes back, they never seem to see the light of day. ;-( I have theoretically production-quality drivers from Adaptec which I will be committing as soon as I have time to test them (a few days, I hope). Cool! I can't wait! Is there anything I can do to help? -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
config(8) weirdness
Hi, Can anyone success compiling kernel with the following config? # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #optionsATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices In my box (freshly built today), this config doesn't make atapi-all.o, so that kernel linking get fails. To make kernel, I needed enable 'atapicd'. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
hints static wiring
When kernel is built with static device wiring (i.e. 'hints' line is enabled in the config file), is /boot/device.hints required? Doing 'make install' without /boot/device.hints is failed, saying "You must set up a /boot/device.hints file first." Is this right? -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config(8) weirdness
On 27 Aug, Motomichi Matsuzaki wrote:
Can anyone success compiling kernel with the following config?
# ATA and ATAPI devices
device ata
device atadisk # ATA disk drives
#device atapicd # ATAPI CDROM drives
device atapifd # ATAPI floppy drives
#device atapist # ATAPI tape drives
#optionsATA_STATIC_ID #Static device numbering
#optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices
In my box (freshly built today),
this config doesn't make atapi-all.o,
so that kernel linking get fails.
I've the same problem. At the moment I'm using the attahed patch to work
around this problem every time I configure a new kernel (cd
/sys/compile/YOURKERNEL; patch /path/to/Makefile.diff). Depending on
your config it may not apply to your Makefile. You just have to add the
atapi-all.o and $S/dev/ata/atapi-all.c differences.
Bye,
Alexander.
--
Failure is not an option. It comes bundled with your Microsoft product.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
--- Makefile.orig Sun Aug 20 16:55:43 2000
+++ MakefileSun Aug 20 16:56:16 2000
@@ -174,7 +174,7 @@
swap_pager.o vm_fault.o vm_glue.o vm_init.o vm_kern.o vm_map.o \
vm_meter.o vm_mmap.o vm_object.o vm_page.o vm_pageout.o \
vm_pager.o vm_swap.o vm_unix.o vm_zone.o vnode_pager.o ata-all.o \
- ata-disk.o ata-dma.o atapi-fd.o if_ed.o if_ed_isa.o fb.o \
+ ata-disk.o ata-dma.o atapi-all.o atapi-fd.o if_ed.o if_ed_isa.o fb.o \
splash.o vga.o atkbd.o atkbdc.o kbd.o schistory.o scmouse.o \
scterm.o scterm-dumb.o scterm-sc.o scvesactl.o scvgarndr.o \
scvidctl.o scvtb.o syscons.o sysmouse.o apm.o atomic.o \
@@ -348,7 +348,7 @@
$S/vm/vm_object.c $S/vm/vm_page.c $S/vm/vm_pageout.c \
$S/vm/vm_pager.c $S/vm/vm_swap.c $S/vm/vm_unix.c $S/vm/vm_zone.c \
$S/vm/vnode_pager.c $S/dev/ata/ata-all.c $S/dev/ata/ata-disk.c \
- $S/dev/ata/ata-dma.c $S/dev/ata/atapi-fd.c $S/dev/ed/if_ed.c \
+ $S/dev/ata/ata-dma.c $S/dev/ata/atapi-all.c $S/dev/ata/atapi-fd.c
+$S/dev/ed/if_ed.c \
$S/dev/ed/if_ed_isa.c $S/dev/fb/fb.c $S/dev/fb/splash.c \
$S/dev/fb/vga.c $S/dev/kbd/atkbd.c $S/dev/kbd/atkbdc.c \
$S/dev/kbd/kbd.c $S/dev/syscons/schistory.c \
@@ -1802,6 +1802,9 @@
${NORMAL_C}
ata-dma.o: $S/dev/ata/ata-dma.c
+ ${NORMAL_C}
+
+atapi-all.o: $S/dev/ata/atapi-all.c
${NORMAL_C}
atapi-fd.o: $S/dev/ata/atapi-fd.c
5.0-current 20000826 snapshot problems
I just had a problem trying to install the latest -current snapshot from the 8/26 snap. Background: Windows trashed my hard disk on one of my machines, so I had to do clean install. Since I run -current on that machine anyways, I decided to try the latest snapshot to restore it. Booting kern.flp (i386) gives me (pardon any typos, I'm looking at one screen and typing on the other): FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed can't load 'kernel' can't load 'kernel.old' Type '?' for a list of commands. ok ls - [ the ls was typed by me ] -- / d boot kernel.gz ok boot kernel.gz don't know how to load module '/kernel.gz' This isn't a show stopper for me, since I can restore the machine via other methods, but since I haven't done a clean FreeBSD install in a while, I thought I would try our latest greatest to see how it worked. As you can see, it didn't go very well :-(. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] - End of forwarded message from Mike Pritchard - -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow /dev/random
Mark writes: Adam writes: OK, I agree that that's an area where yarrow offers better protection. But it's not like Ted's code is broken or anything. We would break things using /dev/random by switching as is to yarrow, so this is why I don't like it: we're trying to improve things (Yarrows protection aginst the attacks you describe), but in order to do this we're doing some other damage. We should at least do no damage: we're improving one thing and breaking something else. Again, I'm not so sure; Yarrow goes to great trouble to protect its internal state; by blocking, I have this very nasty suspicion that this carefully guarded state is being disclosed. The moment you block, you are confiding in the fact that you have no updating entropy, and as a result /dev/urandom gan be attacked to get the internal state. Are we talking Yarrow or Ts'o's algorithm? If you have no entropy, both Yarrow and Ts'o algorithm for non-blocking IO aren't going to leak the state any time soon for computationally bounded attackers -- they only release output through one way functions (SHA1 in Ts'o and counter-mode 3DES in Yarrow-160). - Yarrow-160 has it's Gate operation to ensure you don't compromise too much old output if you obtain the pool state due to host compromise. - Ts'o's algorithm does something analogous with SHA1/MD5 (depending on which version you're using), by modifying the pool when you draw output. One thing you can do is if your server has any private keys -- and it generally will have if it's doing crypto -- is mix the private key into the random pool along with the curren time. As the attacker doesn't know your private key (if he does it's game over anyway), you get a /dev/urandom which is secure. That works with what I already have: cat $privatekey /dev/random :-) Yes. But the /dev/random device is traditionally crw-r--r-- which means user processes can't write to it. So you'd have to be root to do that. What could be done for yarrow is to change the device permissions to crw-rw-rw- and mix into a shared user source and set k_of_n_thresh so that the user can only trigger fast reseeds, and consider slow reseed de-skewing function output for blocking /dev/random; or just add user input with an entropy estimate of 0 so they can't affect reseeding, and draw fast reseed de-skewing function output for block /dev/random (slow output may be too slow). Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Newbusifying ed broke it
Thus spake Seigo Tanimura ([EMAIL PROTECTED]): - bus_space_write_1(sc-bst, sc-bsh, regno, data); + bus_space_write_1(rman_get_bustag(sc-port_res), rman_get_bushandle(sc-port_res), regno, data); Hmm. I used sc-bst/h to save function calls to rman_get_bus*, as many drivers use it. But obvioiusly I forgot to assign the values. I REALLY wonder why it worked for me ... strange. Thanks for fixing that. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
BTW, these IBM 75GXP drives off of the HPT-370 are amazingly fast for IDE. From my own measurements I'd say these drives are amazingly fast, period. They compete rather well with SCSI drives. A big thanks to sos for the HPT-370/UDMA100 support! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow /dev/random
Mark Murray wrote: [...] Again, I'm not so sure; Yarrow goes to great trouble to protect its internal state; by blocking, I have this very nasty suspicion that this carefully guarded state is being disclosed. The moment you block, you are confiding in the fact that you have no updating entropy, and as a result /dev/urandom gan be attacked to get the internal state. You would normally assume that an attacker knows when you are not adding in entropy. In Yarrow, the assumption is that the internal state is (sufficiently) protected by both a hash and the blockcipher so blocking will not affect Yarrow's security properties AFAICS. Yes, /dev/urandom can be attacked at the point of blocking but given robust primitives the complexity is still 2^(sizeof(hash)) which is exactly the complexity Yarrow claims to provide. This is completely independent of any knowledge of reseed timings (or lack thereof). Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
Mike Smith wrote: (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. [...] 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. This is not an "IDE RAID" controller. It's an IDE controller with some lame "RAID" software in the BIOS. We don't support this. Consider using vinum as an alternative. It is supported. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
devfs
I'm sure you know this already, but I just want to reiterate. I have done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did a cvsup in the "wee" hours in the morning. I then did make world in /usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. The system should be clean. Correct me if I am wrong. If I put "option DEVFS" in my kernel , build/install that kernel, my computer will not bot up completely. I will have to enter single user with an errr message stating "/dev: no such file or directory" Mounting of fstab filesystems fails. press enter for /bin/sh My /dev directory exists. Once I rebuild the kernel with no DEVFS it all works, but I like devfs as it makes all the device files that i need for my sound card as an example. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
In message [EMAIL PROTECTED], Tony Johnson writes: I'm sure you know this already, but I just want to reiterate. I have done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did a cvsup in the "wee" hours in the morning. I then did make world in /usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. The system should be clean. Correct me if I am wrong. If I put "option DEVFS" in my kernel , build/install that kernel, my computer will not bot up completely. I will have to enter single user with an errr message stating "/dev: no such file or directory" Mounting of fstab filesystems fails. press enter for /bin/sh My /dev directory exists. Once I rebuild the kernel with no DEVFS it all works, but I like devfs as it makes all the device files that i need for my sound card as an example. Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
Sorry for the repeat. I was playing with the sendmail 8.11.0 you guys have provided... But anyway, if DEVFS is in my fstab or not it gets mounted under /dev , as you point out. I guess this is the problem because I have to remove "options DEVFS" from my kernel in single user for my system to boot. Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Tony Johnson writes: I'm sure you know this already, but I just want to reiterate. I have done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did a cvsup in the "wee" hours in the morning. I then did make world in /usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. The system should be clean. Correct me if I am wrong. If I put "option DEVFS" in my kernel , build/install that kernel, my computer will not bot up completely. I will have to enter single user with an errr message stating "/dev: no such file or directory" Mounting of fstab filesystems fails. press enter for /bin/sh My /dev directory exists. Once I rebuild the kernel with no DEVFS it all works, but I like devfs as it makes all the device files that i need for my sound card as an example. Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
One last note, if this is a case for a functional union fs. I'd like to see my mistyping and the system combine things into one device directory so this type of problem will not stop my system frm booting up completely... Tony Johnson wrote: Sorry for the repeat. I was playing with the sendmail 8.11.0 you guys have provided... But anyway, if DEVFS is in my fstab or not it gets mounted under /dev , as you point out. I guess this is the problem because I have to remove "options DEVFS" from my kernel in single user for my system to boot. Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Tony Johnson writes: I'm sure you know this already, but I just want to reiterate. I have done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did a cvsup in the "wee" hours in the morning. I then did make world in /usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. The system should be clean. Correct me if I am wrong. If I put "option DEVFS" in my kernel , build/install that kernel, my computer will not bot up completely. I will have to enter single user with an errr message stating "/dev: no such file or directory" Mounting of fstab filesystems fails. press enter for /bin/sh My /dev directory exists. Once I rebuild the kernel with no DEVFS it all works, but I like devfs as it makes all the device files that i need for my sound card as an example. Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow /dev/random
That works with what I already have: cat $privatekey /dev/random :-) Yes. But the /dev/random device is traditionally crw-r--r-- which means user processes can't write to it. So you'd have to be root to do that. I go one further; at close, I do an explicit reseed, and I make sure that it is root doing the writing. What could be done for yarrow is to change the device permissions to crw-rw-rw- and mix into a shared user source and set k_of_n_thresh so that the user can only trigger fast reseeds, and consider slow reseed de-skewing function output for blocking /dev/random; or just add user input with an entropy estimate of 0 so they can't affect reseeding, and draw fast reseed de-skewing function output for block /dev/random (slow output may be too slow). The estimate for "user" (really root) input is currently 0, except that I tie it to explicit (fast) reseeds. It shouldn't be a problem to tie it to a trickle-feed, and allow that to do fast-only reseeds after considerable lengths of time. 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
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
It seems [EMAIL PROTECTED] wrote: BTW, these IBM 75GXP drives off of the HPT-370 are amazingly fast for IDE. From my own measurements I'd say these drives are amazingly fast, period. They compete rather well with SCSI drives. A big thanks to sos for the HPT-370/UDMA100 support! Well, this wouldn't have happend without Jeroen (asmodai) having good contacts at HighPoint, so I thank him for making this possible. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Installkernel
Just a little usability observation(or I am too lazy to script_my_own_tools and want to whine!) The method of building and installing a kernel to me seems a bit off.. Both the buildworld and installworld targets default to GENERIC, yet GENERIC is a file checked into the -CURRENT CVS repository.. Any changes to this file will get blown away if whenever you update the sources unless you explicity exclude this file. No one I know runs BSD with a GENERIC kernel, they have specific requirements for the hardware in their machines. Having to specify which kernel to build with the KERNEL= parameter seems to indicate that people should be running GENERIC kernels all the time as it is the default. This just doesnt seem right. I know a script could easily be written to grab a filename out of something like /boot/loader.conf to get which kernel config file you want to use by default.. Are there any plans to change this or is this method final? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposal to clarify mbuf handling rules
In looking at some of the problems relating to divert, bridging,
etc., it's apparent that lots of code is breaking one of the rules
for handling mbufs: that mbuf data can sometimes be read-only.
Each mbuf may be either a normal mbuf or a cluster mbuf (if the
mbuf flags contains M_EXT). Cluster mbufs point to an entire page
of memory, and this page of memory may be shared by more than one
cluster mbuf (see m_copypacket()). This effectively makes the mbuf
data read-only, because a change to one mbuf affects all of the
mbufs, not just the one you're working on. There have been (and
still are) several FreeBSD bugs because of this subtlety.
A test for an mbuf being "read-only" is:
if ((m-m_flags M_EXT) != 0 MEXT_IS_REF(m)) ...
So an implicit rule for handling mbufs is that they should be
treated as read-only unless/until you either check that it's not,
and/or pullup a new (non-cluster) mbuf that covers the data area
that you're going to modify.
However, many routines that take an mbuf parameter assume that the
mbuf given to them is modifiable and proceed to write all over it.
A few examples are: ip_input(), in_arpinput(), tcp_input(),
divert_packt(), etc.
In practice, this is often not a problem because the mbuf is actually
modifiable (because there are no other references to it). But this
is just because we've been lucky. When you throw things like bridging,
dummynet, divert, and netgraph into the mix, not to mention other
site-specific hacks, then these assumptions no longer hold. At the
minimum these assumptions should be clearly commented, but that's
not even the case right now.
Routines that don't change any data, or that only do m_pullup(),
M_PREPEND(), m_adj(), etc. don't have a problem.
So I'd like to propose a mini-project to clarify and fix this problem.
Here is the propsal:
1. All routines that take an mbuf as an argument must not assume
that any mbuf in the chain is modifyable, unless expclicitly
and clearly documented (in the comment at the top of the function)
as doing so.
2. For routines that don't modify data, incorporate liberal use
of the "const" keyword to make this clear. For example, change
struct ip *ip;
ip = mtod(m, struct ip *);
to:
const struct ip *ip;
ip = mtod(m, const struct ip *);
3. For any routines that do need to modify mbuf data, but don't
assume anything about the mbuf, alter those routines to do
an m_pullup() when necessary to make the data are they are
working on modifiable. For example:
struct ip *ip;
/* Pull up IP header */
if (m-m_len sizeof(*ip) !(m = m_pullup(m, sizeof(*ip
return;
ip = mtod(m, struct ip *);
#ifdef NEW_CODE_BEING_ADDED
/* Make sure the IP header area is writable */
if ((m-m_flags M_EXT) != 0 MEXT_IS_REF(m)) {
/* m_pullup() *always* prepends a fresh, non-cluster mbuf */
if ((m = m_pullup(m, sizeof(struct ip))) == 0)
return;
ip = mtod(m, struct ip *);
}
#endif
/* Modify the header */
ip-ip_len = 123;
...
The only negative is the addition of the NEW_CODE_BEING_ADDED code
in the relevant places. In practice this test will usually fail,
as most mbufs are modifiable, so there should be no noticable
slowdown. However, robustness should improve, especially when
bridging, diverting, etc.
What do people think? If this is generally agreeable I'll try to
work on putting together a patch set for review.
-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: Proposal to clarify mbuf handling rules
On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote: What do people think? If this is generally agreeable I'll try to work on putting together a patch set for review. Myself and Ian Dowse have been talking about almost this issue recently in relation to sbcompress. At the moment sbcompress is too conservative about compressing mbuf chains, with the result that it is easily possible to run many machines out of mbuf clusters. (We've seen this problem with netscape and kioslave). At the moment sbcompress only compresses into mbufs, where it could also compress into clusters, providing they have a reference count of 1. However, this still means it can't compress into jumbo buffers associated with gigabit ethernet and the like. We were thinking it might be a good idea to have a flag associated with mbufs which means they are writable, providing the reference count is 1. Then we can provide a macro for checking writability. This flag could be set on jumbo ethernet buffers, but not sendfile buffers (for example). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote:
Each mbuf may be either a normal mbuf or a cluster mbuf (if the
mbuf flags contains M_EXT). Cluster mbufs point to an entire page
of memory, and this page of memory may be shared by more than one
cluster mbuf (see m_copypacket()).
Clusters are currently 2048 bytes in size - which I don't think it
a page on the alpha or the i386. (Not that this is really important).
his effectively makes the mbuf
data read-only, because a change to one mbuf affects all of the
mbufs, not just the one you're working on. There have been (and
still are) several FreeBSD bugs because of this subtlety.
A test for an mbuf being "read-only" is:
if ((m-m_flags M_EXT) != 0 MEXT_IS_REF(m)) ...
You should also check that it's really a cluster you're looking
at:
if ((m-m_flags M_EXT) != 0
(MEXT_IS_REF(m) || (m)-m_ext.ext_free != NULL)) {
/* data is read only */
}
(This is why the flag I was talking about in the other mail
would be useful for spotting other cases where the storage
may be writable, even if it's not a cluster).
Cleaning up this sounds like a good plan. It would be worth
getting Ian and Bosko involved if possible.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: yarrow /dev/random
Adam writes: Yes. But the /dev/random device is traditionally crw-r--r-- which means user processes can't write to it. So you'd have to be root to do that. What could be done for yarrow is to change the device permissions to crw-rw-rw- and mix into a shared user source and set k_of_n_thresh so that the user can only trigger fast reseeds, and consider slow reseed de-skewing function output for blocking /dev/random; or just add user input with an entropy estimate of 0 so they can't affect reseeding, and draw fast reseed de-skewing function output for block /dev/random (slow output may be too slow). I'm not on the freebsd.org lists, so I've missed some of the discussion on this threads; I was pointed to the web archives by Adam. A couple of comments here. It was always the intention that /dev/random be 0666, and in my implementation, writing to /dev/random mixed the input into the entropy pool *without* changing the entropy estimate. The mixing algorithm was carefully chosen so that even if an attacker mixed all zero's, or some other carefully chosen input, he/she would gain no more information about the pool than he/she already had (which hopefully is non, of course. :-) I used an ioctl which atomically adds data into the entropy pool *and* updates the entropy count. I did this because (a) the (trusted, privileged) user-mode random collection daemon has the best idea of how much entropy the input data has, and (b) if someone is actively drawing on the entropy pool, you want to update the entropy count at exactly the same time as you add the entropy to the entropy pool. As far as yarrow versus the current design, I've certainly looked at yarrow, and I've certainly considered adding some of yarrow's design into my /dev/random implementation. Given that I strongly recommend that the 512 bytes of entropy be saved from /dev/random at shutdown time, and then written to /dev/random at startup time (without updating the entropy estimate), I question how realistic the attack scenario that Yarrow tries so hard to defend against. The other problem I have against the Yarrow design is that it depends on the strength of the crypto primitives a bit more than I feel comfortable doing. In my /dev/random design, which draws heavily from the philosophy of PGP's RNG, we use a crypto primitive for whitening, but as long as there is a sufficient amount of system entropy getting poured into the pool, the crypto primitive could be replaced with a CRC function (or even an additive checksum!) without really doing a lot of damage to system security. I also feel very strongly that something like 3DES/AES counter mode is something which a crypto application which needs a lot of session keys should be implemented in user-mode in a library, probably. There's no real reason why that needs to be implemented in the kernel --- /dev/random needs to be there because it's doing all of the sampling of the system environment, and the entropy pool needs to be stored securely and easily updated by the entropy collection routines. So it may be that the best way to handle things is to implement the upper level of a yarrow-like design in a usermode library, and which does its "catastrophic reseeding" by reading from /dev/random as necessary. Certainly that is my bias at this point. - Ted To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installkernel
From: "James Johnson" [EMAIL PROTECTED] The method of building and installing a kernel to me seems a bit off.. Both the buildworld and installworld targets default to GENERIC, yet GENERIC is a file checked into the -CURRENT CVS repository.. Any changes to this file will get blown away if whenever you update the sources unless you explicity Your supposed to copy GENERIC to a new name, and then build your kernel with that file. You can change the default kernel to build by specifying: KERNEL= MY-KERNEL in the /etc/make.conf file. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
In article [EMAIL PROTECTED],
Brian Fundakowski Feldman [EMAIL PROTECTED] wrote:
If this is a problem with sbsize, this should take care of any possibility
ever of there being a problem...
I tried your patch, but it panics reliably on start-up:
Automatic boot in progress...
/dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1a: clean, 335363 free (8667 frags, 40837 blocks, 1.1% fragmentation)
/dev/da0s1e: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1e: clean, 1966150 free (46222 frags, 239991 blocks, 1.0% fragmentation)
Doing initial network setup: hostname.
panic: reducing sbsize: lost count, uid = 0
Debugger("panic")
Stopped at Debugger+0x34: movb$0,in_Debugger.390
db trace
Debugger(c0280363) at Debugger+0x34
panic(c027fc80,0,2400,0,c7c20f74) at panic+0x70
chgsbsize(0,c7c20f78,2400,,7fff) at chgsbsize+0x33
sbreserve(c7c20f74,2400,c7c20f00,c77ee440) at sbreserve+0x6a
soreserve(c7c20f00,2400,a280,c7c20f00,c02bb368) at soreserve+0x1c
udp_attach(c7c20f00,0,c77ee440,0,c86f6f80) at udp_attach+0x2a
socreate(2,c86f6f20,2,0,c77ee440) at socreate+0xe8
socket(c77ee440,c86f6f80,8085098,bfbffda0,3) at socket+0x3e
syscall2(2f,2f,2f,3,bfbffda0) at syscall2+0x1f1
Xint0x80_syscall() at Xint0x80_syscall+0x25
The value of *hiwat in chgsbsize() is 0:
db x/ul 0xc7c20f78
0xc7c20f78: 0
I can't get it to generate a core dump that it will recognize on
reboot, and I'm not set up for remote gdb on this machine. But I can
check anything you'd like with ddb.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
alpha devfs feedback
I compiled and booted on alpha. It sees my ad0 now. Plus it also sees the 3 'da' disks that were found. The only real problem is that it won't see the partitions made for 'dangerously dedicated' 'da' disks. What's the plan for addressing this? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installkernel
James Johnson wrote: Having to specify which kernel to build with the KERNEL= parameter seems to indicate that people should be running GENERIC kernels all the time as it is the default. No, it seems to indicate that you should specify KERNEL=YOURKERNEL in make.conf. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux ABI no longer supports staroffice
Marcel: Up until this weekend, I was able to use the staroffice52 port with little problem (I had installed it earlier without benefit of the port and it worked fine.) I did a 5.0-current kernel rebuild on Thursday with sources current on that day and things were fine. When I rebuilt my kernel yesterday afternoon with sources from Saturday morning, the port stopped working. I get the following error messages I18N: X Window System doesn't support locale "C" _X11TransSocketOpen: socket() failed for local _X11TransSocketOpenCOTSClient: Unable to open socket for local _X11TransOpen: transport open failed for local/dinolt1.bingdrive:0 setup.bin: cannot open display ":0.0" Please check your "DISPLAY" environment variable, as well as the permissions to access that display (See "man X" resp. "man xhost" for details) I am running the install as root. The Window Manager is up and running, other programs including linux-netscape have no trouble running in the same environment. This is not a clue for me, but it may mean something to others. (By the way, these errors did not appear prior to the changes.) I was wondering whether the setrlimit changes had something to do with this. This seems to be the major change to the linux code in the last few days. Apparently you were the one to make those changes, so I am writing to you (Marcel) Anyway, thought someone should know. George Dinolt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposal to clarify mbuf handling rules
On Sun, 27 Aug 2000 14:25:55 -0700 (PDT), Archie Cobbs [EMAIL PROTECTED] said: However, many routines that take an mbuf parameter assume that the mbuf given to them is modifiable and proceed to write all over it. s/assume/require as a necessary precondition/ It's not a coding error, it's part of the specification. No, it's not documented -- but it's pretty clear from the design of the original code. 3. For any routines that do need to modify mbuf data, but don't assume anything about the mbuf, alter those routines to do an m_pullup() when necessary to make the data are they are working on modifiable. m_pullup is evil. It would be better to fix the places (i.e., ip_input and ip_output) which make the modification necessary. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
Mike Pritchard wrote: I just had a problem trying to install the latest -current snapshot from the 8/26 snap. Background: Windows trashed my hard disk on one of my machines, so I had to do clean install. Since I run -current on that machine anyways, I decided to try the latest snapshot to restore it. Booting kern.flp (i386) gives me (pardon any typos, I'm looking at one screen and typing on the other): FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/random device permissions (Re: yarrow /dev/random)
Ted writes: A couple of comments here. It was always the intention that /dev/random be 0666, and in my implementation, writing to /dev/random mixed the input into the entropy pool *without* changing the entropy estimate. I see. This is not clear. We recently set it /dev/random to group writeable for a server application so we could write into /dev/random without being root. I'll change that to 0666. I think the confusion may come from a misunderstanding about the access control mechanism on the ioctls. (I tried 0666 just now and called the ioctl to zero the pool as a user and it denies access based on not being root -- so 0666 is in fact safe). Everyone seems to be setting it to 0644. Default linux Redhat, Slackware, freeBSD etc., etc is 0644. This is wrong, and as a result applications which really could benefit /dev/random by writing (private keys, encrypted IVs, user passwords, etc) aren't doing it. These tricks can really help mitigate lack of input device entropy in server environments. Given the importance of this, we ought to draw this to the attention of distribution maintainers and get it fixed. Bugtraq may be a good way to get the word out? The rest of Ted's comments about Yarrow and /dev/random design are interesting -- next mail. Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
On Sun, Aug 27, 2000 at 09:33:21PM +0900, Motomichi Matsuzaki wrote: When kernel is built with static device wiring (i.e. 'hints' line is enabled in the config file), is /boot/device.hints required? Doing 'make install' without /boot/device.hints is failed, saying "You must set up a /boot/device.hints file first." Is this right? You should read cvs-all. There was a commit by Peter which forces you to install a /boot/device.hints file to install a kernel as an anti-foot shooting measure. An empty file (ie touch /boot/device.hints) is acceptable for those who don't want to use a hints file. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken definition for {g|s}etrlimit
Sean-Paul Rees wrote:
On Sun, Aug 27, 2000 at 05:24:07PM -0700, Marcel Moolenaar wrote:
"George W. Dinolt" wrote:
I was wondering whether the setrlimit changes had something to do with
this. This seems to be the major change to the linux code in the last
few days. Apparently you were the one to make those changes, so I am
writing to you (Marcel)
Can you track down which change caused the failure. I haven't
experienced any problems so far. I'll try running SO myself in the mean
time.
I'm also running -current, however, StarOffice will barely even run! It seems
that all the Linux apps on -current run at about 1/10th their speed. It was
unbearable (and also unusable).
This has been happening to me for the last few builds of -current. Maybe I'm
doing something wrong or need to reinstall something. Can you offer any
pointers?
It seems that the recent change to {g|s}etrlimit hit upon a bug in the
FreeBSD syscall definition. Can you tell me if the following patch
solves the problem?
(don't forget to run 'make sysent.c' in /sys/kern before running config)
Index: syscalls.master
===
RCS file: /home/ncvs/src/sys/kern/syscalls.master,v
retrieving revision 1.81
diff -u -r1.81 syscalls.master
--- syscalls.master 2000/07/29 10:05:23 1.81
+++ syscalls.master 2000/08/28 01:48:38
@@ -223,8 +223,8 @@
141COMPAT BSD { int getpeername(int fdes, caddr_t asa, int
*alen); }
142COMPAT BSD { long gethostid(void); }
143COMPAT BSD { int sethostid(long hostid); }
-144COMPAT BSD { int getrlimit(u_int which, struct ogetrlimit
*rlp); }
-145COMPAT BSD { int setrlimit(u_int which, struct ogetrlimit
*rlp); }
+144COMPAT BSD { int getrlimit(u_int which, struct orlimit
*rlp); }
+145COMPAT BSD { int setrlimit(u_int which, struct orlimit
*rlp); }
146COMPAT BSD { int killpg(int pgid, int signum); }
147STD POSIX { int setsid(void); }
148STD BSD { int quotactl(char *path, int cmd, int uid, \
@@ -294,10 +294,10 @@
192STD POSIX { int fpathconf(int fd, int name); }
193UNIMPL NOHIDE nosys
194STD BSD { int getrlimit(u_int which, \
- struct orlimit *rlp); } \
+ struct rlimit *rlp); } \
getrlimit __getrlimit_args int
195STD BSD { int setrlimit(u_int which, \
- struct orlimit *rlp); } \
+ struct rlimit *rlp); } \
setrlimit __setrlimit_args int
196STD BSD { int getdirentries(int fd, char *buf, u_int
count, \
long *basep); }
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
merits of the iterative guessing attack (Re: yarrow /dev/random)
Ted writes: [...] As far as yarrow versus the current design, I've certainly looked at yarrow, and I've certainly considered adding some of yarrow's design into my /dev/random implementation. Given that I strongly recommend that the 512 bytes of entropy be saved from /dev/random at shutdown time, and then written to /dev/random at startup time (without updating the entropy estimate), I question how realistic the attack scenario that Yarrow tries so hard to defend against. This would be the "iterative guessing attack" the yarrow authors design against to recover from state compromise. One argument against the realism of the iterative guessing attack might be you need root to obtain the state, and that if you have root you can easily change other things to maintain ability to predict crypto keys. Say like linking /dev/[u]random to /dev/zero, or something marginally more subtle, or modifying target binaries, or grabbing the target servers private key from /dev/keymem. However probably just grabbing the pool state with ioctl RNDGETPOOL and then getting out may be less likely to trigger alarms. Arguments in favor of the attempts to recover from state compromise: - The bootstrap problem -- where did /dev/random get it's start state from before there was a seed file to load; all the entropy samples went in small chunks, and if the machine was outputting randomness the whole time, the attacker may be able to maintain the "iterative guessing attack" right from install time. - Situations where the server has no writeable media to store it's /var/run/seed -- boot of CD or harddisk mounted read only plus /var mounting on a ram disk. In this scenario the attacker gets to mount - Distributions which don't include the shutdown and startup state save and restore. (I've got an old slackware installation at home with /dev/random, but no state saving and loading in /etc/rc.d/*). - Default wrong permissions on /dev/[u]random -- discards any user entropy (primarily an argument to persuade people to fix the permissions). If we buy these arguments, then Yarrow's conservative recovery strategies are a good idea. I also feel very strongly that something like 3DES/AES counter mode is something which a crypto application which needs a lot of session keys should be implemented in user-mode in a library, probably. There's no real reason why that needs to be implemented in the kernel --- /dev/random needs to be there because it's doing all of the sampling of the system environment, and the entropy pool needs to be stored securely and easily updated by the entropy collection routines. So it may be that the best way to handle things is to implement the upper level of a yarrow-like design in a usermode library, and which does its "catastrophic reseeding" by reading from /dev/random as necessary. Certainly that is my bias at this point. It's certainly preferable to keep the line count in the kernel down. Yarrow is quite complex. However, unprivileged users can do DoS attacks against /dev/random -- cat /dev/random /dev/null. This and the risk of server stall where there is no input device means many people avoid /dev/random for servers and use /dev/urandom. And use /dev/random just for long term private key generation. To use /dev/random as a source of state compromise recovery for a user land yarrow, you'd want a way to be able to use non-blocking IO to atomically read some chunk of bits (100 for fast and 160 for slow reseeds with Yarrow-160) from /dev/random otherwise you'd still be vulnerable to iterative guessing attacks based on other /dev/urandom processes outputs. Looking at the /dev/random code, I think you'll get a short read if not enough bits are available. A more integrated yarrow can avoid the risk of DoS attack preventing state compromise recovery by reserving some of the /dev/random output for state compromise recovery and leaving the rest for /dev/random users. Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Monitor dies and doesn't come back.
I've been having a strange problem recently after installing a new harddrive.. the harddrive works fine in other OS's, but in FreeBSD, (seemingly after the HD install), the Monitor (CTX VL19") goes into powersaving and you cant get it back without doing a cold reboot.. not even a warm reboot will work. I am not sure exactly what is happening here, perhaps something borked? I have a Western Digital Caviar 45GB drive running at UDMA33. dmesg output follows: FreeBSD 5.0-CURRENT #1: Sat Aug 26 00:24:22 MDT 2000 [EMAIL PROTECTED]:/usr2/src/sys/compile/FREEBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 501138733 Hz CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) avail memory = 127107072 (124128K bytes) Preloaded elf kernel "kernel" at 0xc037e000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc037e09c. Preloaded elf module "splash_bmp.ko" at 0xc037e0ec. Preloaded elf module "vesa.ko" at 0xc037e190. Preloaded splash_image_data "/boot/splash.bmp" at 0xc037e22c. Preloaded elf module "snd_emu10k1.ko" at 0xc037e27c. Preloaded elf module "snd_pcm.ko" at 0xc037e320. Pentium Pro MTRR support enabled VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc02f43b7 (1000117) VESA: 3dfx Interactive, Inc. npx0: math processor on motherboard pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: Intel 82443BX (440 BX) host to PCI bridge at 0.0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 5 pci0: Intel 82371AB Power management controller at 7.3 pcm0: Creative EMU10K1 port 0xe400-0xe41f irq 10 at device 13.0 on pci0 pci0: 3Dfx Voodoo 3 graphics accelerator at 15.0 irq 11 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ed0 at port 0x240-0x25f iomem 0xd8000-0xd9fff irq 3 on isa0 ed0: address 00:e0:29:16:cb:72, type SMC8416T (16 bit) sc1: System console on isa0 sc1: MDA 16 virtual consoles, flags=0x0 vga1: Generic ISA VGA at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled ad0: 9671MB WDC AC310100B [19650/16/63] at ata0-master using UDMA33 ad1: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata0-slave using UDMA33 acd0: CD-RW PLEXTOR CD-R PX-W8432T at ata1-master using WDMA2 acd1: CDROM FX001DE at ata1-slave using PIO3 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted Any help would be appreciated. Thanks! (Sorry, no panic, so that's all I could get) -JD- Jason DiCioccio - IBM Global Services - [EMAIL PROTECTED] - www.ibm.com Systems Admin - Open Domain Server - [EMAIL PROTECTED] - www.ods.org FreeBSD - The Power to Serve - - www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP and softupdates?
In upgrading my system I've bought a shiny new SMP mobo to go with my new 30gb Deskstar... The nice thing about this new board is my HighPoint HPT366 based IDE controller works now (Buggy Phoenix BIOSes prevented it from working before). Perhaps in a rush to get started, I've compiled and been using a SMP kernel even before the second processor arrives. This has worked fine, however I've gotten some rather weird hangs and crashes resulting in a nice lost+found directory on the usr fs. In trying to track this down, I've tried a UP kernel which seems to not have crashed where the SMP one did before.. I'm sure it's not a cooling issue as the sole CPU is staying below 35C. However I'm curious: * Are there any known issues with SMP and softupdates as of late? * Is running one processor with an SMP kernel such a horrible idea (other than performance wise)? I'm glad I can run my harddrives (Caviar and Deskstar) at ATA66 speeds.. but having to tread lightly is sucking. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
David Malone writes: We were thinking it might be a good idea to have a flag associated with mbufs which means they are writable, providing the reference count is 1. Then we can provide a macro for checking writability. This flag could be set on jumbo ethernet buffers, but not sendfile buffers (for example). That's a good idea.. I forgot about things like sendfile, where the mbuf is read-only due to other reasons. So we need some kind of flag it seems. That's good -- it makes it even more obvious. -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
subscribe
subscribe _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
On Sun, 27 Aug 2000, John Polstra wrote: In article [EMAIL PROTECTED], Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: If this is a problem with sbsize, this should take care of any possibility ever of there being a problem... I tried your patch, but it panics reliably on start-up: Woops, I have the KASSERT bungled up. Please change KASSERT(to *hiwat uip != NULL, to KASSERT(to = *hiwat || uip != NULL, -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
hintmode not found.
Someone stashed a refewrence to an extern int hintmode in /sys/kern/subr_bus.c a couple of days ago - where's it actually defined? Mr Grep cant seem to find in /sys. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Just a suggestion, but isn't this the type of thing that should be added to UPDATING? "This file contains a list, in reverse chronologocal order, of major breakages in tracking -current." TOny. On Sun, 27 Aug 2000, Brooks Davis wrote: On Sun, Aug 27, 2000 at 09:33:21PM +0900, Motomichi Matsuzaki wrote: When kernel is built with static device wiring (i.e. 'hints' line is enabled in the config file), is /boot/device.hints required? Doing 'make install' without /boot/device.hints is failed, saying "You must set up a /boot/device.hints file first." Is this right? You should read cvs-all. There was a commit by Peter which forces you to install a /boot/device.hints file to install a kernel as an anti-foot shooting measure. An empty file (ie touch /boot/device.hints) is acceptable for those who don't want to use a hints file. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
