Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

2004-06-11 Thread Crispin Cowan
David Crocker wrote:
Apart from the obvious solution of choosing another language, there are at least
two ways to avoid these problems in C++:
1. Ban arrays (to quote Marshall Cline's C++ FAQ Lite, arrays are evil!). Use
...
2. If you really must have naked arrays, ban the use of indexing and arithmetic
on naked pointers to arrays (i.e. if p is a pointer, then p[x], p+x, p-x, ++p
 

If you want safer C and you want the compiler to enforce it, and you 
don't mind having to re-write your code some, then use one of the safer 
C dialects (CCured http://manju.cs.berkeley.edu/ccured/ and Cyclone 
http://www.research.att.com/projects/cyclone/). These tools provide a 
nice mid-point in the amount of work you have to do to reach various 
levels of security in C/C++:

   * low security, low effort
 o do nothing
 o code carefully
 o apply defensive compilers, e.g. StackGuard
 o apply code auditors, e.g. RATS, Flawfinder
 o port code to safer C dialects like CCured and Cyclone
 o re-write code in type safe languages like Java and C#
 o apply further code security techniques, e.g. formal theorem
   provers WRT a formal spec
   * high security, high effort
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

2004-06-11 Thread Michael S Hines
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.

Many of our Operating Systems seem to have evolved out of the old DEC RSTS
system.  For example, CP/M had a PIP command.  Later renamed to COPY in DOS.


UNIX had a hierarchical file structure.  DOS inherited this feature early
on.  

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.  

It all sort of runs together over time - it seems.

Mike Hines
---
Michael S Hines
[EMAIL PROTECTED] 




RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

2004-06-11 Thread David Crocker
ljknews wrote:


And there are ways of using Assembly Language to avoid pitfalls that it
provides.  There are ways of using horse-drawn carriages to avoid the
major reason (think street cleaning) why the automobile was embraced in
urban areas during the early part of the 20th century.

What there are _not_ are reasons for new development to cling to languages
which make flawed constructs easy for the individual programmer to misuse.


There is often one very good reason for clinging to such languages: because
there is no other suitable language available. As has already been pointed out,
there is usually very little alternative to C/C++ when it comes to kernel mode
code.

I would love to see a safer alternative to C/C++ for writing operating system
kernels, device drivers and real-time embedded applications (yes, I know Ada can
be used for the latter, buts its package structure and associated with-ing
problem can be a real pain in large systems). The newer programming languages
such as Java, C# and Eiffel are all designed for applications and make heavy use
of garbage collection (which is a boon to application writers, but a no-no for
kernel code and many embedded apps).

What I don't understand is why the language standardisation committees don't
remove some of the unsafe dross when they bring out new language revisions. A
classic example is the failure to define the type of a string literal in C as
const char*. Just imagine if we had a new version of C++ with all the unsafe
stuff removed. Backwards compatibility would not be a problem in practice,
because the compiler suppliers would provide switches to make their new
compilers accept obsolete constructs.

As for non-real-time application-level code, I gave up writing them in C++ by
hand long ago. [Actually I prefer to write specifications, verify them, and let
a code generator produce correct C++ from them; but that is another story.]

David Crocker
Consultancy  contracting for dependable software development
www.eschertech.com






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

2004-06-11 Thread der Mouse
 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.

Lisp.  I used Lisp Machines back when I worked in academia, and almost
everything was in Lisp, including most of what would in a more
conventional OS be called the kernel.

Of course, the Lisp dialect they used was not, strictly, typesafe,
since it had subprimitives that allowed you to assemble arbitrary
lispvals out of nothing.  (In fact, I submit that a language that does
not have some analog thereof _cannot_ be suitable for writing the
lowest-level kernel code, though it may be fine for the more
disciplined parts of the kernel.  Vide infra.)

 Especially on Windows and the Linux platform.

If you're restricting yourself to OS Foo, then you will have a very
hard time finding a language suitable for OS hacking except for the
language(s) that Foo is written in.

For example, you are unlikely to have an easy time of doing Linux
kernel code in any language but gcc.

 What is the C language downfall is also its best strength.

Yes.  It's a little like a Formula 1 racecar: touchy, unforgiving...and
a good deal more powerful than your average car.

Of course, you don't go shopping for groceries in a F1 racecar; C is
not always the right answer.  But simply because it does not force code
to be typesafe does not automatically make it the wrong answer, either.
(For example, I have trouble imagining how you could build the VM
subsystem in a language that did enforce type safety.)

The problem is not C.
The problem is using C when it's not the right language.

Note also that the right language varies not only with the problem,
but with other things too, such as who's going to be writing the code.
(As a simple example, C is a right language for more problems for me,
who's been using it for going on twenty years now, than it is for
someone who got a little of it in half of a course last semsester but
really knows Visual BASIC inside and out.)

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B




[SC-L] IBM OS Source Code

2004-06-11 Thread Michael S Hines
I was a bit wrong earlier..   IBM System Programming language was PL/X (not
PL/M)...

Here's a link to an older reference manual...
http://www.bitsavers.org/pdf/ibm/360/pls/GC28-6794-0_PLSIIguideMay74.pdf

Mike H.

---
Michael S Hines
[EMAIL PROTECTED] 




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

2004-06-11 Thread ljknews
At 9:16 AM -0500 6/11/04, Michael S Hines wrote:

 IBM had Language Environment (LE) before .NET come along.  

What is Language Environment (for either of those) ?




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

2004-06-11 Thread Crispin Cowan
Michael S Hines wrote:
Likewise for the IBM Mainframe operating systems MVS,OS/390,z/OS - much of
which is written in (I believe) PL/M - a dialect much like PL/1.
 

If PL/M is the language I am remembering from an embedded systems class 
back in the 1980s, then it is not at all like PL/1. Rather, it is a 
completely type-unsafe language. I would say similar to C, in that it 
has most of the same pitfalls. 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.

Many of our Operating Systems seem to have evolved out of the old DEC RSTS
system.  For example, CP/M had a PIP command.  Later renamed to COPY in DOS.
 

True.
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.  
 

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 :)

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