On Wed, Apr 1, 2015 at 9:34 PM, Jeff Law <l...@redhat.com> wrote: > On 03/31/2015 03:47 AM, Ilya Enkovich wrote: >> >> On 23 Mar 13:19, Ilya Enkovich wrote: >>> >>> Hi, >>> >>> May this patch go into trunk at this point? It is very important for >>> dynamic MPX codes. >>> >>> Thanks, >>> Ilya >>> >> >> I additionally documented changes in invoke.texi. OK for trunk? >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-03-31 Ilya Enkovich <ilya.enkov...@intel.com> >> >> PR driver/65444 >> * config/i386/linux-common.h (MPX_SPEC): New. >> (CHKP_SPEC): Add MPX_SPEC. >> * doc/invoke.texi (-fcheck-pointer-boudns): Document >> possible issues with '-z bndplt' support in linker. >> >> libmpx/ >> >> 2015-03-31 Ilya Enkovich <ilya.enkov...@intel.com> >> >> PR driver/65444 >> * configure.ac: Add check for '-z bndplt' support >> by linker. Add link_mpx output variable. >> * libmpx.spec.in (link_mpx): New. >> * configure: Regenerate. > > Just to make sure I understand. With this patch we conditionally pass -z > bndplt based on whether or not it's supported by the linker we find when we > configure GCC. > > Failure to pass -z bndplt won't cause the program to misbehave, but will > limit the effectiveness of MPX. > > Gold doesn't support -z bndplt, just newer versions of the BFD linker. > > Gold issues an error for -z bndplt, old BFD linkers will issue a warning. > > There are, at least in theory, use cases where we might not have a PLT and > thus -z bndplt wouldn't make sense anyway. > > I guess the one thing I don't like here is that whether or not to pass -z > bndplt is made at the time we configure GCC. Yet, it's trivial for someone > to change the system linker later, either to gold or from an old BFD linker > that doesn't support -z bndplt to one that does support -z bndplt. > > [ Note we have the same issue with certain assembler feature tests. ] > > I'm not aware of any real infrastructure in GCC to query the behavior of the > linker at link time and then customize the options passed. So if it's going > to be configurable, then that's the only time to do the test. > > I strongly disagree with HJ's assertion that we should always pass the flag, > regardless of the underlying linker. > > So, in an ideal world, we'd query the linker at link time and pass the flag > anytime we have a linker that supports the capability and perhaps warn if > the linker doesn't support that capability. > > Given we're not in that ideal world, I think Ilya's patch is reasonable and > should be installed.
Without proper PLT for MPX, all external function calls will clear bound registers. MPX is a security feature. Cyber criminals only need to get it right 1 time. An organization who uses MPX for cyber security may not realize they leave a door open due to an old linker. What I want to avoid is 2 years from now, bank of foobar comes out saying that they thought they were protected by MPX, but somehow MPX didn't catch a buffer overflow it was supposed to and there was no compiler error message to warn programmers. -- H.J.
