From: Robert Bernecky <bernecky@acm.org>
To: Chris Lattner <sabre@nondot.org>
Cc: <greg@mcgary.org>, <gcc@gcc.gnu.org>, <gnu@toad.com>, <bernecky@acm.org>
Subject: RE: Esthetics (or worse?) of Secure Pointers
Date: Tue, 17 Apr 2001 15:46:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.31.0104171412260.1110-100000@cobra.localhost> (raw)
In-Reply-To: <Pine.LNX.4.21.0104171657170.11717-100000@nondot.org>
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
next prev parent reply other threads:[~2001-04-17 15:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-17 15:00 Chris Lattner
2001-04-17 15:46 ` Robert Bernecky [this message]
2001-04-17 16:06 ` Chris Lattner
2001-04-17 16:32 ` Robert Bernecky
2001-04-17 17:00 ` Greg McGary
2001-04-17 16:52 ` Greg McGary
2001-04-18 10:00 ` Joern Rennecke
2001-04-17 16:43 ` Greg McGary
2001-04-17 19:20 ` John Gilmore
2001-04-18 9:22 ` Joe Buck
2001-04-18 13:14 ` Toon Moene
2001-04-17 16:36 ` Greg McGary
2001-04-17 17:03 ` Zack Weinberg
2001-04-17 17:28 ` Greg McGary
2001-04-17 17:41 ` Chris Lattner
2001-04-17 18:01 ` Greg McGary
2001-04-17 19:40 ` John Gilmore
2001-04-17 19:46 ` David Edelsohn
2001-04-17 20:01 ` Michael Meissner
2001-04-18 10:03 ` Joern Rennecke
2001-04-18 10:37 ` Robert Bernecky
2001-04-18 11:02 ` Neil Booth
2001-04-18 11:10 ` Joern Rennecke
2001-04-19 0:04 ` Fergus Henderson
2001-04-17 19:59 ` Michael Meissner
2001-04-17 17:56 ` Fergus Henderson
-- strict thread matches above, loose matches on Subject: below --
2001-04-19 2:22 Jimen Ching
2001-04-19 6:49 ` Robert Bernecky
2001-04-17 11:52 Robert Bernecky
2001-04-17 12:29 ` Geoff Keating
2001-04-17 16:28 ` Greg McGary
2001-04-17 16:41 ` Robert Bernecky
2001-04-17 17:52 ` Joe Buck
2001-04-17 18:07 ` Greg McGary
2001-04-17 18:49 ` Joe Buck
2001-04-19 5:26 ` Per Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.31.0104171412260.1110-100000@cobra.localhost \
--to=bernecky@acm.org \
--cc=gcc@gcc.gnu.org \
--cc=gnu@toad.com \
--cc=greg@mcgary.org \
--cc=sabre@nondot.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).