Date: Mon, 29 Nov 1999 16:03:13 -0700 From: Warner Losh <imp@village.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Dan Moschuk <dan@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <199911292303.QAA97590@harmony.village.org> In-Reply-To: Your message of "Mon, 29 Nov 1999 14:49:00 PST." <199911292249.OAA12040@apollo.backplane.com> References: <199911292249.OAA12040@apollo.backplane.com> <199911292221.OAA11475@apollo.backplane.com> <199911292202.OAA09817@apollo.backplane.com> <19991129161327.E2999@spirit.jaded.net> <199911281751.JAA40710@freefall.freebsd.org> <199911292104.NAA09106@apollo.backplane.com> <199911292200.PAA95264@harmony.village.org> <199911292214.PAA97196@harmony.village.org> <199911292235.PAA97412@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199911292249.OAA12040@apollo.backplane.com> Matthew Dillon writes: : Arguably, NFS is much more useful on a boot disk then, say, security : options for pid and source port. For most systems this is the case. : :We're at the level where > 1k should be the threshold. Many changes : :in the kernel have > 1k. look at kern_ntptime.o. It is approx 2.5k, : :but not optional. Other example could be found in that same size : : kern_ntptime is not optional simply because a huge number of people : use it, because there are options in rc.conf that need it (xntpd : for example), and because the core facilities provided by ntptime : are necessary for a number of other modules, including NFS. Have you : ever ran an NFS server with multiple clients where the clients haven't : been time synched? We didn't dare do that even back in the 80's. Yes. I have. However, it isn't needed for the boot disk since none of its functionality is used. I know that for 99%+ of the systems I'd install I'd want both ntp and the port randomization. The port randomization is important because it makes it harder by several orders of magnitude to launch an attack against a system (instead of just guessing the tcp initial sequence number, you also have to guess the port number as well, which adds 10,000x to the complexity of launching such attacks). Ditto for temp file races. If you don't know the pid of the program you are racing, it too becomes a much more difficult problem. In other discussions, it is sounding like the agregate cost is going to be bigger than the 1k threshold that I had set. Once it crosses this threshold, then it should be looked at as an option that is on by default due to its importance in securing the system. People that really don't need it (there are a few, like embedded devices w/o network access) can shut it off. : :range (or bigger, look at the kernel linker at 6k)... That's the : :point I'm trying to make. There are bigger poles in this tent and we : :have't been good about marking the poles, nor in establishing policy : :for compile time vs runtime engineering decisions. : : : :Warner : : But, frankly, I dont' understand your argument. If you are arguing : that there are other modules that could be optimized I don't see how : that justifies not optimizing a trivially optimized module while the : author still has his book open to it. The authors of the other modules : do not necessarily have their books open to those any more, so we are : really talking about uncompareable things here. I guess I'm arguing that it isn't worth optimizing things this small, book open or not, when it hasn't been a focus in the past, isn't really a focus now and there are generally larger fish to fry in this area to make it worth the extra hassle of having extra kernel compile time options that we already have too many of. Your objection appeared to be that it would run us out of room on the boot disk. My contention is that it is useful enough to find 686 bytes somewhere else, and the nfs modules are a good place to look for fat since they are 150k combined, or about 5% of a compressed floppy while this option (the one costing 300 bytes compressed) is < .002%. That's why I brought it up at all. I'll bet we can get 5k out of the nfs modules w/o cutting any functionality at all with minimal efforts. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911292303.QAA97590>