Comments

: Given recent experiences at work (regualar job) I have determined that : Johnathan's position on boundary checking is the correct course for the : CBOOP standard.: Woohoo. :-)

: However, Johnathan seeks this feature to protect against poor coding : and errors. I am convinced it is necessary for security.: Many security issues arise as a result of poor coding and uncaught errors. I might not have mentioned security explicitly, but I think it goes without saying that poor coding that leads to an attacker having the ability to overflow a buffer is quite possibly going to lead to a security problem.

Trading in some performance for safety (and thus better security) has been going on for decades.

Boundary checking will be included in CBOOP. However, this will be included only in external interface code unless otherwise declared to the compiler. There are reasons for this...

(1) Buffer overflows are only security threats when a component is accessed by some arbitrary external entity. This includes hardware and sofware components connected to the given component. Internal calls and accesses are not typically violated since the programmer of the component would be violating his own software.

(2) Boundary checking internally is a consumption of resources many would like to avoid. Thus, since system stability is not threatened as much as in the case of external overflows (e.g. hack attempts), the process should be optional for the developer--depending on his trust of any public code used in the project and his own coding skills.

Lastly, boundary checking will be enabled by a command issued in the c-squared language's compiler language subset. It should be turned on and turned off in the source code (not through an IDE). This will allow boundary checking only for code that requires it.

Hence, should I write some of my own elaborate (and rightfully deemed excellence) code for a project and make said code public then some other person (such as the esteemed Johnathan) use that code in his own project, it is possible that he could turn on boundary checking before and after the inclusion of my code...making sure I am minding my p's and q's. ;-)

This same compiler language subset format will be used throughout the development of c-squared.

: Boundary checking will be included in CBOOP. However, this will be : included only in external interface code unless otherwise declared to : the compiler. There are reasons for this...: There are reasons for setting your hair on fire too, but I'm not sure they're good ones. (By the way, don't try it. I did it by accident in a chemistry class. It smelt kinda awful. :-))

: (1) Buffer overflows are only security threats when a component is : accessed by some arbitrary external entity. This includes hardware : and sofware components connected to the given component. Basically, if we don't accept any user data into our program, we're safe. Apart from programs with no input data are pretty boring.

: Internal calls and accesses are not typically violated since the : programmer of the component would be violating his own software.: Hmmm...

Data propogates throughout a system. Buffer overflows generally result from lack of validation before calling another routine, e.g. strcpy or memcpy, or some other internal or library routine. Your suggestion is essentially "let's build a wall to protect our city, but we won't bother having an army in case it's breached because walls never get knocked down". Then something shoots a ballistic missle through it and you're screwed.

I'm pretty sure that if you go and look at which bits of code get attacked in some real-world buffer overflow situations, you'll find that some of them are pretty deep in.

Also think of the poor programmer. "OK, so what methods are protected?".

: (2) Boundary checking internally is a consumption of resources many : would like to avoid. Yup, many folks are so against it that nobody uses JAVA, or any .NET language, or Perl, PHP...oh, wait...they do. If you're writing something that needs really high performance (e.g. games) or an OS or something that low level, I agree you don't really want it. But most people aren't writing those things. Most people are writing business, desktop and web apps.

: Thus, since system stability is not threatened as much as in the case : of external overflowsDisagree with this hypothesis, see above.

: (e.g. hack attempts), the process should be : optional for the developer--depending on his trust of any public code : used in the project and his own coding skills.: : Lastly, boundary checking will be enabled by a command issued in the : c-squared language's compiler language subset. It should be turned on : and turned off in the source code (not through an IDE). This will : allow boundary checking only for code that requires it.: I strongly recommend on always by default, and then the people who really want their performance can disable it. That way, newbies hacking together that web script are getting the protection they need.

: Hence, should I write some of my own elaborate (and rightfully deemed : excellence) code for a project and make said code public then some : other person (such as the esteemed Johnathan) use that code in his own : project, it is possible that he could turn on boundary checking before : and after the inclusion of my code...making sure I am minding my p's : and q's. ;-): But what if your code is somehow too trusting of the input I give it? Then we're back to square one. Even great programmers make mistakes or too many assumptions. There's a particular danger when their code is being used by someone else who is making their own set of assumptions (because the first rule of documentation is that nobody really reads it, right? :-))

I've probably said this a lot of times before, but one of the most important things a programming language can do for an applications programmer is to take care of memory management for them. It boosts productivity, makes bug finding easier and leads to more robust applications.

As usual, Johnathan, your critique is on target. I will agree to make boundary checking the default in this system. Yet the highest risk of component compromise is at the point of interface. Here boundary checking will pay off in spades. I recently dissected a little nasty that literally raped the Component Object Model (COM). Two things would have prevented this hack: boundary checking and component-identity verification.

Here lies the rub: I am starting to add more and more protective layers to the compiler (which has been thrown away until the redesign is complete). These layers are adding more and more run-time overhead to the output the compiler will yield. I need CBOOP to take care of memory management (boundary checking, garbage collection, etc) in real time while also allowing some form of component authentication.

Where is the balance? Some of this needs to be implemented at the system level through an API. But that is long term. To do so, however, would improve overall performance of CBOOP components.

I know that Java and company are great and popular with the masses. But labelling men of science and independent thought as heretics was also once a popular concept (Copernicius? Aristotle?) and now we know that it was insanity. ;-) What I am proposing is a return to the binary format with a language that can adapt to individual platforms. Hence a cross-platform language that tailors itself to the binary machine.