C considered harmful
John Macdonald
jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR at public.gmane.org
Thu Dec 4 22:45:11 UTC 2003
On Thu, Dec 04, 2003 at 01:42:39PM -0500, Anthony de Boer wrote:
> Peter Hiscocks wrote:
> > So, it is an interesting challenge to the language writers to create
> > something that has the power of the C language and still does (say)
> > automatic checking of array bounds.
>
> This idea may be fine within an application, but it breaks down at
> security boundaries like the user/kernel interface, since the kernel had
> better not trust the user program's claim of the size of an array (this
> being an approximation of how Debian got burned), also since the kernel
> is dynamically carving out chunks of memory for things, and since "one
> man's program is another man's data" (the whole program may be one array
> of mere data to the kernel).
>
> There's a lot that can be fixed with opaque handles to structures (eg.
> Dan Bernstein's string library as opposed to the traditional C library's
> simple char * string implementation); C++ formalizes some such ideas,
> but a prudent C programmer can write better code without needing C++'s
> extra baggage.
Not only does language provided bounds checking fail
to be useful in this instance, it is this sort of
case where it often can get in the way. Not only
does the kernel code have to convert and validate
pointer values between user space representation and
kernel representation but (in the case of language
enforced bounds checking) it would also have to
convert the bounds info as well as the address, *and
then convince the language that it is allowed to use
the converted result. Often, languages that try to
prevent errors do not provide a way to cheat (i.e.
compose a "pointer" by hand).
--
The Toronto Linux Users Group. Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
More information about the Legacy
mailing list