> 2 words explain this approach: "Source code"
Why are we naively assuming that any functionality has to be in
the source code. It's well know that higher level compliers
drop in start-up and end-of-run code which sets up the
environment for the language to run. If I wanted to affect
**all** source code, I would attack the compiler and drop in my
trojan hacks at start up time.
We also assume that compilers are 100% accurate, and seem to
forget that compilers are applications written by people who are
prone to make the same types of errors we see in operating
systems - this is why there are stringent testing processes for
any code developed and compiled (even assemblers may kick out
the wrong op code for a symbolic statement - its possible). As
we all know a successful compile doesn't mean a bug free
product.
A successful compile doesn't even guarantee a perfect object
code generation either... most of the time it's pretty
close... but I think you will find that most compilers are not
at version 1.0 anymore... indicating bug fixes have been
released. If the same compilers are used to generate OS, then
the OS are going to be buggy to - even though the source code
appears bullet proof.
Almost makes on wonder how we get any work done, doesn't it?
:)
-----------------------------------------------------------------
Internet: mshines @
purdue .
edu * Michael S. Hines, CDP, CFE
Voice: (765) 494-5845 * Sr. Information Systems Auditor
FAX: (765) 496-1814 * Purdue University
if AC 765 doesn't work, try 317 * 1065 Freehafer Hall
* West Lafayette, IN 47907-1065
All views are my own and do not reflect Purdue University policy.
References:
|
|
