Re: File trees: the deeper, the weirder
[ Restoring some OP context.] On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote: As for the said program, it keeps its 1 Hz pace, mostly waiting on vlruwk. It's killable, after a delay. The system doesn't show ... Weird, eh? Any ideas what's going on? I would guess that you need a new vnode to create the new file, but no vnodes are obvious candidates for freeing because they all have a child directory in use. Is there some sort of vnode clearing that goes on every second if we are short of vnodes? See sys/vfs_subr.c, subroutine getnewvnode(). We call msleep() if we're waiting on vnodes to be created (or recycled). And just look at the 'hz' parameter passed to msleep()! The calling process's mkdir() will end up waiting in getnewvnode() (in vlruwk state) while the vnlru kernel thread does it's thing (which is to recycle vnodes.) Either the vnlru kernel thread has to work faster, or the caller has to sleep less, in order to avoid this lock-step behaviour. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
- Original Message - From: Steve Kargl [EMAIL PROTECTED] To: Randall Hyde [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Sent: Wednesday, June 28, 2006 10:10 PM Subject: Re: Return value of malloc(0) On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote: Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. A new thread with a proper subject would be appropriate too :) -- Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Config(8) dependency checking - first patches
: Notes and patches against 7-CURRENT are at : http://www.gsicomp.on.ca/projects/freebsd/configdep.html. How would you encode ed's dependencies? The ed driver only depends on mii when built with pccard enabled. I suspected that conditional dependencies would be neccessary, but didn't have any examples. Now I do. Thanks! -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Config(8) dependency checking - first patches
Folks, I've written up some patches to add dependency checking to config(8). This will help prevent link errors when compiling kernels with an incomplete kernel config (things like fxp without miibus; umass without da/scbus, etc.) The current set of patches add support to config(8) to read, parse and use dependency information; however, no dependency meta-data has been generated yet. Notes and patches against 7-CURRENT are at http://www.gsicomp.on.ca/projects/freebsd/configdep.html. Comments and suggestions appreciated. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Named requests filling up T1
Ugh...it's always something The T1 here is getting blasted by named requests, any suggestions would be appreciated... I turned on debugging and got the following, lots of them...so many that we're getting 30-50% packet loss across the T1: 16-Jan-2006 18:01:35.795 client @0x87d4800: udprecv 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: UDP request 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: using view '_default' 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: request is not signed 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: recursion available 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: query 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: query (cache) 'v.tn.co.za/ANY/IN' approved 16-Jan-2006 18:01:35.795 client 64.18.133.103#5550: send 16-Jan-2006 18:01:35.796 client 64.18.133.103#5550: sendto 16-Jan-2006 18:01:35.796 client 64.18.133.103#5550: senddone 16-Jan-2006 18:01:35.796 client 64.18.133.103#5550: next 16-Jan-2006 18:01:35.796 client 64.18.133.103#5550: endrequest Any suggestion on what it might be and how I might stop it? Looks like someone is spamming your DNS server with queries. Two questions: 1) Is v.tn.co.za a domain that you are authorative for? 2) Are you an ISP and/or is client 64.18.133.103 authorized to use your DNS server? If the answer to 1) is NO, then there's no reason for these queries to be directed to your DNS server from the Internet. If the answer to 2) is NO, then there's no reason for these queries to be directed to your DNS server from the Internet. Source IP filtering is likely your best option, although it doesn't help with your T1 saturation, although it would give whoever is blasting these queries a clue. -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using pkg_add fetch only
Good evening, I'm writing on the ezjail project and want to be able to use the easy interface of pkg_add to fetch packages recursively. This is _fetch_, not install them, since installation is expected to happen at a later stage when starting up lots of jails each being identical. Clearly pkg_add does not provide this option. Even if it would, it would declare some dependencies fulfilled since packages are installed in the hostsystem already. Anyone having an idea here, besides rewriting pkg_add? What about pkg_fetch -R? -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Compiling kernel/modules without INET?
Howdy, One of my new years resolutions was to become a bit more masochistic, so I set out to see if I could build a kernel (and modules) without options INET on HEAD. This works flawlessly for the kernel part, but there are tons of issues when building modules -- various problems encountered during make depend and make. So far there appear to be four different classes of errors: 1) Failures during make depend due to #error directives hit when INET is not defined. 2) #includes which are always needed but are only pulled in (implicitly) when INET is defined 3) Small blocks of code (variable declarations and tests) which are not wrapped with #ifdef INET (or other #defines), or simply wrapped with the wrong #ifdef 4) Larger messes such as GRE's hard-coded dependence on INET; SLIP/PPP's dependence on packet compress code, etc. I have what I think are valid fixes for the first 3 issues, but I know I'm just making a mess of things to resolve the last issue. Before I spit and polish these patches for public consumption, I want to know if this is even a worthy project. I know there are benefits simply because we should do the right thing, but I'm sure I'm wading into murky waters. Any guidance would be appreciated. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote:
Did you read my post?
Or are you not on the list? I sent my response directly to the list,
not including you specifically.
[...]
I am on the list,and I don't receive your post.
I think you can send post specifically to me and cc
to the list :-).
Thanks.
In the future, please respond to personal mails personally. Neither my
direct e-mail address nor this mail were intended for public viewing.
The post to which i was referring is:
http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014986.html
The problem is that libnet defines ether_addr without regard for the fact
that it's defined in our system headers. This is a bug in libnet, not
FreeBSD.
In particular, libnet/libnet-headers.h has this code, which is very
Linux-centric and works around the duplicate definition problem on Linux,
but doesn't help anyone on other platforms.
391 #if (!__GLIBC__)
392 struct ether_addr
393 {
394 u_char ether_addr_octet[6];
395 };
396 #endif
The problem has been properly fixed in the current development version of
libnet (net/libnet-devel), by renaming the ether_addr structure to
libnet_ether_addr.
The net/libnet port should be marked BROKEN because of this issue (I've
opened a PR) and folks should use libnet-devel instead, until the net/libnet
port is updated to a newer version. The net/libnet maintainer has been
notified of this problem.
Regards,
--
Matt Emmerton
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RFC: porting NetBSD fsdb enhancements to FreeBSD
Recently I've had to do some low-level surgery on some disks that have gone bad in order to recover some of the data. This has required me to zero out blocks on disk, patch up the affected files, and pull the data off the disks. I was toying around the with fsdb tool, but couldn't figure out a way to map blocks to inodes (although the 'blocks' command does the mapping in the other direction quite nicely.) Poking around I found that someone has added this functionality (via a findblk command) to NetBSD's fsdb (back in 2003!), which I have grafted onto a 4.x box here with relative ease. NetBSD Mailing List Posting: http://groups.google.com/group/mailing.netbsd.tech.userlevel/browse_thread/thread/18acceb04cf5aadb/2a891d67edf9279%232a891d67edf9279?sa=Xoi=groupsrstart=0num=3) NetBSD CVS: http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/fsdb/fsdb.c.diff?r1=1.24r2=1.25f=h Is this something that folks would like to see on FreeBSD? I've got RELENG_5_4 and RELENG_6_0 boxes here in my office so I can whip up the patches and do some testing in short order. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat reporting incorrect cpu usage
- Original Message - From: Neo-Vortex [EMAIL PROTECTED] To: freebsd-hackers@freebsd.org Sent: Saturday, June 04, 2005 10:01 AM Subject: vmstat reporting incorrect cpu usage I've noticed if i run vmstat with no params when rebuilding the kernel i get this right: # vmstat procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 2 1 0 294156 44596 313 0 0 0 296 1 0 82 85 225 14 8 78 # But, if i run it like this # vmstat -c 2 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 299580 38204 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 294996 42876 886 0 0 0 2061 0 3 1364 2231 81 19 0 # The second result shows what top does, but the first one seems to be completely wrong... # vmstat -c 6 procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 1 1 0 300136 36196 313 0 0 0 296 1 0 82 85 225 14 8 78 1 1 0 301040 35312 230 0 0 0 9 0 0 2193 489 2156 87 13 0 1 1 0 296720 39644 1234 0 0 0 2326 0 5 2190 1530 2185 70 30 0 1 1 0 297092 39228 1435 0 0 0 1336 0 3 2200 1562 2188 75 25 0 1 1 0 298488 37844 1573 0 0 0 1229 0 4 2206 1592 2191 69 31 0 1 1 0 299372 36908 316 0 0 0 123 0 96 2301 618 2442 86 14 0 # Only the first one seems to do it though... FreeBSD 5.3-RELEASE. Does this happen for anyone else? (Mabe someone running 5.4 can test this?) The first line is the average since the system was last booted; all other lines are instantaneous. -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp driver not 64 bit?
- Original Message - From: Dan Nelson [EMAIL PROTECTED] To: David Gilbert [EMAIL PROTECTED] Cc: Matt Emmerton [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 12:56 AM Subject: Re: isp driver not 64 bit? In the last episode (Nov 29), David Gilbert said: Well... cam_calc_geometry seems to get called quite a bit. Almost everytime you touch the disk, in fact. fsck'ing a partition calls it, for instance. Does this not seem excessive to anyone? Call me naive, but shouldn't the only time we need to obtain the geometry is at initial probe time? Console access is personally expensive (much driving, for instance), but from memory the debugging I put in cam_calc_geometry() would print before the correct output from dadone(). Your description reminds me of this --- but it's no less vexing that the output from dadone() has the correct sector and volume size and the ccg in cam_calc_geometry() has bogus data. I don't know if it's significant, but the correct numbers were: 279353684 sectors of 512 bytes The ccg structure comes up with: 3737169375 sectors of 3737169374 bytes Not entirely sensible. Interesting that they're close values. However, with different things on the stack, the values changed. Even more interesting is their hex values: DEC0ADDF and DEC0ADDE, aka 0xDEADC0DE. Something's reading memory after the kernel freed it. Which makes me wonder if one of our 'extra' cam_calc_geometry() calls is being executed from a place where it shouldn't be. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp driver not 64 bit?
Dave, After a bunch of frustrating debugging, I've tenatively come to the conclusion that the isp(4) driver is not 64 bit safe --- at the very least insofar as the amd64 platform is concerned. The test setup was a quad opteron 248 system connected via two isp 2340 cards to switches which interconnect to an EMC^2 disk array. I've made a couple of interim posts on this subject. The message from scsi_da.c indicates the correct probe is received from the disk. In the test, it was a 131 gig disk of 512 byte sectors. However, by the time we get to cam_calc_geometry() in cam.c, the structure is corrupt --- containing bad values for both volume_size and sector_size. Here's what I found by walking through the code. Mind you, given that I'm no expert on this code either, I may be missing things. 1) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 probes the device for capacity information. 2) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then calls dasetgeom(). The parameters to dasetgeom() are obtained from 1), are updated in softc-params and later the ccg. All variables involved in these assignments have matching types, so there should be no truncation. 3) dasetgeom() then calls xpt_action() [ which I'm assuming is redirected to dev/isp/isp_freebsd.c::isp_action() ] with a function id of XPT_CALC_GEOMETRY, which ultimately calls cam_calc_geometry(). 4) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then prints out a probe of the device size. You indicate that this probe is done properly. From what I see, cam_calc_geometry() is called *before* the device probe prints out the device size, so I'm unsure of how what you are describing can occur. Have you built run a kernel compiled with options CAMDEBUG ? This may provide more insight into where things are going wrong. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
This may be a dumb question, but if you make a cpio tape archive from data on an SCO system (HTFS filesystem), you can still restore the data off the tape to another system, like FreeBSD with a UFS filesystem, right? This should work. If you run into any issues they will be incompatibilities between SCO's cpio and the GNU cpio that FreeBSD uses. And the followup, can FreeBSD run SCO binaries (SCO Unix 5.0.1)? I am going to try and convert these people from their SCO box over to a FreeBSD system. Just want to make sure the data will come off the tape. Yes, but support is really limited. You need to copy a bunch of core libraries onto the FreeBSD machine from the SCO machine to make things work. (We just emulate the syscall interface -- you need libc and friends from SCO.) Matt -John On Oct 9, 2004, at 6:51 AM, Doug Russell wrote: On Fri, 8 Oct 2004, Sergey Babkin wrote: Try to use the Verify menu from the Adaptec BIOS. It finds and tries to re-map the bad sectors (it tries to preserve data during this too, unless the sector is completely unreadable). The verify commands issued by the BIOS are virtually useless compared to the type of tests done my sformat. If you enable automatic read re-allocation, it is almost the same as simply reading your whole disk with dd. I do the full 14 pattern tests before I put a SCSI disk in service. When a disk starts losing blocks like this, usually they only multiply over time. The best thing you can do is replace the disk and move the data before you lost more of it. NO! Not necessarily! If a disk has simply grown a few new defects since it was new, it does not necessarily mean it is going to die. I have many disks that had minor bad spots on them that weren't even always found by the factory format routines, or had appeared since (due to transport, debris in the HDA, poor holding power for the magnetic fields in some area, etc). If the drive passes through a few full patern tests without problems and doesn't continue to grow new defects, it is likely just fine. I've got all kinds of old SCSI disks that were 'discarded' due to errors. Only a couple are truly dead... the rest have been running for years with no problems after making a real grown defect list from the pattern tests. This is something I learned many many years ago when running my old Miniscribe 3650s on a Perstor high density controller. It formated the drives to 31 sectors per track instead of 17. Hard on the disks, and the media, but a good drive, after being properly tested, would run flawlessly for years being hammered 24/7 on BBS machines. Got 78 megs per drive instead of 42.whatever it was. :) Later.. Doug John Von Essen ([EMAIL PROTECTED]) President, Essenz Consulting (www.essenz.com) Phone: (800) 248-1736 Fax: (800) 852-3387 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
Well, I eventually got this SCO system working. But today, some errors appeared: 505k:unrecover error reading SCSI disk on 0 Dev 1/42 cha = 0 id = 0 1 on = 0 Block 6578 medium error unrecovered read error HTFS i/o failure occurred while trying to upgrade 1 node 26302 on HTFS. Dev hd 1/42 Error log over flow block 6578 medium error unrecovered read error . Do these sound likes hardware errors for the drive or the adaptec card itself? The drive is brand new (well, its actually a replacement from acer with a date code on it from 1998 so it has been sitting in a box for awhile). However, the card is very old too. Any ideas? -john medium error unrecorvered read error really sounds like a phsycial medium (drive) error. If the controller was flaky, you'd get bus retries and stuff. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hacking SCO....
I believe DAT is what you want to tell SCO. -- Matt - Original Message - From: John Von Essen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 27, 2004 6:33 PM Subject: Re: hacking SCO Well, I was able to get a boot/install floppy made. Then install a fresh SCO. Then create recovery floppies, then boot with recovery floppy and try to cpio tape data to /mnt. However, in both the recover floppy and the real SCO system I have to configure the tape drive apparently. As of right now, I can not access the tape device. SCO's tape device builder asks what type of tape, is a DDS-2 considered DAT or 8mm? Anyway, I wish I would of thought of the dd args to skip the bad sectors and continue on. Now that SCO is installed (which took an hour and a half) I would hate to start over. The drive is really messed up, dd would copy a couple thousand records, then the drive would start making a horrendous noise and through an IO error stopping dd. You have no idea how much I hate SCO. I feel like I am cheating on my girlfriend every time I login to this damn box. -john On Sep 27, 2004, at 4:15 PM, Doug Russell wrote: On Mon, 27 Sep 2004, John Von Essen wrote: I have a new replacement 4Gb disk. With a FreeBSD boot CD I did a dd and was able to get the new disk setup with all of the old disks partition maps, boot data, etc.,. The new disk actually boots into SCO but fails because it only has 100Mb or so of data. Try addingconv=sync,noerrorto your dd line. If most of the data after the defect(s) can be read, you'll end up with an almost complete partition which will likely run. You can then fsck and restore from tape. for example, dd if=/dev/daX of=/dev/daY conv=sync,noerror bs=128k Later.. Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
- Original Message - From: Devon H. O'Dell [EMAIL PROTECTED] To: Matt Emmerton [EMAIL PROTECTED]; Mike Meyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 18, 2004 4:01 AM Subject: Re: FreeBSD Kernel buffer overflow - Original Message From: Matt Emmerton [EMAIL PROTECTED] To: Mike Meyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD Kernel buffer overflow Date: 18/09/04 05:41 - Original Message - From: quot;Mike Meyerquot; lt;[EMAIL PROTECTED]gt; To: quot;Matt Emmertonquot; lt;[EMAIL PROTECTED]gt; Cc: lt;[EMAIL PROTECTED]gt;; quot;Avleen Vigquot; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt;; lt;[EMAIL PROTECTED]gt; Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow gt; In lt;[EMAIL PROTECTED]gt;, Matt Emmerton lt;[EMAIL PROTECTED]gt; typed: gt; gt; I disagree. It really comes down to how secure you want FreeBSD to be, and gt; gt; the attitude of quot;we don't need to protect against this case because anyone gt; gt; who does this is asking for trouble anywayquot; is one of the main reason why gt; gt; security holes exist in products today. (Someone else had brought this up gt; gt; much earlier on in the thread.) gt; gt; You haven't been paying close enough attention to the discussion. To gt; exploit this quot;security problemquot; you have to be root. If it's an gt; external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton So should we stop the command ``shutdown -h now'' from working for root? After all, he can DoS the system with it? How about this: let's disallow root from loading kernel modules! That way this can't ever happen. Even better: Why don't we just not boot into a usable environment! Then we have NO security holes. You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. Not to be sarcastic, but you guys are missing the problem. The problem was that someone was unaware of a kernel API. When you start programming for the kernel, you need to make sure that the code is secure. If you think this is a problem, take a look at init(8) and learn about securelevels. What happened: someone was unfamiliar with the syscall API. They crashed their system. They screamed wildly, believing they'd found a buffer overflow, when they'd merely overloaded the function stack and screwed up the call. This caused the system to reboot. Solution: make it more clear that syscalls take only 8 arguments. Make it clear that you can pass arguments in a struct to a syscall. Make it clear that many/most syscalls do this anyway. If there's beef on this, take it to [EMAIL PROTECTED] Mike and I discussed this offline. Can someone just step up to work on and commit the KASSERT code which handles the problem and end the thread? The only reason I piped up was because nothing had been done yet, and suggested two alternate ways of hardening the system that could be enabled/disabled by the system administrator, instead of being always enabled (like a KASSERT, which always incurs a run-time check and thus could hurt performance.) -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? Extra code on a time-critical path with no sane use whatsoever. Note that anyone who adds a syscall (or a library function, for that matter) with that many arguments deserves public humiliation for terminal lack of taste, so it's not going to help anything that wouldn't be worth rm -rf... I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) An article posted today on Slashdot ( http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html ) points out that this attitude as a key reason why OSS code isn't neccessarily more secure than commercial counterparts, even though there are more eyes on the source. We have to realize the fact that there *are* insecure FreeBSD installations out there, and because of the OSS nature of FreeBSD, the availability of the source code and public mailing lists like this one (which highlight possible security holes) makes the development of exploits much, much easier. The argument of extra code on a time-critical path is valid, but only if we're concerned about building the fastest BSD out there. However, we can provide a choice to system administrators by wrapping these sanity checks with a runtime if-check of a sysctl value, or a compile-time #define, much like we use for WITNESS or INVARIANTS today. I'm reminded of the old adage of good, fast, cheap -- choose two. There's nothing preventing us from implementing all three and leaving the choice of which two to use up to the end-user. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Kernel buffer overflow
- Original Message - From: Mike Meyer [EMAIL PROTECTED] To: Matt Emmerton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Avleen Vig [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow In [EMAIL PROTECTED], Matt Emmerton [EMAIL PROTECTED] typed: I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of we don't need to protect against this case because anyone who does this is asking for trouble anyway is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this security problem you have to be root. If it's an external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mount name length limit (MNAMELEN)
On Wednesday 04 August 2004 17:40, Patrick Dung wrote: Hi It seems that the constant is in /usr/sys/sys/mount.h. The limit is already there since the initial import in 1995. (From 4.4BSD?) I want to know what is the root cause preventing a larger value. PS: I have found some interesting links about MNAMELEN: http://leaf.dragonflybsd.org/mailarchive/kernel/2003-08/msg00194.html http://www.secnetix.de/~olli/FreeBSD/mnamelen.hawk I recall bringing this up on the FreeBSD lists a while ago (1-2 years?) and IIRC, the reason this is tough to change is that we use this constant in a lot of internal structures, and changing the constant will change the structure sizes which will break a lot of things. From what I've seen in the Linux code, they never store a char blah[MNAMELEN] in their structures, but rather, a pointer to that data element (in the name cache, I think). Thus, they are free to change the size of the element without affecting the majority of structures that use it. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is this LOST??
On Sunday 02 May 2004 01:26 am, Deng XueFeng wrote: I found the htonl implemention in libc for i386 is not sync with the kern. sys use bswap for swaping the int. but libc still use xchg. IS THIS LOST? It's because libc still supports 80386 which doesn't have bswap (introduced on the 486 IIRC). The kernel only supports 486+ unless you explicitly build an 80386 kernel, which won't use bswap for htonl(). Since 5-current kernel do not support 80386. why keep libc(5-current) support 80386? The 5-current kernel *does* support 80386 -- you have to recompile your kernel to add 80386 support first. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
- Original Message -
From: Garance A Drosihn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 20, 2004 5:45 PM
Subject: Adventures with gcc: code vs object-code size
I have written a fairly major set of changes to the `ps' command,
which is available as:
http://people.freebsd.org/~gad/ps-susv3.diff
Debate/discussion about the changes themselves actual changes should
be going on in the freebsd-standards mailing list. So for purposes
of this mailing list, please ignore most of that.
But while doing it, I was somewhat obsessed about making sure that
my changes wouldn't cause a dramatic increase in the size of the
executable for `ps'. Due to that, I tripped over one example of
code vs object-code produced which makes no sense to me. So,
consider just this section of the update (with some reformatting
so it is easy to see the code):
char elemcopy[PATH_MAX];
...do stuff...
#if !defined(ADD_PS_LISTRESET)
inf-addelem(inf, elemcopy);
#else
/*
* We now have a single element. Add it to the
* list, unless the element is :. In that case,
* reset the list so previous entries are ignored.
*/
if (strcmp(elemcopy, :) == 0)
inf-count = 0;
else
inf-addelem(inf, elemcopy);
#endif
Now, here is what I noticed:
* XXX - Adding this check increases the total size of `ps' by
* 3940 bytes on i386! That's 12% of the entire program!
* { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 }
*
* When compiling for sparc, adding this option causes NO
* change in the size of the `ps' executable. And on alpha,
* adding this option adds only 8 bytes to the executable.
So, by adding one call to strcmp() to check for a : string, I end
up with /bin/ps (the stripped-object-file) which has grown by 12.6% !!
This is for a program which is almost 2500 lines spread out over
5 '.c'-files. How is that possible? What am I missing here?
I am not a compilier guru, so I suspect it would take me hours to
pin this down. I don't want to do that, so I'm wondering if anyone
understands how such a minor code-change can POSSIBLY cause such a
huge change in resulting object file... I also wonder if this same
issue pops up in other programs, too.
I don't know why the code bloats so much on i386, but I do question the use
of strcmp() for a single-character compare.
Something like the following would probably be better (and would avoid your
problem):
if (elemcopy[0] == ':')
inf-count = 0;
else
inf-addelem(inf, elemcopy);
--
Matt Emmerton
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Matthew D. Fuller wrote: On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. It won't necessarily be the prettiest process, but I'm in favor of letting the floppies be a bit ugly, or even explicitly moving them to experienced users only status. I just find them far too convenient, as well as ubiquitous, to see them sent into the Great Bitbucket In The Sky yet. This is exactly what Debian does. I was a bit ticked when I found I had to make 7 floppy images to get a machine installed, but the important part is that it worked. Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. I myself have 4 machines (out of the 6 in front of me) that are Pentium- or Pentium II-class machines that cannot boot from CD-ROM or PXE, thus floppies are my only choice. Thus, I am genuinely interested in the effort to maintain working floppy images and can help out -- but not to the point of being maintainer yet. However, I have no experience building releases at all, so someone from re@ will have to help me along. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
3) Simple but time consuming requests from developers - Isn't it possible to have developers pass off some of their simple tasks to others? Think of it like a pet dog. Your dog may be able fetch your newspaper but he couldn't read it. Still fetching the newspaper takes time! The requests I see are usually Jr. kernel type requests. Everyone wants to contribute at the kernel level but that takes a lot of knowhow and experience working with fbsd's kernel. Let users get involved with simple (stupid) tasks which are time consuming. Now define simple... Again, I think a JKH (Junior Kernel Hacker) list (like the one PHK had for awhile) would be a great addition. I'll even volunteer to maintain it if developers were willing to help me by providing these small projects for people to work on. As someone attempting to join the ranks of people in the Submitted by: log lines this is one of the hardest things for me to do is find something I can work on. The only problem with a JKH list is that there need to be committers willing to review and commit PRs that are created from the tasks on the list. About a year ago I started working on one of PHK's tasks, opened up 4 PRs, and found absolutely nobody willing to review or commit them. After a month of pinging people and waiting for feedback (and getting absolutely none), I just stopped working on it. It's these kinds of impasses that prevent people who have the skills and time from actually contributing to the project. There really isn't any use opening PRs and creating patches if they're never going to get committed (or by the time someone decides to commit them, the patches need to be moved forward 3 or 4 releases.) -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 20:31 06/01/2004, Mark Linimon wrote: There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. Speaking of which... if there's one thing which could be done to improve committer / non-committer relations, it would be to *do* something with all those PRs. The ports team is pretty good -- my maintainer updates have always been committed fairly quickly -- but I've never had a src patch committed without badgering committer(s) about my PRs. Don't misunderstand me; I think the project is heading in the right direction, and committers are doing a great job. But I think the contributions of non-committers could make FreeBSD even better, and those contributions are being largely lost or ignored. Exactly. I've filed PRs that have languished for months, and then after picking some random person from -current or -stable, the patches in the PR get committed within a week. I'd imagine that there's a lot of PRs that get dropped because they sit for 6+ months and then the submitter can't be found or cannot reproduce the situation. I think the problem is that too many commiters are focused on their own corner of the project, and there's nobody left to handle all the general sort of PRs. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
