Esthetics (or worse?) of Secure Pointers

[Greg McGary]

Joe Buck <jbuck@racerx.synopsys.com> writes:

> It might be possible, for specific libraries, to write a set of thunks
> that would allow bounds-checked code to call the non-bounds-checked C
> library.

To some degree it is possible.  I did this in the early going as a
necessity of bootstraping so that I could run the C torture tests with
a non-BP glibc.  Once GCC passed enough torture tests, I moved on to
glibc, and now that I have a BP glibc, I no longer need thunks to run
torture tests or to port anything else.

> Such things might be necessary for people on OSes that don't
> have a free C library to use the bounds checking compiler.

We have limited resources.  Bending over backwards to support non-free
OSes is a poor use of those resources.  Much better to press forward
in the land of the free.

> This thunks layer would assume that the C library is correct, and
> use the known properties of the library function to determine bounds
> in cases where pointers are returned (e.g. for malloc we set the
> lower bound to result and the upper bound to result+size).  And yes,
> I know there are lots of problems with functions like strchr that
> assume strings are properly null-terminated.
> 
> But even if this is done, in the end it perhaps doesn't make a great
> deal of difference: if you use bounds checking you need a different libc.
> Perhaps this is produced by building a libc from source with a bounds
> checking compiler, or perhaps it is produced by some other form of
> trickery as described above.

IMO, it's an interesting academic research project, but has no
priority over the important work of finding and fixing bugs & security
holes in free software.

Greg