From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Bernecky To: Chris Lattner Cc: , , , Subject: RE: Esthetics (or worse?) of Secure Pointers Date: Tue, 17 Apr 2001 15:46:00 -0000 Message-id: References: X-SW-Source: 2001-04/msg00812.html 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