Re: [SC-L] Interesting article on the adoption of Software Security

[Crispin Cowan]

Andreas Saurwein wrote:
Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just 
as good) PL/M went the opposite direction from C, making it very 
annoying for a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
No, just trivial decisions on syntax. It made my fingers hurt to use it, 
because I had to retrain a lot of habits. Unfortunately I no longer 
remember the specifics.

When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well 
earlier,
when you include the third party ISVs - as an add on).  IBM had 
Language
Environment (LE) before .NET come along.
Crispin Cowan wrote:
I think .Net borrows most heavily from Java. Java in turn borrows 
from everyone. The "managed code" thing in particular leads back to 
the Pascal P-code interpreter; a kludge to make the Pascal compiler 
easier to implement and port. The innovation in Java was to take this 
ugly kludge and market it as a feature :)
Michael S Hines wrote:
I'm not sure that it can be blamed on Pascal. Microsoft was shipping 
Excel for the Mac in the early 80's as P-Code application and has been 
selling P-Code generating compilers since about the same time. Ever 
since, MS was strong on P-Code generating compilers.
The UCSD Pascal P-Code system was released in 1978 
. 
MS Excel was released in 1984 
. And if anything, 
the above claim that MS has been using P-code since the early days of 
Excel only supports the claim that Pascal P-Code is the origin of the 
idea at Microsoft.

Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com

RE: [SC-L] Interesting article on the adoption of Software Security

[Wall, Kevin]

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 

Re: [SC-L] Interesting article on the adoption of Software Security

[Andreas Saurwein]

Crispin Cowan wrote:
However, where ever C made an arbitrary decision (either way is just as 
good) PL/M went the opposite direction from C, making it very annoying for 
a C programmer to use.
Does that mean it did not make any decision at all? What was the outcome?
Michael S Hines wrote:
When you've been around for a while, you start to see the same features
converge..  UNIX had quotas, we got Quotas with Win XP Server (well earlier,
when you include the third party ISVs - as an add on).  IBM had Language
Environment (LE) before .NET come along.
Crispin Cowan wrote:
I think .Net borrows most heavily from Java. Java in turn borrows from 
everyone. The "managed code" thing in particular leads back to the Pascal 
P-code interpreter; a kludge to make the Pascal compiler easier to 
implement and port. The innovation in Java was to take this ugly kludge 
and market it as a feature :)
I'm not sure that it can be blamed on Pascal. Microsoft was shipping Excel 
for the Mac in the early 80's as P-Code application and has been selling 
P-Code generating compilers since about the same time. Ever since, MS was 
strong on P-Code generating compilers.

Michael, let me please correct two more things in your comment:
1) there is no such thing as a Windows XP server (probably you refer to 
Windows 2003 Server)
2) Quotas have been native to Windows 2000 already (lets not discuss quota 
management now...)

cheers
Andreas