Re: Digitally Signed Binaries w/ Kernel support, etc.
On Thu, Apr 10, 2008 at 04:39:56PM +0200, Kris Kennaway wrote: [..] > > csjp@ had a mac_chkexec module that looks like it was never committed. > > http://groups.google.com/group/mailing.freebsd.hackers/msg/074eec7def84c52b > > Shouldn't be hard to update it. > Just a few notes: - This isn't really "binary signing" per se, I associate a cryptographic checksum with a shared object, executable, shell script etc... Then if you try to mmap the shared object into the address space, or execute the executable object (after it was back-doored with malicious code), it will deny it (assuming the system is in "enforce" and not in "learning" mode). Also, new binaries (ones without checksums associated with them) would not be permitted to execute. True binary signing basically requires that the signature is part of the executable format. for example: embedding a certificate in the ELF structure. This would allow us to distribute binaries across systems. In my model, we are using extended attributes, which offers security for the local system only (but still useful if the intent is to allow certain users to upload new binaries, and protect against exploits or backdoored binaries). - Mathew Dodd and I started working on a "bignum" library for the kernel so we could perform the arbitrary precision arithmetic required for various PKC operations to implement proper "signing", and for the most part it worked, but I think there were some edge cases where there are problems. (Since there is some interest here, I could be convinced to pickup the project again). - I have not committed this because I do not want to import the userspace utilities required to manage the checksums. In retrospect, I should have stored the checksums in the MAC label. I intend to correct this, and it's likely I could add it to base once this is done. The code listed in the link above is not likely to compile due to some MAC entry point renaming that was completed. However I should be able to fix this pretty quickly and send a follow up email here for anyone who is interested in experimenting. http://people.freebsd.org/~csjp/mac/trustedexec.png Describes it's operation at a high level. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: df -kP != df -Pk
FYI, I have taken care of this in -CURRENT Thanks for the report! csjp2006-09-20 20:55:02 UTC FreeBSD src repository Modified files: bin/df df.c Log: Based on The Open Group Base Specifications Issue 6 IEEE Std 1003.1, our current implementation of df(1) is does not properly format the output under certain conditions. Right now -kP and -Pk are not the same thing. Further, when we set the BLOCKSIZE environment variable, we use "1k" instead of "1024", making the header display incorrectly. To quote the specification: "When both the -k and -P options are specified, the following header line shall be written (in the POSIX locale): "Filesystem 1024-blocks Used Available Capacity Mounted on\n" - If -P has been specified, check to make sure that -k has not already been specified, if so, simply break instead of clobbering the previous blocksize - Use 1024 instead of 1k to make the header POSIX compliant Reported by:Andriy Gapon Discussed with: bde, ru MFC after: 1 week Revision ChangesPath 1.66 +11 -2 src/bin/df/df.c Andriy Gapon wrote: on 19/09/2006 19:17 Christian S.J. Peron said the following: Andriy Gapon wrote: It seems that -P flag to df resets previously specified -k for no good reason. POSIX expressly talks about -P and -k being used together. http://www.opengroup.org/onlinepubs/009695399/utilities/df.html This is FreeBSD 6.1-RELEASE-p2 i386. Please test the attached patch and let me know if it's good for you. Thanks for bringing this to our attention. Yes, the patch works very well. Thank you for the lightning-fast response. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer FreeBSD Security Team ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6: I/O deadlock under load
It almost looks as if a user frequently runs gmirror(8) to query the status of their array. Under a high load situation, the worker is busy, so at one un-lucky momment, gmirror(8) is run: (1) gmirror(8) waits for sc->sc_lock owned by the worker (2) The worker then drops the lock (3) gmirror(8) proceeds (4) Worker wakes up and waits for sc->sc_lock (5) Only gmirror never will because it's waiting on a resource (presumably owned by the worker thread)? I am not certain this is correct, so I have included pjd in the CC loop, hoping he can help shed some light on the subject :) Ulrich Spoerlein wrote: Ulrich Spoerlein wrote: Our fileserver deadlocked, again. It is running RELENG_6 checked out yesterday. I have enabled DDB, WITNESS and INVARIANTS and have it hooked up via serial console. Happend again, now I have DEBUG_LOCKS and DEBUG_VFS_LOCK included. There are hundreds of cron processes waiting on wmesg 'sysctl' (they seem to have piled up prior to me entering the debugger). db> show pcpu cpuid= 0 curthread= 0xc8326780: pid 11 "idle: cpu0" curpcb = 0xe6f1fd90 fpcurthread = none idlethread = 0xc8326780: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 0 cpuid= 0 curthread= 0xc8326780: pid 11 "idle: cpu0" curpcb = 0xe6f1fd90 fpcurthread = none idlethread = 0xc8326780: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid= 1 curthread= 0xc8326600: pid 10 "idle: cpu1" curpcb = 0xe6f1cd90 fpcurthread = none idlethread = 0xc8326600: pid 10 "idle: cpu1" APIC ID = 6 currentldt = 0x50 spin locks held: db> show alllocks Process 60935 (gmirror) thread 0xc88ce780 (100122) exclusive sx sysctl lock r = 0 (0xc0971dc0) locked @ /usr/src/sys/kern/kern_sysctl.c:1375 Process 50 (g_mirror gm0) thread 0xc86b7600 (100062) exclusive sx gmirror:lock r = 0 (0xc84b282c) locked @ /usr/src/sys/geom/mirror/g_mirror.c:1809 'gm0' is the mirror where the OS resides on. It is 8GB in size and spans across da0s1 and da1s1 which are RAID5 volumes attached through two twa(4) controllers. db> show lockedvnods Locked vnodes 0xcb4a4984: tag ufs, type VREG usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xcc804e70 ref 0 pages 1 lock type ufs: SHARED (count 1)#0 0xc0667314 at lockmgr+0x160 #1 0xc0783fea at ffs_lock+0x76 #2 0xc083688f at VOP_LOCK_APV+0x87 #3 0xc06d50b8 at vn_lock+0xac #4 0xc06d478e at vn_read+0x132 #5 0xc0697a89 at dofileread+0x85 #6 0xc0697922 at kern_readv+0x36 #7 0xc069784d at read+0x45 #8 0xc0824037 at syscall+0x25b #9 0xc08106af at Xint0x80_syscall+0x1f ino 8315, on dev ufs/root 0xc87682b8: tag ufs, type VDIR usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcb4b6630 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc850b000 (pid 43987)#0 0xc06676a1 at lockmgr+0x4ed #1 0xc0783fea at ffs_lock+0x76 #2 0xc083688f at VOP_LOCK_APV+0x87 #3 0xc06d50b8 at vn_lock+0xac #4 0xc06c8f46 at vget+0xc2 #5 0xc06bd9be at cache_lookup+0x34a #6 0xc06bdef2 at vfs_cache_lookup+0x92 #7 0xc083494f at VOP_LOOKUP_APV+0x87 #8 0xc06c20a2 at lookup+0x46e #9 0xc06c19b6 at namei+0x39a #10 0xc06d3e9f at vn_open_cred+0x5b #11 0xc06d3e42 at vn_open+0x1e #12 0xc06cd342 at kern_open+0xb6 #13 0xc06cd256 at open+0x1a #14 0xc0824037 at syscall+0x25b #15 0xc08106af at Xint0x80_syscall+0x1f ino 94210, on dev ufs/var 0xc87746cc: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xc876a210 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xc86b7000 (pid 14753)#0 0xc06676a1 at lockmgr+0x4ed #1 0xc0783fea at ffs_lock+0x76 #2 0xc083688f at VOP_LOCK_APV+0x87 #3 0xc06d50b8 at vn_lock+0xac #4 0xc06d4a54 at vn_write+0x138 #5 0xc0697d5f at dofilewrite+0x77 #6 0xc0697c03 at kern_writev+0x3b #7 0xc0697bac at writev+0x30 #8 0xc0824037 at syscall+0x25b #9 0xc08106af at Xint0x80_syscall+0x1f ino 94280, on dev ufs/var 0xca357414: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc8cdf480 (pid 20101)#0 0xc06676a1 at lockmgr+0x4ed #1 0xc0783fea at ffs_lock+0x76 #2 0xc083688f at VOP_LOCK_APV+0x87 #3 0xc06d50b8 at vn_lock+0xac #4 0xc06c8f46 at vget+0xc2 #5 0xc06bd9be at cache_lookup+0x34a #6 0xc06bdef2 at vfs_cache_lookup+0x92 #7 0xc083494f at VOP_LOOKUP_APV+0x87 #8 0xc06c20a2 at lookup+0x46e #9 0xc06c19b6 at namei+0x39a #10 0xc06cf3f1 at kern_stat+0x35 #11 0xc06cf39f at stat+0x1b #12 0xc0824037 at syscall+0x25b #13 0xc08106af at Xint0x80_syscall+0x1f ino 94211, on dev ufs/var 0xc875c15c: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xc84ce480 (pid 46)#0 0xc06676a1 at lockmgr+0x4ed #1 0xc06c00e1 at vop_stdlock+0x21 #2 0xc083688f at VOP_
Re: RELENG_6: I/O deadlock under load
Sorry, I forgot to include the chunk of code from the gmirror worker
thread which made me suspect this could be the problem:
[..]
/* Get first request from the queue. */
mtx_lock(&sc->sc_queue_mtx);
bp = bioq_first(&sc->sc_queue);
if (bp == NULL) {
if ((sc->sc_flags &
G_MIRROR_DEVICE_FLAG_DESTROY) != 0) {
mtx_unlock(&sc->sc_queue_mtx);
if (g_mirror_try_destroy(sc)) {
curthread->td_pflags &= ~TDP_GEOM;
G_MIRROR_DEBUG(1, "Thread
exiting.");
kthread_exit(0);
}
mtx_lock(&sc->sc_queue_mtx);
}
sx_xunlock(&sc->sc_lock);
/*
* XXX: We can miss an event here, because an event
* can be added without sx-device-lock and
without
* mtx-queue-lock. Maybe I should just stop
using
* dedicated mutex for events
synchronization and
* stick with the queue lock?
* The event will hang here until next I/O
request
* or next event is received.
*/
MSLEEP(sc, &sc->sc_queue_mtx, PRIBIO | PDROP,
"m:w1",
timeout * hz);
sx_xlock(&sc->sc_lock);
G_MIRROR_DEBUG(5, "%s: I'm here 4.", __func__);
continue;
}
bioq_remove(&sc->sc_queue, bp);
mtx_unlock(&sc->sc_queue_mtx);
Christian S.J. Peron wrote:
It almost looks as if a user frequently runs gmirror(8) to query the
status of their array. Under a high load situation, the worker is
busy, so at one un-lucky momment, gmirror(8) is run:
(1) gmirror(8) waits for sc->sc_lock owned by the worker
(2) The worker then drops the lock
(3) gmirror(8) proceeds
(4) Worker wakes up and waits for sc->sc_lock
(5) Only gmirror never will because it's waiting on a resource
(presumably owned by the worker thread)?
I am not certain this is correct, so I have included pjd in the CC
loop, hoping he can help shed some light on the subject :)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: df -kP != df -Pk
Andriy Gapon wrote:
It seems that -P flag to df resets previously specified -k for no good
reason. POSIX expressly talks about -P and -k being used together.
http://www.opengroup.org/onlinepubs/009695399/utilities/df.html
This is FreeBSD 6.1-RELEASE-p2 i386.
Please test the attached patch and let me know if it's good for you.
Thanks for bringing this to our attention.
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
FreeBSD Security Team
? df
? df.1.gz
? df.c.diff
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.64
diff -u -r1.64 df.c
--- df.c10 Jan 2005 08:39:21 - 1.64
+++ df.c19 Sep 2006 16:14:37 -
@@ -93,7 +93,7 @@
return (a > b ? a : b);
}
-static int aflag = 0, cflag, hflag, iflag, nflag;
+static int aflag = 0, cflag, hflag, kflag, iflag, nflag, Pflag;
static struct ufs_args mdev;
int
@@ -123,6 +123,7 @@
case 'b':
/* FALLTHROUGH */
case 'P':
+ Pflag++;
putenv("BLOCKSIZE=512");
hflag = 0;
break;
@@ -143,6 +144,7 @@
iflag = 1;
break;
case 'k':
+ kflag++;
putenv("BLOCKSIZE=1k");
hflag = 0;
break;
@@ -171,6 +173,12 @@
argc -= optind;
argv += optind;
+ /*
+* POSIX specifies that if both -P and -k options are used together a
+* 1k blocksize should be used.
+*/
+ if (Pflag != 0 && kflag != 0)
+ putenv("BLOCKSIZE=1k");
mntsize = getmntinfo(&mntbuf, MNT_NOWAIT);
bzero(&maxwidths, sizeof(maxwidths));
for (i = 0; i < mntsize; i++)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
bug1: session_input_channel_req: session 0 req shell > === and here === > > 9. On T the session is stuck: > === cut here === > $ ssh 192.168.168.254 -l test2 > Password: > Environment: > USER=test2 > LOGNAME=test2 > HOME=/home/test2 > > MAIL=/var/mail/test2 > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/test2/bin >TERM=su > FTP_PASSIVE_MODE=YES > BLOCKSIZE=K > > SHELL=/usr/local/bin/rbash >SSH_CLIENT=192.168.168.253 39090 22 > SSH_CONNECTION=192.168.168.253 > 39090 192.168.168.254 22 > === and here === > > 10. On J the content of /dev/pts and /dev/pty is unchanged: > === cut here === > J# ls -la /dev/pts > total 1 > dr-xr-xr-x 2 root wheel 512 Nov 7 16:38 . > dr-xr-xr-x 6 root wheel 512 Nov 7 16:38 .. > crw-rw-rw- 1 root wheel0, 97 Nov 7 17:22 0 > crw-rw-rw- 1 root wheel0, 106 Nov 7 16:56 2 > crw-rw-rw- 1 root wheel0, 110 Nov 7 17:16 5 > J# ls -la /dev/pty > total 1 > dr-xr-xr-x 2 root wheel 512 Nov 7 16:38 . > dr-xr-xr-x 6 root wheel 512 Nov 7 16:38 .. > crw-rw-rw- 1 root wheel0, 95 Nov 7 17:22 0 > crw-rw-rw- 1 root wheel0, 104 Nov 7 15:36 1 > crw-rw-rw- 1 root wheel0, 105 Nov 7 16:56 2 > crw-rw-rw- 1 root wheel0, 107 Nov 7 15:36 3 > crw-rw-rw- 1 root wheel0, 108 Nov 7 15:36 4 > crw-rw-rw- 1 root wheel0, 109 Nov 7 17:16 5 > === and here === > > regards, > Gepu > > On Wed, Nov 07, 2007 at 10:42:58AM +, Tom Evans wrote: > > On Tue, 2007-11-06 at 22:19 +0200, Dan Epure wrote: > > > Hi All, > > > > > > > > > I'm using on the host system (7.0-BETA2): > > > #sysctl kern.pts.enable > > > kern.pts.enable: 1 > > > I have no problem at all. > > > > > > The jail is also 7.0-BETA2 > > > > > > The problem is inside the jail openpty() can not allocate the pty: > > > === cut here === > > > debug1: monitor_child_preauth: test2 has been authenticated by privileged > > > process > > > debug1: PAM: reinitializing credentials > > > debug1: Entering interactive session for SSH2. > > > debug1: server_init_dispatch_20 > > > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max > > > 16384 > > > debug1: input_session_request > > > debug1: channel 0: new [server-session] > > > debug1: session_new: init > > > debug1: session_new: session 0 > > > debug1: session_open: channel 0 > > > debug1: session_open: session 0: link with channel 0 > > > debug1: server_input_channel_open: confirm session > > > debug1: server_input_channel_req: channel 0 request pty-req reply 0 > > > debug1: session_by_channel: session 0 channel 0 > > > debug1: session_input_channel_req: session 0 req pty-req > > > debug1: Allocating pty. > > > debug1: session_new: init > > > debug1: session_new: session 0 > > > openpty: No such file or directory > > > session_pty_req: session 0 alloc failed > > > debug1: server_input_channel_req: channel 0 request shell reply 0 > > > debug1: session_by_channel: session 0 channel 0 > > > debug1: session_input_channel_req: session 0 req shell > > > === and here === > > > the ssh session just hangs. (no pty ?) > > > > > > I did not forget to mount devfs inside the jail. > > > The jail is configured in rc.conf: > > > === cut here === > > > jail_enable="YES" > > > jail_list="test" > > > jail_test_hostname="test.mydomain.org" > > > jail_test_rootdir="/jails/test" > > > jail_test_interface="bge0" > > > jail_test_devfs_enable="YES" > > > jail_test_ip="192.168.10.2" > > > jail_set_hostname_allow="NO" > > > jail_sysvipc_allow="NO" > > > jail_socket_unixiproute_only="YES" > > > === and here === > > > I think the problem is related to restrictions imposed by the jail. > > > > > > Please advise. > > > > > > Gepu > > > > This is because you haven't been allocated a pty inside your jail. >
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: > I just used the patch and it is working. > Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: > On 11/11/07, Christian S.J. Peron <[EMAIL PROTECTED]> wrote: > > On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: > > > I just used the patch and it is working. > > > > > > > Good to hear. I have submitted the request to get this merged to > > RELENG_7. Thanks for the quick response. > >Unfortunately, this doesn't fix the problems with screen :( > Which? I can look into it. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] > >This one: > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html >Thanks! > Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too short ethernet frame...
Yes,
This appears to be a mistake on my part, please commit this patch.
Thanks for catching this!
On Thu, Aug 18, 2005 at 09:59:50AM +0100, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Iva Hesy writes:
> >OK, now, I get the result:
> >"tag=RELENG_6 date=2005.07.30.22.00.00" works fine, "tag=RELENG_6
> >date=2005.07.31.03.00.00" makes noise, many many ethernet frames can
> >be sniffered.
> >the cvsup log:
> >Updating collection src-all/cvs
> > Edit src/sys/dev/mlx/mlx_pci.c
> > Add delta 1.23.2.1 2005.07.31.00.41.53 csjp
> > Edit src/sys/net/bpf.c
> > Add delta 1.153.2.1 2005.07.31.00.48.18 csjp
> > Edit src/sys/net/bpfdesc.h
> > Add delta 1.29.2.1 2005.07.31.00.48.18 csjp
> >Shutting down connection to server
> >Finished successfully
> >I guess it should be bpf.c...
>
> There appear to be some braces missed in that revision of bpf.c. Does
> the following patch help?
>
> Ian
>
> Index: sys/net/bpf.c
> ===
> RCS file: /dump/FreeBSD-CVS/src/sys/net/bpf.c,v
> retrieving revision 1.153.2.2
> diff -u -r1.153.2.2 bpf.c
> --- sys/net/bpf.c 13 Aug 2005 21:24:16 - 1.153.2.2
> +++ sys/net/bpf.c 18 Aug 2005 08:55:49 -
> @@ -1256,13 +1256,14 @@
> BPFD_LOCK(d);
> ++d->bd_rcount;
> slen = bpf_filter(d->bd_filter, (u_char *)m, pktlen, 0);
> - if (slen != 0)
> + if (slen != 0) {
> d->bd_fcount++;
> #ifdef MAC
> if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0)
> #endif
> catchpacket(d, (u_char *)m, pktlen, slen,
> bpf_mcopy);
> + }
> BPFD_UNLOCK(d);
> }
> BPFIF_UNLOCK(bp);
> @@ -1308,13 +1309,14 @@
> BPFD_LOCK(d);
> ++d->bd_rcount;
> slen = bpf_filter(d->bd_filter, (u_char *)&mb, pktlen, 0);
> - if (slen != 0)
> + if (slen != 0) {
> d->bd_fcount++;
> #ifdef MAC
> if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0)
> #endif
> catchpacket(d, (u_char *)&mb, pktlen, slen,
> bpf_mcopy);
> + }
> BPFD_UNLOCK(d);
> }
> BPFIF_UNLOCK(bp);
>
>
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too short ethernet frame...
Or if you want, I will commit it.
On Thu, Aug 18, 2005 at 09:59:50AM +0100, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Iva Hesy writes:
> >OK, now, I get the result:
> >"tag=RELENG_6 date=2005.07.30.22.00.00" works fine, "tag=RELENG_6
> >date=2005.07.31.03.00.00" makes noise, many many ethernet frames can
> >be sniffered.
> >the cvsup log:
> >Updating collection src-all/cvs
> > Edit src/sys/dev/mlx/mlx_pci.c
> > Add delta 1.23.2.1 2005.07.31.00.41.53 csjp
> > Edit src/sys/net/bpf.c
> > Add delta 1.153.2.1 2005.07.31.00.48.18 csjp
> > Edit src/sys/net/bpfdesc.h
> > Add delta 1.29.2.1 2005.07.31.00.48.18 csjp
> >Shutting down connection to server
> >Finished successfully
> >I guess it should be bpf.c...
>
> There appear to be some braces missed in that revision of bpf.c. Does
> the following patch help?
>
> Ian
>
> Index: sys/net/bpf.c
> ===
> RCS file: /dump/FreeBSD-CVS/src/sys/net/bpf.c,v
> retrieving revision 1.153.2.2
> diff -u -r1.153.2.2 bpf.c
> --- sys/net/bpf.c 13 Aug 2005 21:24:16 - 1.153.2.2
> +++ sys/net/bpf.c 18 Aug 2005 08:55:49 -
> @@ -1256,13 +1256,14 @@
> BPFD_LOCK(d);
> ++d->bd_rcount;
> slen = bpf_filter(d->bd_filter, (u_char *)m, pktlen, 0);
> - if (slen != 0)
> + if (slen != 0) {
> d->bd_fcount++;
> #ifdef MAC
> if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0)
> #endif
> catchpacket(d, (u_char *)m, pktlen, slen,
> bpf_mcopy);
> + }
> BPFD_UNLOCK(d);
> }
> BPFIF_UNLOCK(bp);
> @@ -1308,13 +1309,14 @@
> BPFD_LOCK(d);
> ++d->bd_rcount;
> slen = bpf_filter(d->bd_filter, (u_char *)&mb, pktlen, 0);
> - if (slen != 0)
> + if (slen != 0) {
> d->bd_fcount++;
> #ifdef MAC
> if (mac_check_bpfdesc_receive(d, bp->bif_ifp) == 0)
> #endif
> catchpacket(d, (u_char *)&mb, pktlen, slen,
> bpf_mcopy);
> + }
> BPFD_UNLOCK(d);
> }
> BPFIF_UNLOCK(bp);
>
>
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
