Re: Esthetics (or worse?) of Secure Pointers

[Joe Buck <jbuck at racerx dot synopsys dot com>]

John Gilmore writes:

> The whole idea, from my point of view, is to implement secure pointers
> efficiently enough that people just accept the 10-15% overhead, since
> for most people CPU cycles are close to free anyway.  And eventually
> to influence chip architecture for more efficient support.

I like the work on bounded pointers very much.  But there are many
applications where very large data structures are needed, and we can't
get around the fact that pointers now require three times the memory.
We may be able to get down to 10-15% time overhead, since most checks
won't have to be made and many bounds are the same.  But the space
overhead is another matter.

For some algorithms that some people care deeply about (e.g. static timing
verification of an ASIC) we're already having trouble fitting in 2^32
bytes (5 million gates, with 1Kbyte or so of data for each gate to represent
all the pins and the time delays between transitions on each pin pair,
you get the idea) -- of course, folks can and are moving to 64-bit
machines, but many are reluctant to do so before they have to.  We could
still do bounded pointers, if we force the designers of such algorithms to
change their data structures, maybe by using integers for pointers and put
all the objects into one space ... oops, looks a lot what malloc and thin
pointers do now.

Evil memories of all those 16-bit Windows C pointer types come creeping
back ...

> I see little
> point in implementing a curiosity that nobody will use; if it doesn't
> have a shot to become the mainstream, then it isn't worth doing.

Despite my caveats above, I'd feel much better about things if every
program that runs as root or is setuid used bounded pointers.  Buffer
overruns become impossible; one less nasty to worry about.