Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Roundtable On BSD, Security, And Quality

Posted by Nik on from the no-info-on-what-colour-the-table-was dept.

mccormi writes: "Dr. Dobb's Journal is covering a roundtable with four key members of the BSD movement at the recent USENIX Security Symposium 2000. The participants emphasized that reliability and security are achieved through simplicity. Other topics included the evolving distinction between Linux and BSD, why they don't use std::string, and why no one to likes IKE."

9 of 60 comments (clear)

  1. Automated installs by guacamole · · Score: 4

    Theo: "The direction I'm going is to have a facility for installing large numbers of machines easily. Right now you have to do attended installs. It would be nice to have a config file, TFTP or NFS mounts, preload a bunch of defaults, and splat out 30 installs at once. Most of the major OSes have this in some form or other. RedHat Linux KickStart is more complicated than it need be."

    Amen! This would be a very very nice feature!
    I use mostly RedHat and Solaris at work. We use Jumpstart for automating Solaris installs and configuration and kickstart for RedHat installs.
    Yes, it takes an effort to secure a Solaris or RedHat box, but if you script it and prepare an unattended install method then it doesn't matter to you whether to install 20, 30 or 200 boxes at once. This is the reason why we use RedHat instead of Debian (Debian installation is waay too interactive..)

    If OpenBSD will have this feature, good for them.

  2. Re:Linux networking stack by mce · · Score: 3
    Yes, I remember that post from Alan (some 2 or 3 months ago, IIRC). I just did a Google search, but can't find it archived right now. However, here's an equivalent quote from the January 16, 1996 version (yes, this whole confusion is that old already) of the Linux NET-2/3-HOWTO:

    2. Disclaimer.

    The Linux networking code is a brand new implementation of kernel
    based tcp/ip networking. It has been developed from scratch and is not
    a port of any existing kernel networking code.
    ...
    NOTE: While its name may appear similar to the Berkeley Software
    Distribution NET-2 release, the Linux network code actually has
    nothing at all to do with it. Please don't confuse them.

    --

    --
    Linux user since early January 1992.
  3. Re:*CORRECT* LINKS Re:Might be outdated. by Guy+Harris · · Score: 3

    Actually, he meant

    Slide 35

    Slide 36

    so you don't have to cut and paste the frigging URL from the article's text.

    I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.

    In any case, please note that Slide 42 says:

    moving target: is only valid for today

    Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....

  4. Re:Might be outdated. by Guy+Harris · · Score: 3
    Well, looking at the date on that page (01 October 1998) it seems to me that this info just might be just a tad out of date. Have you actually looked at what's in the 2.4 kernel? Maybe things haven't changed, but it sure wouldn't harm to have a look before fudding.

    The item in Linux on that page says

    Current releases of the supported versions of Linux (Red Hat and Slackware) do not use BPF or DLPI. Instead, libpcap sniffs packets by reading packets one by one into user space. The packets source address is compared against its interface name. This implies that all interfaces send all data to all promiscuous listening processes and that the user code is responsible for determining if a packet is interesting.

    The packet sniffing mechanisms available in 2.0[.x] kernels, err, umm, suck. 2.2 introduced a better mechanism, and if you've configured in the right kernel option ("Socket Filter" or something such as that) it supports doing packet filtering at the kernel level (i.e., uninteresting packets aren't copied up to userland).

    Some Linuxes come with libpcap libraries that use the new mechanism; the current CVS version of libpcap at the tcpdump.org Web site, and the beta versions of libpcap 0.6, also use the new mechanism.

    2.4 has, I believe, a mechanism that shares a memory-mapped buffer between the kernel and userland; I don't know if any versions of libpcap use it yet.

    So Linux may now do a better job, at least if you configure the socket filter code into your kernel. It doesn't have any buffering mechanism to "batch up" multiple packets in one recvfrom() call, the way BPF and the bufmod STREAMS module on Solaris do; the 2.4 mechanism (which will, I think, eliminate a copy) might obviate the need for that.

    (People are looking at similar memory-mapped mechanisms for BSD. Had I bothered to implement the "memory-mapped stream head" stuff I was thinking about ages ago at Sun, it might've been available in Solaris as well; so it goes....)

    Note that on Solaris, the same "everything is copied to userland" problem exists that exists on some versions of Linux; I'm not sure why the NFR document speaks of the Linux mechanism as being lower-performance - it may be due to the lack of a buffering mechanism to batch up packets. (They speak of HP-UX, which also lacks such a buffering mechanism, as requiring more CPU for that reason.)

  5. Re:stolen code? by logicTrAp · · Score: 4

    As others have said, GPLing BSD code is mostly ok (modulo the old advertising clause). But it's mostly a moot point since "Linux stole the BSD TCP stack" is just a piece of fiction that has managed to survive all these years. The only BSD networking is actually the BSD PPP compression, the rest is a grounds-up reimplementation (for better or for worse).

  6. Re:Linux networking stack by keepper · · Score: 3
    Links my friend.... Links... Last i've heard, we still mopped the floor with linux on networking...

    Have you ever tried to do any bandwith shapping with linux, or routing? anything network intensive? then you would now why most router OS's have based their stacks on the BSD code.

    But, since you didn't provide links, I WILL BUDDY.
    case 1) NFR's home page. quote
    The performance of NFR on Linux will be poor on any hardware when compared to NFR on BSD-based systems on the same hardware. Linux does not use the BPF. The libpcap library uses another method to extract packets from the kernel on Linux. The code for this method does not appear to be written with performance in mind. Programs such as NFR, which use libpcap to read packets from the interface in promiscuous mode, will experience significant packet loss on any network that sees traffic of several megabits per second or more.

    Linux does not properly handle interfaces in promiscuous mode. It fails to it fails to distinguish packets addressed to it from packets addressed to other machines. This means that you can subvert the Linux system in various ways: Other systems on the network can detect Linux based sniffers by looking for responses to requests sent to the wrong MAC address. The Apostols Web page (http://www.apostols.org/projectz) (in Spanish) describes the exploit. The source code for the exploit program contains comments and error messages in English. On an NFR that is multihomed, someone could use the flaws in Linux to route traffic from the promiscuous interface to other interfaces.


    More you ask?

    http://neuromancer.rmci.net/linux-vs-freebsd.html

    Please stop talking from the wrong end....
  7. I like FreeBSD by Bender+Unit+22 · · Score: 3

    I just added a 45GB drive to my FreeBSD box, it's an old 75mhz Pentium on a Intel motherboard that can't handle drives over 8gb.
    So the BIOS reported some wierd numbers and when I made the partition in FreeBSD, it just said "The BIOS reports some f****d up numbers, do you want to use mine instead(Y/N)"(ok, not word by word). I made my slices on the drive, got it up and running, added it into /etc/fstab and now I have the drive installed and working even though the Intels site says that you can't add a drive at that size on that board. heh.
    And yes, it worked after I booted the machine.
    Well maybe it would not work on a OS that depends on what the BIOS reports.

    --------

  8. Re:stolen code? by bugg · · Score: 3
    But you still must observe the BSD license, reproducing the copyright and disclaimer.

    A poster explained it well here: http://daily.daemonnews.org/view_story.php3?story_ id=1485

    --
    -bugg
  9. Re:stolen code? by Ceren · · Score: 3
    It's not stolen. GPL-ing BSD code is, well, just fine, since sometimes the only way to make use of the code includes slapping a GPL on that copy of it... whatever's clever. We don't care. Good code getting used usefully is the end goal... not spreading a licensing scheme to topple the evil companies that pay programmers.

    Besides, there's a previous copy of that code out there with the BSD-style license on it, so it's not as if suddenly the stack is magically GPL-restricted. Everyone else is still perfectly free to use it for whatever they want.

    The closest thing we have to "stolen" is "taking for use without giving fair credit to the programmer."
    And that's not nice.
    Don't do it.