Slashdot Mirror
A Roundtable On BSD, Security, And Quality
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."
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.
It's been done, and applied to NFS and others, for quite a while. The freebsd-announce mailing list would be a good place to check for more; substantial work on it has been done for several months.
As for Linux, it's soomething that just came into 2.4 with one of the TUX patches in Q3 2000, as far as I know (source: http://boudicca.tux.org/hypermail/linux-kernel/200 0week36/0979.html)
"He's as blind as he can be, just see what he wants to see, nowhere man can you see me at all?"
-bugg
My two favorite (edited) highlights:
DDJ: What's the main difference between BSD and Linux?
WL: The strong central source repository. You know what you're building. With Linux, "You need this, and you need this, and get this somewhere else, and today we just discovered that you need these twelve patches." There's no way to keep up with that. It's crazy-making. With the BSDs, you synchronize to the sources, "make world" or "make build", and you know exactly what's running on your machine. From a security point of view, that's good.
DDJ: What's the thing with IKE? There are guys running around here wearing buttons, "I don't like IKE."
AK: The problem is 300 pages of specification. The implementation we have of this in OpenBSD is about 36,000 lines of code without the crypto. That's just the protocol. I can't think of one single piece of code that size and start to debug it.
TdR: The Boeing 747 flight control deck has about 30,000 lines of code, separated into 12 independent modules. That's the right way to do things.
o/~ Join us now and share the software
Well, AFAIK, the KAME stack has a relatively complete feature-set. In fact, I think the IPSec implementation in a lot of stacks (Linux included) is fairly complete. HOWEVER, from what I understand, interoperability is still an issue. If you have a homogenous network of OpenBSD boxes, you could probably set up an IPSec-based infrastructure. However, once you mix things up a bit, it probably won't work as seemlessly (although, since the BSDs share the KAME stack, they'll interwork... the real problem is when you get commercial stuff in the mix).
And as for the userland implementation, again, AFAIK, there's a nice API for accessing all these features. You'd still have to modify the apps to make use of the APIs, obviously, but the interfaces are there.
Also thought the SMP stuff was good, but I'm still under the impression that the OpenBSD crowd aren't that keen on it.
Well, from previous conversations with Theo, I don't think SMP is even on the horizon for OpenBSD, due to the huge architectural overhaul required.
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.
Actually, he meant
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:
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"....
The item in Linux on that page says
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.)
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).
its templatized nature leads to massive code bloat
Please show me a C++ snippet, using the STL, which demonstrates this "massive code bloat". While some C++ compilers are certainly atrocious (Solaris C++ comes to mind), the majority of them make small, fast code.
In the Red Hat 5.x days, C++ compiled to massive size due to an error in how Red Hat was set up--not due to an error in the compiler.
Seriously. Please show me a code snippet, using GCC-2.95 or later, which expands into a large executable. I'd like to see it, and so would the GCC maintainers.
Because /. is written in Perl and PHP and who knows what else. Not C++. You'll note that /. doesn't post major articles attacking Perl, because that would make them look like hypocrites. Anyhow...
Programmers interested in security should definitely take a closer look at std::string. I agree with you that the reason that it's only used in one out of 300 programs is because they're writing an OS, not an application nor a library nor an extensible framework, etc, etc. But std::string answers most of the same security concerns they brought up!
I'll just give two reasons right here:
But of course, you won't hear about it on /. if they do any of that, because that would make C++ look useful.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Its also funny to see you use techno-babble you don't understand in regards to hardware checksumming. But I digress...
The fact is that Linux and BSD each help make the other better, with friendly competition among the actual developers and a free flow of information between them. With rare exceptions, the attitude between workers in the two camps is one of mutual respect and even occasionally admiration. The BSD vs. Linux lamers simply don't understand
In the 2.2[.x] Linux kernel, you have to configure the socket filter code on; it's not on by default (for reasons not obvious to me).
(If you're referring to the BSD BPF code, that has to be compiled in on some BSDs, although it's there by default in recent FreeBSDs and possibly in other BSDs; however, if it's not there, you can't do packet capture at all - the in-kernel BPF engine is an integral part of the BPF packet capture mechanism, unlike Linux where you can have PF_PACKET sockets without the socket filter.)
WL: Not a lot, though sometimes one steals ideas. Linux, for instance, stole part of the BSD networking stack. [Pauses.] All of it.
So what happens when people GPL BSD code? Is there anyone to sue to get it taken out?
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
More you ask?
http://neuromancer.rmci.net/linux-vs-freebsd.html
Please stop talking from the wrong end....
STL is certainly a handy set of classes but its templatized nature leads to massive code bloat. If bloat is a consideration don't use STL even if you write the rest of your code in C++.
I wasn't aware that IPsec was so far along. I was planning on writing some code for a 'secure' server and had been looking at FreeBSD and writing up a lot of my own daemons like FTP et al, but now I'll probably take a longer look at the stack on OpenBSD. Does anybody know how far they've got with implementing these features in userland so far? Any plans for other OSes to get compliant so we can start seeing proper IPsec infrastrucutres popping out of the mists?
:-) I bet that last comment gets me marked down as flamebait or troll.
Also thought the SMP stuff was good, but I'm still under the impression that the OpenBSD crowd aren't that keen on it. I can understand why, but I think that they've pretty much got the security sussed now, so perhaps it's time they started looking further afield - the remote install stuff looks good and is not only good for rolling out over a LAN but makes OEM installs for machines to sell easier as well.
I think this was typical of the BSD crowd though (myself included) by discussing all the bad stuff with Linux without actually mentioning any of the good stuff. Although, like I said, I'm a BSD bigot, so I'm not quite sure what the good stuff in Linux is.
Noh, what's odd is that we all laughed and wondered how it could have been stolen and screwed up so badly in the process. :)
Yes, this has been hashed over and over again on the kernel list. For the record, there has never been a BSD derived stack in the official linux kernel tree. Someone ported it in the timeframe of early 90s, but because of the license (advertising clause) it couldn't be included in the kernel. I tried to search for a reference to this effort, but couldn't find one right now (Alan Cox mentioned this on linux-kernel once).
Just about the only BSD code that has been included and still lives in the kernel tree, is the PPP compression code. It could only be compiled as a module, but now as the license has been changed, this has changed.
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. /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.
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
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.
--------
AFAIK a team of researcher working on FreeBSD still have the record for TCP performance, using FreeBSD/Alpha on a Myrinet network.
See..
The performance reached was 1.147 billion bps on a single TCP connection... Way over what Gigabit Ethernet or ATM are even physically able to do. Those boards are really fast...
Anyone know about more recent results ?
How bizarre. I'm using FreeBSD with Qt/KDE. No problems. Perfectly reliable. Surely Qt/KDE counts as noncomplex C++ programs. I also do my own C++ development on FreeBSD. No problems. By the way, BSD uses ELF, not aout.
Brzzzt. Next contestant.
A Government Is a Body of People, Usually Notably Ungoverned
Maybe I'm not a smart as most C/C++ programmers. I can't remember the arguments for all the library functions. So I always use man. It's my primary documentation. And every time I use man strcpy() it always tells me to beware.
A Government Is a Body of People, Usually Notably Ungoverned
Good.
'Secure by default' should be the norm, not the exception.
"...America's great minds of today, teaching America's great minds of tomorrow. Poor bastards." -- A Beautiful Min
What is it about C++ and OOP that Slashdot has to continually disparage it? Just today they have a complete article on the "hype" of OO, and now this. Their mention of std::string in its context makes it sound like BSD thinks std::string is a bad thing, possibly even insecure.
Read the friggin article! They don't use std::string in 299 of 300 programs because those programs are written in C! Why not C++? Because it's an operating system. C is better for low level systems programming, not because C++ sucks.
Out of the hundreds of points made in this article, dozens of which can be considered at least somewhat controversial, why did Slashdot choose to mention "why they don't use std::string"?
A Government Is a Body of People, Usually Notably Ungoverned
...that they have to discuss that the fact the things that are more simple are easier to secure. That's one of the first rules in any form of security, and especially in computer security. As for the widening rift between Linux and BSD, that came about because of the different startup schemes (SystemV for (most) Linux systems and, well, BSD for BSD). Oh yeah, and the different logos (The penguin is cooler...but chicks the daemon is hot...)
CAP THAT KARMA!
Moderators: -1, nested, oldest first!
SIG: HUP
I can see where the author is coming from because some proffessors swear by OOP. Stuff like, "it's not right unless it's OOP and/or OOD". At the same time, I think he is over stating the procedural languages.
...
...
...
...
...
...
In some ways procedural languages like C could be confusing. You'd have all these functions working on data, and unless the person did a good job of documenting it, it can be hard to follow.
Add to that the fact that in C, and other procedural language, if you wanted a function to work on some variable you had two real choices. You could make the variable global--which some consider a big no no, or you can pass it in the arguments. You can really increase the number of augments fast that way.
I use mainly C++ because it is not a pure OOP language. This allows you to use a function where appropriate, and a class where it would work better. For example, let's say you have complex numbers you want to manipulate. In languages like C, you need to create a function(s) for all the mathematical operations you want to perform. Then the code reads something like this:
complex res,x1,x2;
multiplycomplex(x1,x2,res);
In C++, you can incorporate all the functions into one class, and you can overload operators to make the code more readable. The above example could look like this:
complex x1,x2;
res = x1 * x2;
To me, this is more readable and it looks more like the what you want the operation to do.
In the end, no mater what style of programming you use, it comes down to how you design it. While I like using OOP, I don't like religous use of OOP just for the sake of OOP.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that