This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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] |
On 01/05/2018 12:08 AM, Cary Coutant wrote:
* options.h (retpolineplt): New -z option to use retpoline PLT. * x86_64.cc (Output_data_plt_x86_64_retpoline): New class. (Target_x86_64<64>::do_make_data_plt): Create retpoline PLT when the option is used. * testsuite/Makefile.am (retpoline_plt_1.sh): New test. * testsuite/Makefile.in: Regenerate. * testsuite/retpoline_plt_1.sh: New test script. * testsuite/retpoline_plt_1.s: New test source.This makes the -z bndplt and -z retpolineplt options mutually exclusive. Please add a check in options.cc (General_options::finalize) for this.
It's also incompatible with shadow stack support, so the binary marker for that needs to be removed.
I don't think this is the right approach at all. What is this trying to accomplish? What kind of speculation barrier does this implement on current CPUs? Isn't this *extremely* costly?
If we think this is a problem that needs to be fixed, we should remove the indirect call altogether, and have the dynamic linker generate a direct call at load time. There are few constraints associated with that (4 GiB total application + DSO size, some SELinux users will unhappy, lack of lazy binding support), but at least it can be turned on in practice.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |