This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 0/6] ld: Add "-z textonly" option to ELF linker
On Tue, Jan 09, 2018 at 09:39:04AM -0800, H.J. Lu wrote:
> On Tue, Jan 9, 2018 at 5:21 AM, Alan Modra <firstname.lastname@example.org> wrote:
> > On Mon, Jan 08, 2018 at 08:10:53AM -0800, H.J. Lu wrote:
> >> On Mon, Jan 8, 2018 at 7:26 AM, Michael Matz <email@example.com> wrote:
> >> > supposed to mean? :) -z separate-text-segment perhaps?
> >> -z codeonly -or z insnonly?
> > -z separate-code perhaps?
> Done. I updated to -z separate-code on users/hjl/pr22393 branch.
> > Regarding the implementation, I'm wondering why you didn't implement
> > the vma adjustments entirely in the new linker scripts. It seems like
> > this ought to be possible.
> It may be doable without RELRO. My current approach is built on top
> of RELRO.
Yes, that's what I don't like about the current implementation. In
practice users will likely want both turned on, but that fact
shouldn't affect the design. From a high level perspective, -z relro
and -z separate-code are two different and independent concepts, with
-z relro being more complicated. So it would be nicer if the relro
machinery wasn't made more complicated than it is now by also handling
So let's talk about the design.
For -z separate-code you do need to start with a PF_R PT_LOAD segment,
for the ELF header. The header can't be PF_X since its data, if
interpreted as instructions might contain exploitable code. Initial
read-only sections like .interp will be placed into this segment too.
Next we'll have a PF_X PT_LOAD segment. This will start at a
-z common-page-size boundary, or if you want to save disk space *and*
you have support in ld.so to clear the beginning of the segment, at
the end of the previous segment plus one common-page-size. I don't
think we currently have glibc ld.so clearing the beginning of
segments.. I'm following your choice of common-page-size rather than
max-page-size because aligning to max-page-size will create large
binaries on disk. However, using a common-page-size alignment means
the resulting binary will not have effective separation of code from
data if the system page size is larger than common-page-size,
similarly to the way relro is ineffective under the same condition.
So that's the first questionable design decision. I strongly suspect
we should add max-page-size to the end of the previous segment, but
that means a glibc change is needed (I think). Can we make ld.so
clear out leading and trailing rubbish from PF_X segments for glibc
Next we have another PF_R PT_LOAD segment, for .rodata and other
read-only sections that normally are placed after .text. As before,
this segment needs to be aligned to a -z common-page-size boundary (or
you need glibc ld.so support for clearing the end of the previous
None of the above has any effect on the relro support.
> Maybe I missed something. Can you show me how to do
> it entirely in linker scripts?
It's more likely I'm missing something. :) Hmm, probably code in
elf.c packing sections to segments will need to know whether -z
separate-code is in effect, at least if we don't go for the
max-page-size vma adjustment.
Australia Development Lab, IBM