RE: Interesting article on the adoption of Software Security

["Wall, Kevin" <Kevin.Wall () qwest com>]

Dana Epp wrote...

[...snip...]
> For those of us who write kernel mode / ring0 code, what language are 
> you suggesting we write in? Name a good typesafe language that you have 
> PRACTICALLY seen to write kernel mode code in. Especially on Windows and
> the Linux platform. I am not trying to fuel the argument over which 
> language is better, it comes down to the right tool for the right job. I
> know back in December ljknews suggested PL/I and Ada, but who has 
> actually seen production code in either Windows or Linux using it?

I suppose it's _possible_ that one might be able to sneak in a bit of
carefully constructed C++ in one of these kernels, but you'd probably
have to be very careful about what you used (e.g., probably most of
STL is out) and in the end, you'd probably have to use

        extern "C" {
          ...
        }

wrappers around most of your stuff so it could interface with the
rest of the kernel.

I thought of doing something like this back in 1990 when working on
device drivers with the Unix System V kernel at Bell Labs, but the
potential problems (several having to do with DTORs IIRC and the binding
issues) seemed to outweigh any potential gain. I thought of also using
C++ as "a better (more strongly typed) C", but that too didn't seem
worth it.

Of course, there are some kernels that were implemented in C++; Clouds
comes to mind.

> Lets face it. You aren't going to normally see Java or C# in kernel code
> (yes I am aware of JavaOS and some guys at Microsoft wanting to write 
> everything in their kernel via managed code) but its just not going to 
> happen in practice. C and ASM is the right tool in this area of code.

I'd pretty much agree with this. You seldom even see Java or C# used in
real-time systems (and let's face it, the kernel itself is pretty much
real-time; don't want to be missing an interrupt while doing GC).
Perhaps once the Real-time Specification for Java is approved and
implemented by Sun, this will change, but I don't think that we'll
be seeing many new OSes adopt Java or C# for their kernel code.
(However, I think this also has to do in part with the fact that most
OS/kernel developers are not experts in OO...just my opinion.)

[...snip...]
> Cripin is right; new code SHOULD be written in a type safe language 
> unless there is a very strong reason to do otherwise. The reality is 
> that many developers don't know when that right time is. And resulting 
> is poor choice in tools, languages and structure.

I think, in a large part, that's because your average developer knows
only one or maybe two programming languages. And if they know more,
they only know languages from a single paradigm (e.g., OO, logic programming,
functional programming, procedural, etc.).  Because of this, the view is
"when all you have is a hammer, everything looks like a nail".

> I'd love for someone to show me... no... convince me, of a
> typesafe language that can be used in such a place.
                                     ^^^^^^^^^^^^^^^^

Not sure I get your drift here. Did you mean "in commercial systems"
or in OS kernels or something else? (Cut me some slack; I've only
had 2 cups of coffee so far. ;-)

> I have yet to see it for production code, used on a regular basis.

Here at Qwest, we've been pretty much exclusively using nothing else
besides Java and C# since the last 6 years. (Java for about 6+ years
and C# for the past 2 years.)

So buffer overflows are pretty much things of the past, but developers
still don't validate most of their input data so there's still plenty
of XSS and SQL injection problems left. (IMO, these are just another
example of failure to do proper data validation, as are buffer overflows.)

[...snip...]
> ... Nor is right to assume you can use 
> typesafe languages as the panacea for secure coding.

To be sure, about 50% of the security holes that I still see are
the results of dumb design decisions (e.g., no authorization checks
whatsoever, placing sensitive data in persistent cookies, etc.).
Keeps my team plenty busy. ;-)

OTOH, I'm sure we'd be a lot worse off if developers here were still
allowed to use C or C++ to write new code in.

Cheers,
-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
[EMAIL PROTECTED]       Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former Whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit