This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Nov 2014 20:56:29 +0000
- Subject: Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library
- Authentication-results: sourceware.org; auth=none
- References: <20141111153449 dot GB52080 at msticlxl57 dot ims dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1411111754330 dot 26374 at digraph dot polyomino dot org dot uk> <87r3x9a7yt dot fsf at tassilo dot jf dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1411112016450 dot 12642 at digraph dot polyomino dot org dot uk> <20141112160432 dot GA5697 at msticlxl57 dot ims dot intel dot com> <alpine dot DEB dot 2 dot 10 dot 1411122125170 dot 31875 at digraph dot polyomino dot org dot uk> <CAMbmDYamHxfspd6MXEbc+ZP7Psef+YtpTCL6RDnkoiMS35CAsA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1411122259240 dot 31875 at digraph dot polyomino dot org dot uk> <CAMbmDYbSg4nrktxpkzZR862kaWHpFoheMugTNUJ5-UZQDi+0nw at mail dot gmail dot com>
On Thu, 13 Nov 2014, Ilya Enkovich wrote:
> > You can leave it as a single library - it's just that imposes libgcc-like
> > constraints on what the library does and how it does things, so as to be
> > usable for arbitrary programs built with MPX (e.g. using
> > reserved-namespace names such as __write when available - direct syscalls
> > may also be a possibility in some cases).
>
> I really don't want to make it libgcc-like and complicate its further
> development. What is the reason for that? Is it because library is
> linked by -mmpx? Can it be avoided if library is linked only at
> '-fcheck-pointer-bounds -mmpx' combination? If single -mmpx is used
What's -fcheck-pointer-bounds? I don't see any documentation of it in
invoke.texi. Any options intended for users to use need documenting there
- did a documentation patch get missed out from the series of patches
posted / committed?
Documentation might help understand the intent of the feature. I think
there are two natural possibilities:
* Use as a lightweight hardening feature enabled by default across a whole
distribution (or for a subset of the distribution considered
security-critical), by people who don't know the detailed requirements of
individual programs built with the option. In that case there are
libgcc-like requirements (as another issue there, it might be problematic
to cause arbitrary previously unthreaded programs to link with libpthread;
at least, performance issues seem possible). Outputting reports to files
determined by environment variables is probably not a sensible approach in
this case. You might want reports to syslog, or might want MPX-detected
issues to be intercepted by crash reporters such as apport so they can
collect relevant information and offer to report it to the distributor.
* Use as a debugging tool, by people who understand the requirements of
their application / library and can tell whether the things the MPX
library is documented as doing might be a problem in their case. For
this, libgcc-like requirements don't apply and output to files seems more
sensible.
If it's intended only as the latter - and this is documented - then you
don't have the libgcc-like requirements, and there's no point in having
multiple libraries. If it's intended for both, that points the way to
separate libraries (where the debugging-tool library would be used in that
use case, but the crash-reporter-interception case would expect programs
to have been linked with only the minimal library).
--
Joseph S. Myers
joseph@codesourcery.com