This is the mail archive of the
mailing list for the binutils project.
Re: [GOLD][PATCH] Fix -z relro bugs
"Doug Kwan (éæå)" <email@example.com> writes:
> This patch fixes two problems related to the -z relro option. The
> first one is that .init_array, .fini_array and .preinit_array are not
> handle properly in Layout::make_output_seciton. The function only
> force the relro flag if section type if SHT_PROGBITS. The second
> problem is that the ARM backend ignores the -z now option. This patch
> fixes this problem and also places the .got section at the RELRO
> boundary. This is tested on both ARM and x86_64.
> 2012-03-15 Doug Kwan <firstname.lastname@example.org>
> * arm.cc (Target_arm::got_section): Make .got section read-only
> if -z now is given. Also place .got section at RELRO boundary.
> * layout.cc (Layout::make_output_section): Fix a bug that causes
> .init_array, .fini_array and .preinit_array to be not included
> in the RELRO segment when -z now is given.
(Please send to email@example.com, not
Coincidentally somebody reported the layout.cc change thing as a PR and
I fixed it this morning.
> + // When using -z now, we can treat .got as a relro section.
> + // Without -z now, it is modified after program startup by lazy
> + // PLT relocations.
> + bool is_got_relro = parameters->options().now();
> + Output_section_order got_order = (is_got_relro
> + ? ORDER_RELRO_LAST
> + : ORDER_NON_RELRO_FIRST);
As far as I can see this hsould be ORDER_DATA rather than
ORDER_NON_RELRO_FIRST. The x86 support uses ORDER_NON_RELRO_FIRST
because it calls layout->increase_relro. If you don't use that, you
might as well use ORDER_DATA. Unless there is some other reason that
the section should be first, but what?
This patch is OK using ORDER_DATA, or with ORDER_NON_RELRO_FIRST if
there is a reason for it.