Re: Software Design (was: Re: [tlug] Confessions of a closet OpenBSDuser)

[Josh Glover <jmglov@example.com>]

Viktor Pavlenko wrote:
>>>>>>"VT" == Uva Coder <uvacoder@example.com> writes:
>>>>>
> 
>     VT> It doesn't matter how elegant your (userland) code appears.

I am not sure I follow, Uva? Are you saying that elegance does not 
matter, or that code can appear to be inelegant and really be elegant?

> Most of the code is userland.

I should interject, Viktor, that most code *should* be userland. There 
has been a disturbing (to me, at least) trend in Linux recently to move 
more and more functionality into the kernel (as you note below). I mean, 
Tux? Sure, it is a high performance webserver, but what is it doing in 
the kernel? Maybe in a webserver appliance, sure, but not in a general 
purpose kernel.

I mean, a webserver exploit is now a kernel exploit. That is *so* much 
worse than even a root exploit!

>     VT> If Linux's (and *BSD's) overall security model contains
>     VT> significant flaws in its design, then attempting to create the
>     VT> fix in the userland isn't the best answer. The answer lay with
>     VT> the kernel itself. Design, especially security, begins with
>     VT> the kernel.
> 
> True that security begins with the kernel but it doesn't end there.
> Kernel has to support many insecure operations to be usable.

I am not sure that I agree here, Viktor (sorry to keep calling you by 
name, but this Uva vs. Viktor thread is confusing me! ;). I do not want 
the kernel to have to provide unsafe functionality to insecure userland 
stuff. I think that the mindset that leads to good security is to make 
every layer as secure as possible, and force the developers who depend 
on the functionality that you are providing to adopt better practises.

I think that Uva is dead-on here.

>     VT> Blaming sloppy userland development seems to me to be a red
>     VT> herring.
> 
> You can't even imagine how wrong you are.

I can! ;) Think of it this way, Uva: the system libraries ([g]libc) are 
userland. Sloppiness here affects any application that is not statically 
linked against a different set of libraries. How many security 
vulnerabilities have we seen over the years because of sprintf() and 
friends being vulnerable to buffer overflows and string format exploits?

>     VT> IMO what Linux, *BSD, and UNIX need are innovative ideas
>     VT> incorporated at the kernel level; not at the userland
>     VT> level. Plan 9's IL protocol is a good example of out of the
>     VT> box thinking.

I like you just for your repeated Plan 9 references. I played with it 
very briefly, and absolutely loved the design philosophy. Would that I 
had a bit more time...

>     VT> I believe that if Linux fails as an OS, it will be due to too
>     VT> much "in-the-box" thinking; not from "sloppy" code.
> 
> If linux fails it will be because too many things will have been moved
> into the kernel.

I cannot agree with you here, Uva. "In-the-box" thinking is sometimes 
just what we need for higher quality software. A solid design, following 
good, formal software engineering practises is what "in-the-box" 
thinking can accomplish. Of course, creativity, both in design and in 
implementation, is what pushes things to the next level, takes 
technology higher. We need those conservative guys to perfect what the 
hugely creative guys envision.

I have known so many skilled coders who come up with a great idea, but 
get bored with the more mundane details of coding and resort to 
sloppiness and kludges to either save them some work or just to spice up 
the code a bit. Fun? Maybe, but it leads to some buggy software.

And I think that what Viktor points out in his closing line is a symptom 
of lack of a good design. This feature creep, if you will, is even more 
tempting when you do not have a series of extremely complicated UML / 
finite state machine diagrams to update. In this way, laziness can 
sometimes save the day... ;)


-- 
Josh Glover <jmglov@example.com>

Associate Systems Administrator
INCOGEN, Inc.