Re: Esthetics (or worse?) of Secure Pointers

[Robert Bernecky <bernecky at acm dot org>]

Greg's right on all of the following: I'm the newcomer
on the project, and am not up to speed on much of this;
Greg's done all the work up to this point.
Answers to his questions (or new ideas) at the bottom are still
desired, as would be some more info on multilibs.

Bob

On 17 Apr 2001, Greg McGary wrote:

> Robert Bernecky <bernecky@acm.org> writes:
>
> > The glibc change is difficult: due to internal changes in
> > pointer structure, glibc has to be recompiled in toto.
> > Programs compiled with bounds checking are incompatible
> > [from a linker/loader standpoint] with existing [non-bounds-chedked]
> > programs: the function call interface has to change for
> > pointers.
>
> I see no trouble here.  Recompile libs for BPs.  No biggie.  You want
> to do that anyway so that bounds checks are active for the libraries.
>
> > From a sanity standpoint, we'd like to be able to
> > intermix bounds-checked and non-bounds-checked functions.
> > John, Greg, and I discussed possible resolutions to this problem.
> > John and Greg may wish to correct me on my appreciation of our
> > discussion, which follows.
>
> Bob, I think you are hallucinating! John and I agreed long ago
> that trying to mix bounded and unbounded code is an exercise in
> frustration, and a poor use of time, since the resulting program has
> holes in its checking.  IMO, the only sort of mixing that's desirable
> is at the program level: you want to be able to run 100% BP programs
> and 100% non-BP programs on the same OS.  IIRC, John doesn't even care
> for any mixing: he wants the BP system to be an entirely different
> architecture that's incompatible with non-BP.
>
> > We discarded the function-level intermixing as too low-level
> > and complicated in practice.
>
> You stopped hallucinating so soon.  Good!  8^)
>
> > This left us with larger approaches to
> > the problem of intermixing checked and non-checked code:
> >
> > a. Multiple libraries: discarded as too fragile and
> >    unstable, at least in their current state.
>
> I don't recall discarding that idea.  I think it's the only way to go.
>
> > b. Rebuild entire applications with the new library. John's opinion
> >    is that, at least in Linux, we have complete source
> >    code availalbe, so building an entirely new distribution
> >    is reasonable.
> >    Obviously, non-Linux GCC users may not have this degree
> >    of control, but come the revolution... Oops, sorry. 8^}
> >
> >    This is messy, in my view, as it is be possible,
> >    in practice, to introduce bounds checking into
> >    a bazllion lines of code and have it all work.
> >    So, we'd like to have a NudgeWare(tm) solution, in which
> >    we can migrate applications in a more controlled manner.
>
> Assuming you have a kernel that accommodates both BP and non-BP
> programs, it's not so difficult to bootstrap an 100% BP system since
> you can build things with a cross-compiler (BP target, non-BP host)
> and test in a chroot'ed tree.
>
> > c. (Bear with me...) Greg's work controls bounds checking
> >    by a compiler flag:  --enabled-bounded.
>
> Correction: the options are -fbounded-pointers and -fcheck-bounds.
> The first tells GCC to make pointers "fat", the second tells GCC to
> emit bounds checking code.  Using the first implies the second.  One
> can explicitly turn off the second to get fat-pointer interfaces
> without having runtime bounds checks.  This could be used for
> partitioning the debugging task, or for assessing the performance
> impact of fat-pointer handling in isolation from that of runtime
> checks.
>
> >    This means that we use the same glibc for both checked and
> >    non-checked output.
>
> That it doesn't necessarily follow.  Compiler options can trigger use
> of alternate library sets.  That's what multilibs are all about.
>
> >    John suggested an alternate approach which may work fine,
> >    but Greg is a bit leery of it, and I don't know enough about
> >    the issues: Bounds-checked code would be produced by
> >    introducing a new target architecture. My understanding of
> >    this us that it would let us have multiple glibcs lying
> >    around, in a manner that we could control easily.
>
> With multilibs, it is possible to have a single compiler executable
> produce code that requires different library variants.  I'm not so
> leery about handling BPs as a different target architecture, I just
> think it might be inconvenient.  OTOH, maintaining multilibs just so
> one can use the same compiler for BP and non-BP might be more
> inconvenient.  I'd appreciate the input of someone experienced with
> maintaining multilibs.
>
> > So, the question boils down to:
> >
> > 	What is the appropriate way to introduce an incompatible
> >       glibc, preferably in a way that lets it coexist with
> >       the existing glibc?
>
> It must be a different glibc (and different every-other-lib).  The
> only question is:
>
> 1) should BP compilation be done with a cross compiler (non-BP host, BP
> target), and BP libs found in the place reserved for that target.
>
> 2) should BP compilation be done with a compiler option and BP libs
> found via multilib mechanisms.
>
> I favor #2 because whereas it's useful to think of BPs as being a
> different architecture in some contexts, they really aren't so
> different as that.  The same machine insn set is used, and both kinds
> of programs can run natively and simultaneously on the same OS.  (If we
> go with #1, is there any barrier or added inconvenience to running BP
> programs with shared libraries?)
>
> Greg
>

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