| Message ID | 20150406151742.GA43634@msticlxl57.ims.intel.com |
|---|---|
| State | New |
| Headers | show |
On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >> >> To tell the truth, I can't figure out what this means from a user >> perspective. How does a user know whether the linker option is >> being ignored, or if they have a new enough linker? If the linker >> available at configuration time doesn't support the option, does >> that mean the option will never be passed and users will never know >> that there are gaping holes in the pointer bounds checking? >> >> My suggestion would be to pass the option unconditionally and make >> the documentation say something like > > This option was rejected. Right. There really isn't a good option here because we don't have the infrastructure to query the linker's capabilities at link time. Though I do wonder if we could issue a warning in the case where the configure test indicated -z bndplt was not supported. It'd obviously mean a link warning every time an end user tried to use that toolchain to create a DSO or executable with MPX protection. But that may be better than silently leaving some code unprotected. Jeff
2015-04-06 18:28 GMT+03:00 Jeff Law <law@redhat.com>: > On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >>> >>> >>> To tell the truth, I can't figure out what this means from a user >>> perspective. How does a user know whether the linker option is >>> being ignored, or if they have a new enough linker? If the linker >>> available at configuration time doesn't support the option, does >>> that mean the option will never be passed and users will never know >>> that there are gaping holes in the pointer bounds checking? >>> >>> My suggestion would be to pass the option unconditionally and make >>> the documentation say something like >> >> >> This option was rejected. > > Right. There really isn't a good option here because we don't have the > infrastructure to query the linker's capabilities at link time. > > Though I do wonder if we could issue a warning in the case where the > configure test indicated -z bndplt was not supported. I thought about such possibility. Just don't see a good place for that. Probably introduce some WARNING_SPEC which targets may define to issue a driver warning? Ilya > > It'd obviously mean a link warning every time an end user tried to use that > toolchain to create a DSO or executable with MPX protection. But that may > be better than silently leaving some code unprotected. > > > Jeff >
On 04/06/2015 09:17 AM, Ilya Enkovich wrote: > On 05 Apr 19:44, Sandra Loosemore wrote: >> On 04/03/2015 01:34 PM, Joseph Myers wrote: >>> On Tue, 31 Mar 2015, Ilya Enkovich wrote: >>> >>>> +library. It also passes '-z bndplt' to a linker in case it supports this >>>> +option (which is checked on libmpx configuration). Note that old versions >>>> +of linker may ignore option. Gold linker doesn't support '-z bndplt' >>>> +option. With no '-z bndplt' support in linker all calls to dynamic libraries >>>> +lose passed bounds reducing overall protection level. It's highly >>>> +recommended to use linker with '-z bndplt' support. In case such linker >>>> +is not available it is adviced to always use @option{-static-libmpxwrappers} >>>> +for better protection level or use @option{-static} to completely avoid >>>> +external calls to dynamic libraries. MPX-based instrumentation >>> >>> Use @samp{-z bndplt} rather than '' quoting (but Sandra may have further >>> advice on the substance of this documentation). >> >> To tell the truth, I can't figure out what this means from a user >> perspective. How does a user know whether the linker option is >> being ignored, or if they have a new enough linker? If the linker >> available at configuration time doesn't support the option, does >> that mean the option will never be passed and users will never know >> that there are gaping holes in the pointer bounds checking? >> >> My suggestion would be to pass the option unconditionally and make >> the documentation say something like > > This option was rejected. Hrmmmm, how about then just *never* passing the magic option to the linker, and telling users they either have to pass it manually (and use a linker that supports it), use static linking, or do without bounds checking on dynamic libraries? Remember that most GCC users do not configure GCC themselves... they use whatever came with their distro or from their toolchain vendor, or was installed by their sysadmin. So most GCC users have no way to know what linker their GCC binary was configured with and it's just confusing that this important linker option might or might not be included based on factors they don't know about or can't control. > +++ b/gcc/doc/invoke.texi > @@ -5858,12 +5858,12 @@ a runtime library to enable MPX in hardware and handle bounds > violation signals. By default when @option{-fcheck-pointer-bounds} > and @option{-mmpx} options are used to link a program, the GCC driver > links against the @file{libmpx} runtime library and @file{libmpxwrappers} > -library. It also passes '-z bndplt' to a linker in case it supports this > -option (which is checked on libmpx configuration). Note that old versions > -of linker may ignore option. Gold linker doesn't support '-z bndplt' > -option. With no '-z bndplt' support in linker all calls to dynamic libraries > -lose passed bounds reducing overall protection level. It's highly > -recommended to use linker with '-z bndplt' support. In case such linker > +library. It also passes @option{-z bndplt} to a linker in case it supports > +this option (which is checked on libmpx configuration). LD supports it starting > +from version 2.25. Gold linker doesn't support @option{-z bndplt} > +option. With no @option{-z bndplt} support in a linker all calls to dynamic > +libraries lose passed bounds reducing overall protection level. It's highly > +recommended to use linker with @option{-z bndplt} support. In case such linker > is not available it is adviced to always use @option{-static-libmpxwrappers} > for better protection level or use @option{-static} to completely avoid > external calls to dynamic libraries. MPX-based instrumentation Besides being confusing, there are typos ("adviced") and grammatical errors here. If we really cannot make the linker option either always used or always omitted, how about something like this? If GCC was configured with a linker that supports @option{-z bndplt}, then this option is also passed when linking. It is supported in LD starting with version 2.25, but not in the Gold linker. You should pass @option{-z bndplt} on your link line explicitly if you are not certain how your GCC was configured. Without this option and appropriate linker support, all calls to dynamic libraries lose bounds checking information. If no linker support for @option{-z bndplt} is available, you should link with @option{-static} instead to avoid external calls to dynamic libraries. ...then add a paragraph break before "MPX-based instrumentation...." -Sandra
On 04/06/2015 11:14 AM, Sandra Loosemore wrote: > On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >> On 05 Apr 19:44, Sandra Loosemore wrote: >>> On 04/03/2015 01:34 PM, Joseph Myers wrote: >>>> On Tue, 31 Mar 2015, Ilya Enkovich wrote: >>>> >>>>> +library. It also passes '-z bndplt' to a linker in case it >>>>> supports this >>>>> +option (which is checked on libmpx configuration). Note that old >>>>> versions >>>>> +of linker may ignore option. Gold linker doesn't support '-z bndplt' >>>>> +option. With no '-z bndplt' support in linker all calls to >>>>> dynamic libraries >>>>> +lose passed bounds reducing overall protection level. It's highly >>>>> +recommended to use linker with '-z bndplt' support. In case such >>>>> linker >>>>> +is not available it is adviced to always use >>>>> @option{-static-libmpxwrappers} >>>>> +for better protection level or use @option{-static} to completely >>>>> avoid >>>>> +external calls to dynamic libraries. MPX-based instrumentation >>>> >>>> Use @samp{-z bndplt} rather than '' quoting (but Sandra may have >>>> further >>>> advice on the substance of this documentation). >>> >>> To tell the truth, I can't figure out what this means from a user >>> perspective. How does a user know whether the linker option is >>> being ignored, or if they have a new enough linker? If the linker >>> available at configuration time doesn't support the option, does >>> that mean the option will never be passed and users will never know >>> that there are gaping holes in the pointer bounds checking? >>> >>> My suggestion would be to pass the option unconditionally and make >>> the documentation say something like >> >> This option was rejected. > > Hrmmmm, how about then just *never* passing the magic option to the > linker, and telling users they either have to pass it manually (and use > a linker that supports it), use static linking, or do without bounds > checking on dynamic libraries? > > Remember that most GCC users do not configure GCC themselves... they > use whatever came with their distro or from their toolchain vendor, or > was installed by their sysadmin. So most GCC users have no way to know > what linker their GCC binary was configured with and it's just confusing > that this important linker option might or might not be included based > on factors they don't know about or can't control. But the same arguments apply to forcing the user to manually pass the argument, select static linking, etc. If I think about the most common case usage, it's going to be a compiler/binutils pair built by a distribution such as Fedora, Ubuntu, etc and the configure time test will do the right thing. It's only cases where folks are updating components separately, or building themselves that the configure time test falls down. Jeff
On Tue, Apr 7, 2015 at 12:01 PM, Jeff Law <law@redhat.com> wrote: > On 04/06/2015 11:14 AM, Sandra Loosemore wrote: >> >> On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >>> >>> On 05 Apr 19:44, Sandra Loosemore wrote: >>>> >>>> On 04/03/2015 01:34 PM, Joseph Myers wrote: >>>>> >>>>> On Tue, 31 Mar 2015, Ilya Enkovich wrote: >>>>> >>>>>> +library. It also passes '-z bndplt' to a linker in case it >>>>>> supports this >>>>>> +option (which is checked on libmpx configuration). Note that old >>>>>> versions >>>>>> +of linker may ignore option. Gold linker doesn't support '-z bndplt' >>>>>> +option. With no '-z bndplt' support in linker all calls to >>>>>> dynamic libraries >>>>>> +lose passed bounds reducing overall protection level. It's highly >>>>>> +recommended to use linker with '-z bndplt' support. In case such >>>>>> linker >>>>>> +is not available it is adviced to always use >>>>>> @option{-static-libmpxwrappers} >>>>>> +for better protection level or use @option{-static} to completely >>>>>> avoid >>>>>> +external calls to dynamic libraries. MPX-based instrumentation >>>>> >>>>> >>>>> Use @samp{-z bndplt} rather than '' quoting (but Sandra may have >>>>> further >>>>> advice on the substance of this documentation). >>>> >>>> >>>> To tell the truth, I can't figure out what this means from a user >>>> perspective. How does a user know whether the linker option is >>>> being ignored, or if they have a new enough linker? If the linker >>>> available at configuration time doesn't support the option, does >>>> that mean the option will never be passed and users will never know >>>> that there are gaping holes in the pointer bounds checking? >>>> >>>> My suggestion would be to pass the option unconditionally and make >>>> the documentation say something like >>> >>> >>> This option was rejected. >> >> >> Hrmmmm, how about then just *never* passing the magic option to the >> linker, and telling users they either have to pass it manually (and use >> a linker that supports it), use static linking, or do without bounds >> checking on dynamic libraries? >> >> Remember that most GCC users do not configure GCC themselves... they >> use whatever came with their distro or from their toolchain vendor, or >> was installed by their sysadmin. So most GCC users have no way to know >> what linker their GCC binary was configured with and it's just confusing >> that this important linker option might or might not be included based >> on factors they don't know about or can't control. > > But the same arguments apply to forcing the user to manually pass the > argument, select static linking, etc. > > If I think about the most common case usage, it's going to be a > compiler/binutils pair built by a distribution such as Fedora, Ubuntu, etc > and the configure time test will do the right thing. It's only cases where > folks are updating components separately, or building themselves that the > configure time test falls down. You can't have it both ways. If the common usage is targeting distributions, -z bndplt should always be passed to ld for MPX since distributions should have the proper linker for MPX.
On 2015.04.07 at 12:28 -0700, H.J. Lu wrote: > You can't have it both ways. If the common usage is targeting > distributions, -z bndplt should always be passed to ld for MPX > since distributions should have the proper linker for MPX. Why don't you just implement -z bndplt for gold?
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index c058710..72b9578 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -5858,12 +5858,12 @@ a runtime library to enable MPX in hardware and handle bounds violation signals. By default when @option{-fcheck-pointer-bounds} and @option{-mmpx} options are used to link a program, the GCC driver links against the @file{libmpx} runtime library and @file{libmpxwrappers} -library. It also passes '-z bndplt' to a linker in case it supports this -option (which is checked on libmpx configuration). Note that old versions -of linker may ignore option. Gold linker doesn't support '-z bndplt' -option. With no '-z bndplt' support in linker all calls to dynamic libraries -lose passed bounds reducing overall protection level. It's highly -recommended to use linker with '-z bndplt' support. In case such linker +library. It also passes @option{-z bndplt} to a linker in case it supports +this option (which is checked on libmpx configuration). LD supports it starting +from version 2.25. Gold linker doesn't support @option{-z bndplt} +option. With no @option{-z bndplt} support in a linker all calls to dynamic +libraries lose passed bounds reducing overall protection level. It's highly +recommended to use linker with @option{-z bndplt} support. In case such linker is not available it is adviced to always use @option{-static-libmpxwrappers} for better protection level or use @option{-static} to completely avoid external calls to dynamic libraries. MPX-based instrumentation