Esthetics (or worse?) of Secure Pointers

[Robert Bernecky]

Well, sort of.

[I don't want to start a religious war here; I do want to  make
my position clearer.]

Think of John's proposal as a stepping stone. We introduce a new
architecture (bounded-x86) that lives alongside the existing
x86 architecture. In the fullness of time, everyone buys
into the secure-x86 architecture, we retire the x86 architecture
completely, and everyone lives happily ever after.

Will this work? I believe that there are strong
engineering and liability reasons that will make it work.
Here is a tiny picture of the future of the programming
world, as lawyers exploit their y2k experiences:

http://www.theregister.co.uk/content/8/18324.html

As computing professionals, we have a responsibility to
provide provably reliable tools. C without secure pointers
is not reliable. We (the computing community) are going to
be forced to move programming from a craft to an engineering
discipline. Issues of performance and memory use are going
to be swept aside by the threat of lawsuits.

As someone who has worked with array languages since the dark
ages (a bit earlier, actually), I have to emphasize that code
safety (in the sense of having array buonds checks and automatic
memory management) is an incredibly powerful tool for creating
secure and robust applications. Buffer overflows simply do not
and CAN NOT exist in array languages (modulo compiler bugs, of
course).

Secure pointers are not a complete solution to the problems in
C (dangling pointers can still exist, and the absence of
real arrays (N-dimensional objects rather than vectors of
vectors) causes increased overhead and opportunity for
more code faults), but they move us a long way toward
reliability.

John's position, and mine, is that good optimization work should
let us get the cpu time overheads down to acceptable levels.
We are stuck with the memory overhead, but memory is cheaper
every day, so that's probably acceptable, particularly now that
64-bit architectures are becoming reasonably priced.

Bob

On Wed, 18 Apr 2001, Joern Rennecke wrote:

> >
> > On Tue, Apr 17, 2001 at 10:45:44PM -0400, David Edelsohn wrote:
> > > 	The ELF architecture field in the header is assigned, not
> > > something that one can "pick a new specifier" without causing conflicts.
> >
> > But since the ABI is effectively different anyways, one could argue it is a
> > different machine (John's proposal) and/or uses a data encoding (my proposal)
> > or even using some other field.
>
> John's proposal is not practical, since it means that you have to allocate
> a new machine identifier for every machine identifier in existance where
> you would contemplate using the BP checking compiler.  And also for all
> future non-BP machine identifiers.  And you have to make sure you don't
> step on someone's elses toes while doing these allocations.
>
> The data encoding proposal seems much more practical to me.  You just have
> to add two more types, and cover all architectures.
>

Robert Bernecky                  Snake Island Research Inc.
bernecky@acm.org                 18 Fifth Street, Ward's Island
+1 416 203 0854                  Toronto, Ontario M5J 2B9 Canada
http://www.snakeisland.com