Re: *** HEADS UP *** rc.conf changes (security)
Hopefully sysinstall will be smarter about writing these overrides than it is about writing the "USA_RESIDENT=NO" override to /etc/make.conf. It doesn't do that anymore. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fcntl and /dev/random
Hi
I'm looking at this; I'll have something by the end of the weekend
for 5-CURRENT; 4-STABLE will take a bit longer. I don't think I'll
dop anything for 3-* as it is at its end-of-life.
Domo Arrigato!
M
Setting status flags using F_SETFL command of fcntl(2) on the file
descriptor, which is returned by open(2)ing /dev/random, seems not to
be supported. For example, when I run following code;
#include stdio.h
#include errno.h
#include fcntl.h
main()
{
int fd;
fd = open("/dev/random", O_RDONLY);
if (fcntl(fd, F_SETFL, O_NONBLOCK) == -1) {
printf("%s\n", strerror(errno));
}
}
3.4-RELEASE(and possibly 3.5 and 3.5.1) and 4.1-RELEASE/4.1-STABLE say
`Inappropriate ioctl for device' and 5-current says `Operation not
supported by device'.
I've found above in BIND9's source and its `named' program complains
everytime it's invoked.
Should I fix BIND9's code? or wait for fcntl's F_SETFL being
supported on FreeBSD?
Actually, in BIND9, fd is already open(2)ed with `O_RDONLY | O_NONBLOCK'
and setting O_NONBLOCK status with fcntl(2) is not needed, which means
that fixing BIND9's code is very simple; just comment out the fcntl(2)ing lin
e.
h.hanai
--
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: fcntl and /dev/random
I'm looking at this; I'll have something by the end of the weekend for 5-CURRENT; 4-STABLE will take a bit longer. I don't think I'll Wow, great. dop anything for 3-* as it is at its end-of-life. I agree. We can ignore 3-* as long as they don't show any big problem. Cheers, h.hanai To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fcntl and /dev/random
On Sat, 29 Jul 2000, Hiroyuki Hanai wrote:
Setting status flags using F_SETFL command of fcntl(2) on the file
descriptor, which is returned by open(2)ing /dev/random, seems not to
be supported. For example, when I run following code;
[...]
3.4-RELEASE(and possibly 3.5 and 3.5.1) and 4.1-RELEASE/4.1-STABLE say
`Inappropriate ioctl for device' and 5-current says `Operation not
supported by device'.
EOPNOTSUPP is definitely wrong. Try this:
Index: randomdev.c
===
RCS file: /usr2/ncvs/src/sys/dev/randomdev/randomdev.c,v
retrieving revision 1.10
diff -u -u -1 -r1.10 randomdev.c
--- randomdev.c 2000/07/25 21:22:17 1.10
+++ randomdev.c 2000/07/29 08:12:47
@@ -51,2 +51,3 @@
static d_write_t random_write;
+static d_ioctl_t random_ioctl;
@@ -61,3 +62,3 @@
/* write */ random_write,
- /* ioctl */ noioctl,
+ /* ioctl */ random_ioctl,
/* poll */ nopoll,
@@ -133,2 +134,9 @@
return error;
+}
+
+static int
+random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p)
+{
+
+ return (ENOTTY);
}
I've found above in BIND9's source and its `named' program complains
everytime it's invoked.
Should I fix BIND9's code? or wait for fcntl's F_SETFL being
supported on FreeBSD?
Err, this is a minor bug, but should definitely be fixed.
Actually, in BIND9, fd is already open(2)ed with `O_RDONLY | O_NONBLOCK'
and setting O_NONBLOCK status with fcntl(2) is not needed, which means
that fixing BIND9's code is very simple; just comment out the fcntl(2)ing line.
I'd say send that to the maintainer :)
h.hanai
--
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
Panic in xpt_setup_ccb (cam_xpt.c)
Hi,
while trying to read (dd if=/dev/cd0c) from a damaged cd (the surface is
a little bit damaged), I've got a panic:
---snip---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01a0f19 in panic (fmt=0xc029aa60 "lockmgr: pid %d, not %s %d unlocking")
at ../../kern/kern_shutdown.c:553
#2 0xc019b194 in lockmgr (lkp=0xc14f4a00, flags=65542, interlkp=0xd0e2e22c,
p=0xd0313ba0) at ../../kern/kern_lock.c:382
#3 0xc01cf2af in vop_stdunlock (ap=0xd0d2ecc8) at ../../kern/vfs_default.c:255
#4 0xc022b641 in ufs_vnoperate (ap=0xd0d2ecc8)
at ../../ufs/ufs/ufs_vnops.c:2301
#5 0xc01d22aa in vput (vp=0xd0e2e1c0) at vnode_if.h:794
#6 0xc0222ea7 in ffs_sync (mp=0xc1046a00, waitfor=2, cred=0xc0b3f980,
p=0xc037f0a0) at ../../ufs/ffs/ffs_vfsops.c:955
#7 0xc01d4295 in sync (p=0xc037f0a0, uap=0x0) at ../../kern/vfs_syscalls.c:551
#8 0xc01a094f in boot (howto=256) at ../../kern/kern_shutdown.c:225
#9 0xc01a0f19 in panic (fmt=0xc02babef "page fault")
at ../../kern/kern_shutdown.c:553
#10 0xc0265846 in trap_fatal (frame=0xd0d2ee10, eva=68)
at ../../i386/i386/trap.c:929
#11 0xc02654f9 in trap_pfault (frame=0xd0d2ee10, usermode=0, eva=68)
at ../../i386/i386/trap.c:822
#12 0xc02650bf in trap (frame={tf_fs = 16, tf_es = -791543792,
tf_ds = -1072562160, tf_edi = 1, tf_esi = -1056803840,
tf_ebp = -791482800, tf_isp = -791482820, tf_ebx = 0, tf_edx = 64,
tf_ecx = -791482776, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1072541595, tf_cs = 8, tf_eflags = 2163330,
tf_esp = -791482664, tf_ss = -107284}) at ../../i386/i386/trap.c:427
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
---Type return to continue, or q return to quit---
#15 0xc0121b37 in camperiphdone (periph=0xc1021480, done_ccb=0xc1027400)
at ../../cam/cam_periph.c:1021
#16 0xc0127997 in camisr (queue=0xc03189b0) at ../../cam/cam_xpt.c:6328
#17 0xc01277a9 in swi_cambio () at ../../cam/cam_xpt.c:6231
#18 0xc025b900 in splz_swi ()
#19 0xc01a7451 in softclock () at ../../kern/kern_timeout.c:131
#20 0xc025b85f in doreti_swi ()
Cannot access memory at address 0x91992874.
(kgdb) up 13
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
3734ccb_h-path = path;
(kgdb)
(kgdb) print path
$1 = (struct cam_path *) 0x0
(kgdb) print ccb_h
$2 = (struct ccb_hdr *) 0x0
(kgdb) up
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
855 xpt_setup_ccb(crs.ccb_h, path,
(kgdb) print path
$5 = (struct cam_path *) 0x40
(kgdb) print *path
Cannot access memory at address 0x40.
---snip---
It's a kernel from yesterday.
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
World breakage from exit-sys_exit change?
Ok, I give up. It seems that the world change from exit to sys_exit broke the world build, but I can't figure out where. I've fixed every occurence of SYS_exit in the source tree (this one seems to be src/lib/csu/i386/crt0.c, but there were some in gdb as well), and removed /usr/obj - and I still get the following error from buildworld: === bin/cat cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/include -c /usr/src/bin/cat/cat.c gzip -cn /usr/src/bin/cat/cat.1 cat.1.gz cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/include -static -o cat cat.o /usr/obj/usr/src/i386/usr/lib/libc.a(_exit.o): In function `_exit': _exit.o(.text+0x2): undefined reference to `SYS_exit' *** Error code 1 1 error Is this one of those things that is going to require gyrations to get built? Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Mike Meyer wrote: Ok, I give up. It seems that the world change from exit to sys_exit broke the world build, but I can't figure out where. I've fixed every occurence of SYS_exit in the source tree (this one seems to be src/lib/csu/i386/crt0.c, but there were some in gdb as well), and removed /usr/obj - and I still get the following error from buildworld: I think this might be due to the fact that, for some reason, the build is still using the old syscall.h (the one that references SYS_exit rather than SYS_sys_exit -- ie. the installed one rather than the newly generated one). The funny thing here is I would have expected a make -DCLOBBER to take care of that... Regards, PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Argh! I knew today was going to stay a bad day.
I am pretty sure I know how to fix this and will commit a fix shortly. If you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
Mike Meyer wrote:
Ok, I give up. It seems that the world change from exit to sys_exit
broke the world build, but I can't figure out where. I've fixed every
occurence of SYS_exit in the source tree (this one seems to be
src/lib/csu/i386/crt0.c, but there were some in gdb as well), and
removed /usr/obj - and I still get the following error from
buildworld:
=== bin/cat
cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -c /usr/src/bin/cat/cat.c
gzip -cn /usr/src/bin/cat/cat.1 cat.1.gz
cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -static -o cat cat.o
/usr/obj/usr/src/i386/usr/lib/libc.a(_exit.o): In function `_exit':
_exit.o(.text+0x2): undefined reference to `SYS_exit'
*** Error code 1
1 error
Is this one of those things that is going to require gyrations to get
built?
Thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Peter Wemm writes:
Argh! I knew today was going to stay a bad day.
I had similar thoughts about mine, both before I started the build,
and afterwards.
I am pretty sure I know how to fix this and will commit a fix shortly. If you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
That fix indeed seems to work (it managed to build cat), and looks
saner than mine.
Thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Mike Meyer wrote:
Peter Wemm writes:
Argh! I knew today was going to stay a bad day.
I had similar thoughts about mine, both before I started the build,
and afterwards.
I am pretty sure I know how to fix this and will commit a fix shortly. If
you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args
void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args voi
d
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
That fix indeed seems to work (it managed to build cat), and looks
saner than mine.
Anyway, it should be all fixed now (and has been committed for a while).
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fcntl and /dev/random
n Sat, 29 Jul 2000, Hiroyuki Hanai wrote: Setting status flags using F_SETFL command of fcntl(2) on the file descriptor, which is returned by open(2)ing /dev/random, seems not to be supported. For example, when I run following code; File flags should be handled at the file level, and mostly are, but drivers still need dummy FIONBIO and FIOASYNC ioctls to prevent the fo_ioctl()'s in kern_descrip.c:fcntl() from failing (there must be dummy for FIOASYNC for setting O_NONBLOCK to work, even if the device driver doesn't support async i/o :-(). Broken drivers use these ioctls to make copies of the file flags in the wrong place. Non-broken drivers use the flags passed to their i/o functions, so that the flags are per-i/o. 3.4-RELEASE(and possibly 3.5 and 3.5.1) and 4.1-RELEASE/4.1-STABLE say `Inappropriate ioctl for device' and 5-current says `Operation not supported by device'. This is a different bug. The random device in -current doesn't support ioctls at all, so all ioctls on it return ENODEV instead of most ioctls on it returning ENOTTY. See the patch by Brian Feldman. Actually, in BIND9, fd is already open(2)ed with `O_RDONLY | O_NONBLOCK' and setting O_NONBLOCK status with fcntl(2) is not needed, which means that fixing BIND9's code is very simple; just comment out the fcntl(2)ing line. Except the random device doesn't actually support the O_NONBLOCK flag. This makes no difference in the -current random device, since all i/o is non-blocking. In 3.x and 4.x, O_NONBLOCK should have caused reads on /dev/random to not block. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in xpt_setup_ccb (cam_xpt.c)
What hardware?
On Sat, 29 Jul 2000, Alexander Leidinger wrote:
Hi,
while trying to read (dd if=/dev/cd0c) from a damaged cd (the surface is
a little bit damaged), I've got a panic:
---snip---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01a0f19 in panic (fmt=0xc029aa60 "lockmgr: pid %d, not %s %d unlocking")
at ../../kern/kern_shutdown.c:553
#2 0xc019b194 in lockmgr (lkp=0xc14f4a00, flags=65542, interlkp=0xd0e2e22c,
p=0xd0313ba0) at ../../kern/kern_lock.c:382
#3 0xc01cf2af in vop_stdunlock (ap=0xd0d2ecc8) at ../../kern/vfs_default.c:255
#4 0xc022b641 in ufs_vnoperate (ap=0xd0d2ecc8)
at ../../ufs/ufs/ufs_vnops.c:2301
#5 0xc01d22aa in vput (vp=0xd0e2e1c0) at vnode_if.h:794
#6 0xc0222ea7 in ffs_sync (mp=0xc1046a00, waitfor=2, cred=0xc0b3f980,
p=0xc037f0a0) at ../../ufs/ffs/ffs_vfsops.c:955
#7 0xc01d4295 in sync (p=0xc037f0a0, uap=0x0) at ../../kern/vfs_syscalls.c:551
#8 0xc01a094f in boot (howto=256) at ../../kern/kern_shutdown.c:225
#9 0xc01a0f19 in panic (fmt=0xc02babef "page fault")
at ../../kern/kern_shutdown.c:553
#10 0xc0265846 in trap_fatal (frame=0xd0d2ee10, eva=68)
at ../../i386/i386/trap.c:929
#11 0xc02654f9 in trap_pfault (frame=0xd0d2ee10, usermode=0, eva=68)
at ../../i386/i386/trap.c:822
#12 0xc02650bf in trap (frame={tf_fs = 16, tf_es = -791543792,
tf_ds = -1072562160, tf_edi = 1, tf_esi = -1056803840,
tf_ebp = -791482800, tf_isp = -791482820, tf_ebx = 0, tf_edx = 64,
tf_ecx = -791482776, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1072541595, tf_cs = 8, tf_eflags = 2163330,
tf_esp = -791482664, tf_ss = -107284}) at ../../i386/i386/trap.c:427
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
---Type return to continue, or q return to quit---
#15 0xc0121b37 in camperiphdone (periph=0xc1021480, done_ccb=0xc1027400)
at ../../cam/cam_periph.c:1021
#16 0xc0127997 in camisr (queue=0xc03189b0) at ../../cam/cam_xpt.c:6328
#17 0xc01277a9 in swi_cambio () at ../../cam/cam_xpt.c:6231
#18 0xc025b900 in splz_swi ()
#19 0xc01a7451 in softclock () at ../../kern/kern_timeout.c:131
#20 0xc025b85f in doreti_swi ()
Cannot access memory at address 0x91992874.
(kgdb) up 13
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
3734ccb_h-path = path;
(kgdb)
(kgdb) print path
$1 = (struct cam_path *) 0x0
(kgdb) print ccb_h
$2 = (struct ccb_hdr *) 0x0
(kgdb) up
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
855 xpt_setup_ccb(crs.ccb_h, path,
(kgdb) print path
$5 = (struct cam_path *) 0x40
(kgdb) print *path
Cannot access memory at address 0x40.
---snip---
It's a kernel from yesterday.
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
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: Panic in xpt_setup_ccb (cam_xpt.c)
On 29 Jul, Matthew Jacob wrote: What hardware? ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xb000-0xb0ff mem 0xd980-0xd9800fff irq 9 at device 6.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs cd0 at ahc0 bus 0 target 1 lun 0 cd0: TEAC CD-R55S 1.0Q Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd1 at ahc0 bus 0 target 2 lun 0 cd1: PIONEER CD-ROM DR-U16S 1.01 Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) The panic was with cd0. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broadcast address with DHCP
Ben Smithurst wrote: dhclient seems to be broken, it's giving me the all zeroes broadcast address instead of all ones: inet 192.168.91.35 netmask 0xfff0 broadcast 192.168.91.32 (should be broadcast 192.168.91.47) ok, ignore this, it seems to be working after another buildworld. I'm not sure why it broke in the first place. :-( -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse frozen in X when returning from text console
On Wed, Jul 26, 2000 at 11:12:34PM -0400, Alexander N. Kabaev wrote: There was a patch floating around which fixed these mouse problems for me. The patch solves the problem here too. Perhaps it could be added to the other FreeBSD patches in the XFree86-4 port. Benedikt Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sendmail 8.11.0 trouble
Freshly cvsupped current. Sendmail 8.11.0 When invoking sendmail or newaliases I get this message: /etc/pwd.db: Invalid argument Sendmail can't read /etc/pwd.db, and therefore cannot deliver any local mail. Howtofixitplease? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_event.c
I am having problems with "tail -f" hanging the machine. I don't know if this change is related, but I suspect that it might be. I commonly do a "tail -f" of my log file while doing a buildworld. As soon as I interrupted the tail, the machine hung. I then tried to figure out what was causing the problem. Eventually, I tracked the problem down to tail. The machine would respond to pings, but the keyboard was useless. It would not shutdown as well. One test I tried was to run tail -f under truss. This actually kept the machine somewhat usable. Top showed truss using 75% of the CPU and tail using the other 25%. System time was running over 80%. Truss reported that tail kept receiving the signal (indefinitely as far as I could tell) at a high rate of speed. I tried to get a kernel core dump several times by breaking into ddb, but I never had any luck. Here is the backtrace copied by hand: vec1(c0f8d540,1,bfbffa9c,0,c81b76c0) at vec1+0x2 kevent(c81b76c0,c8bd1f80,280f6b40,4,4) at kevent+0x152 syscall2(2f,2f,2f,4,4) at syscall2+0x1f1 Xinit0x80_syscall() at Xint0x80_syscall+0x25 My kernel and source tree both date from 20:00-22:00 EDT on July 28. I found the problem to be quite repeatable by simply going "tail -f file" (the file does not need to change) and then hitting an interrupt on the keyboard. Let me know if I can be of any assistance in tracking this problem down. I might try to spend some time tomorrow figuring out what is happening. Jim Bloom [EMAIL PROTECTED] Jonathan Lemon wrote: jlemon 2000/07/27 16:06:15 PDT Modified files: sys/kern kern_event.c Log: Have kevent() automatically restart if interrupted by a signal. If this is not desired, then the user can register an EV_SIGNAL filter to explicitly catch a signal event. Change requested by: jayanth, ps, peter "Why is kevent non-restartable after a signal?" Revision ChangesPath 1.12 +3 -6 src/sys/kern/kern_event.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:
What I meant with that point is that the user may get, say an extra few
hundred bits out of it with no new entropy before the scheduled reseed
task kicks in.
How does he know which bits are which? His analysis task just got a whole
lot more difficult.
Again, not entirely correct but not relevant either...
Kris is simply right in that the /dev/random semantics change
and that more bits can be output by Yarrow than there is entropy
gathered. *In theory* the complexity of an attack on our Yarrow
has an upper bound of 2^256 and *in theory* this is less than
the complexity of an attack on our current /dev/random. This is
a hard fact, no way around that.
Even if the attack on a single non-blocking read from Yarrow is only
of 2^256 complexity, it is designed to be much more expensive than
just cracking a single block cipher. Blowfish has a very large keying
step, and Yarrow is designed to exploit having large keying steps and
then adding more complexity in its setup in addition. This makes it
infeasible to mount attacks on Yarrow, and the security is really not
as weak as just cracking 20-round Blowfish-256.
However, none of this makes Yarrow useless for getting many bits of
high-quality random data for, e.g., generation of an RSA key.
However, the big question here is not about theory but about
*practicality*. Is Yarrow less secure than /dev/random in
practice? How does our /dev/random hold up under attack? How
does Yarrow compare? I think we need to evaluate these practical
questions instead of deep theoretical issues as Yarrow is all
about practicality.
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*.
Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0
(I guess that's the proper name for this :-) is complex enough and
generates good enough ouput. If you /really/ want to make the attack
on it much harder, how about this: if you're going to read 1024 bits
of entropy from Yarrow on /dev/random, you will request it all at once
and block just as the old random(4) used to block; the blocking can
occur at 256 bit intervals and sleep until there is a reseed. Waiting
to reseed for each read will ensure a much larger amount of "real"
entropy than it "maybe" happening at random times.
Can you really find anything wrong with doing what I propose *in
practice*? I'm certain that it would make it about as hard to
brute-force the key while knowing certain parameters of its generation
as it would be to just factor the damned 1024-bit number. I've
already implemented this as well as some other bugfixes, so see the
attached diff.
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.
Cheers,
Jeroen
[1] And, should we decide not to change /dev/random semantics,
can we still back /dev/random with a modified Yarrow?
I think it makes sense :)
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_ \_ _(_) (_)/_\_| \ _|/' \/
(_)(_) (_)(_) (_)(_)' _\o_
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: sys/sys/random.h
===
RCS file: /usr2/ncvs/src/sys/sys/random.h,v
retrieving revision 1.25
diff -u -r1.25 random.h
--- sys/sys/random.h2000/07/25 21:18:45 1.25
+++ sys/sys/random.h2000/07/29 23:19:20
@@ -36,6 +36,8 @@
enum esource { RANDOM_WRITE, RANDOM_KEYBOARD, RANDOM_MOUSE, RANDOM_NET, \
ENTROPYSOURCE };
void random_harvest(void *, u_int, u_int, u_int, enum esource);
+void set_wakeup(int *, int);
+void set_wakeup_exit(int *, int, int);
#endif
Index: sys/dev/randomdev/harvest.c
===
RCS file: /usr2/ncvs/src/sys/dev/randomdev/harvest.c,v
retrieving revision 1.4
diff -u -r1.4 harvest.c
--- sys/dev/randomdev/harvest.c 2000/07/25 21:18:46 1.4
+++ sys/dev/randomdev/harvest.c 2000/07/29 23:18:50
@@ -30,6 +30,7 @@
#include sys/systm.h
#include sys/types.h
#include sys/queue.h
+#include sys/kthread.h
#include sys/linker.h
#include sys/libkern.h
#include sys/mbuf.h
@@ -72,4 +73,23 @@
nanotime(timebuf);
(*reap)(timebuf, entropy, count, bits, frac, origin);
}
+}
+
+/*
+ * Helper routines to let kthread_exit() do its stuff properly (i.e. no crash).
+ */
+void
+set_wakeup(int *var, int value)
+{
+
+ *var = value;
+
Unable to install FreeBSD Release 4.1 Keyboard is not present
Hi All Has anyone had any difficulty loading release 4.1 ? I have a Tyan Thunder Main board with 128 MB ram When I try and install it bypasses the kernel configuration and takes me straight to the /stand/sysinstall menu. There is also no keyboard support, therefore I am unable to complete an install. I have tried the boot floppies on another machine with a non ps2 keyboard and it worked fine. The machine I am trying to load to can run the boot floppies for release 4.0 without any difficulties. Has anyone else had similar difficulties with ps 2 keyboards on release 4.1 Please reply directly as I am not on the current mailing list Thanks in advance Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Brian Fundakowski Feldman wrote: On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote: What I meant with that point is that the user may get, say an extra few hundred bits out of it with no new entropy before the scheduled reseed task kicks in. How does he know which bits are which? His analysis task just got a whole lot more difficult. Again, not entirely correct but not relevant either... Kris is simply right in that the /dev/random semantics change and that more bits can be output by Yarrow than there is entropy gathered. *In theory* the complexity of an attack on our Yarrow has an upper bound of 2^256 and *in theory* this is less than the complexity of an attack on our current /dev/random. This is a hard fact, no way around that. Even if the attack on a single non-blocking read from Yarrow is only of 2^256 complexity, it is designed to be much more expensive than just cracking a single block cipher. Blowfish has a very large keying step, and Yarrow is designed to exploit having large keying steps and then adding more complexity in its setup in addition. This makes it infeasible to mount attacks on Yarrow, and the security is really not as weak as just cracking 20-round Blowfish-256. Actually, it is. The low key agility doesn't add anything in terms of practical security because it only affects brute force attacks and can be optimized out in a pipelined implementation. Expensive, yes, but can be done. There is some more details on this in the Yarrow paper I think... Anyway, not that is matters, Yarrow was designed to be as secure as the underlying blockcipher and Blowfish is generally considered to be reasonably secure. So, the security still is 2^256 maximum, no way around that. However, none of this makes Yarrow useless for getting many bits of high-quality random data for, e.g., generation of an RSA key. Well, you will need to back that up with arguments if you want to convince the more sceptical (not me). A mere statement will not do it, you need proof or at least arguments :-) The question that Kris posed basically boiled down to: "Does 2^256 complexity equal 2^x (x 256) complexity in practice?" . I can't think of a practical system where it wouldn't be sufficient in practice but that's just me. Well, you seem to agree and MarkM seems to too. Hmm, maybe the complainers should provide proof that they do need more than 2^256 complexity. Makes it easier for us, proponents ;-/ Also, since a 1024 RSA-key only has ~2^77 complexity it isn't a very good example. A more interesting question is, what if you generate a couple of 256-bit symmetric keys in a row. Their total complexity is 2^256 which is less than they could have. Does that matter in practice? Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0 (I guess that's the proper name for this :-) According to Bruce S. one would call it Yarrow-256 (implementation details go here) You would definately spell out Blowfish completely. Btw, how exactly is the hash actually constructed in our Yarrow? I wonder how one constructs a 256-bit hash out of Blowfish with a 64-bit block size. A quick explanation would be appreciated. is complex enough and generates good enough ouput. If you /really/ want to make the attack on it much harder, how about this: if you're going to read 1024 bits of entropy from Yarrow on /dev/random, you will request it all at once and block just as the old random(4) used to block; the blocking can occur at 256 bit intervals and sleep until there is a reseed. Waiting to reseed for each read will ensure a much larger amount of "real" entropy than it "maybe" happening at random times. Sounds like a good idea. It looks like it would be reasonably easy to then add an extra entropy counter to the pool from which you subtract the number of bits that are output and to which you add the number of entropy bits that are mixed in. You can then extract bytes until that counter hits 0 and then block until it goes positive again which would ensure that the entropy output trough /dev/random is not re-used for output trough /dev/urandom. This would not affect the security of Yarrow at all but preserve the semantics of /dev/random almost completely. Can you really find anything wrong with doing what I propose *in practice*? No. Although I think you can make it nearly perfect by incorporating the above suggestion. You would then *never* return more bits than you have gathered entropy and you would never use those entropy bits twice. I've already implemented this as well as some other bugfixes, so see the attached diff. Cool. [1] And, should we decide not to change /dev/random semantics, can we still back /dev/random with a modified Yarrow? I think it makes sense :) Me too, especially with your changes (or modification thereof) to preserve current /dev/random semantics. Cheers, Jeroen -- Jeroen C. van Gelderen
Re: sendmail 8.11.0 trouble
On Sunday, July 30, 2000, Leif Neland wrote: Freshly cvsupped current. Sendmail 8.11.0 When invoking sendmail or newaliases I get this message: /etc/pwd.db: Invalid argument Sendmail can't read /etc/pwd.db, and therefore cannot deliver any local mail. Howtofixitplease? If you mean when running it as non-root, then you should have g+r on /etc/pwd.db, since it carries the same information as /etc/passwd anyway. -- |Chris Costello [EMAIL PROTECTED] |Computer and car salesmen differ in that the latter know |when they are lying. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
