This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX


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.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]