Esthetics (or worse?) of Secure Pointers

[Robert Bernecky]

We discussed name mangling, but discarded it.
Let me try to recall our
line of reasoning: You have just compiled foo, which calls
goo and hoo. Are the calls to goo and hoo bounded or not?

If you answer the question either way, you have a problem:
If bounded, then all functions down that call tree must be bounded,
because the calling sequences differ for bounded and non-bounded
pointers.
If not bounded, then the whole exercise is moot, as the
callees are not bounded either. The other choice is to require the
user to declare the boundedness of EVERY function in the compilation
unit. This is evil, as it entails non-portable source code changes
for what we hope is a temporary stage of affairs.

Now, let's refuse to answer the question of boundedness.
In that case, we have to deduce which glibc functions
to include (mangling in use), or pick an appropriate glibc (no
mangling). the whole compilation unit is either bounded or not.

The fundamental issue is this: if we want to intermix bounded
and non-bounded code, either the code says it explicitly
(bad -- non-portable), or the compiler has to figure it out
(good -- command-line option). But, how can the compiler
figure which kind of code to emit for a specific function call
for glibc? glibc may change long after the compilation is done,
just to make things more fun.

John  eventually convinced me that there's no way to decide
at compile time what a subfunction's boundedness is. Bummer.
This led us to the compile-the-whole-thing approach, which
we all find scary. Hence, this request for more brain cells.

Thunks almost work, but it  has the unsolved problem of identifying
bounded vs non-bounded pointers in a precise manner.

Bob


On Tue, 17 Apr 2001, Chris Lattner wrote:

>
> > We discarded the function-level intermixing as too low-level
> > and complicated in practice. This left us with larger approaches to
> > the problem of intermixing checked and non-checked code:
>
> Another alternative way to implement this (which would allow a single libc
> that contains both bounded pointer code and nonbounded pointer code to
> exist in the same library), would be to mangle function names, ala
> C++.  Of course you could do this really simply by simply prefixing all
> functions (C as well) with __BP_ or some such ugly thing.
>
> This isn't a wonderful solution from a cleanliness standpoint, but it
> would make it "impossible" to accidentally mismatch code.  It would also
> make it possible to have a library with both bounded pointer and
> nonbounded pointer code linked into it, which would be nice.
>
> -Chris
>
> http://www.nondot.org/~sabre/os/
> http://www.nondot.org/MagicStats/
> http://www.nondot.org/~sabre/
>

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