Re: why is the world full of idiots ?

"ivan" <ivan@userlevel.com> writes:
> yeah... its all true. this and that. whatever

Been there, done that. This sort of idea has floated around for a *long* time, in various flavours. For instance,

	ITS -- the operating system *was* the debugger.
	UCSD P system -- the compiler had an OS and interpreter built in.
	Commodore PET -- came with Basic in ROM.
	Java -- fix all the problems with weak type checking and
		machine dependent logic.
	LISP -- lots of obscure incarnations.

I think the closest thing to what you want today is probably Perl or maybe python. These are both very powerful, and you can do a lot, fairly efficiently. There are limits to where you can go - and I think it's both interesting and significant that perl & python both make it easy to write C library extensions.

The problem with embedding the OS into the language is that you tend to end up with very limited functionality OS designs. The USCD P system & Commodore Pet are both good examples of this.

One of the constants of the universe seems to be that, whatever speed hardware you have, to get the most out of it you want a langauge that allows you to do high level programming (and C, despite whatever you have heard, *is* capable of this), yet does a fairly efficient job of expressing machine semantics. To get everything out of it, you need assembler too. Modern OS design reflects this -- most OS designs today are written mostly in C with a smattering of assembler.

The problem with code written in C++, java, etc., is that you *still* get bugs. Part of the problem is that C++ and java are both evolving rapidly. So it's easy to get version creep problems between language & application(s). Another part of the problem is that both are much more complex than C. It's harder to identify and solve problems in the language compile-time & run-time subsystems. Portability becomes much more of a challenge. Yet another part of the problem is that both languages make it much easier to write badly organized and confusing code.

Avoiding buffer overflows is just the start of security. There are still *plenty* of other ways to do bad security, such as relying on bad random number generation, confusing authentication and authorization, using weak cryptography, doing insufficient checking on untrusted data, failing to recover correctly from system or program crashes, dealing with integer overflow, etc. Everybody "knows" you shouldn't pass unaudited input from a cgi script to a shell - and this still happens.

I recently had occasion to write some code that did the proposed AES string to key function, in a variety of languages. The fastest versions I have are ones written in C, that use assembler language versions of the SHA-1 hash. This is because the proposed fuction spends 99% of its time doing 90112 sha-1 hashes. The slowest versions I have use the "least-native" interpreters -- Kaffe on OpenBSD, and Perl on Solaris. The fastest version to write was perl. In order to get it all working, I had to resolve problems with java compilers (kjc couldn't make a working rijndael from the source I had found), and if I were serious about this, I'd have to chase down interesting key size limits in later versions of Sun Java selected to please the french. The proposed iteration count, 45056, was selected by some of the IETF working group to make a deliberately "slow" password hash that would take "about a second" on the slowest hardware people contemplated -- a pentium III at 300 Mhz. Whatever speed hardware you have, *somebody* is going to figure out how to use *all* of it. And using Java doesn't increase program reliability or security.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

I think the most interesting systems for security down the road are going to be systems that are modular, simple & easy to understand, and heterogeneous. Heterogenous means it shouldn't be all written in one language, use one processor, or run under one OS. If hardware becomes cheap enough, it may be practical to do what is done with the shuttle today: run 2 different software packages on different hardware that do the "same" thing, compare output, and do something appropriate if the results don't match.

There are still people who do serious programming in Fortran today. Hard to believe, but there it is.

                                -Marcus Watts Received on Mon Mar 31 23:23:25 2003