Home Original page

[PATCH 0/6] ld: Add "-z textonly" option to ELF linker

Alan Modra amodra@gmail.com
Tue Jan 9 23:10:00 GMT 2018 
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 <amodra@gmail.com> 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 <matz@suse.de> 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
-z separate-code.

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
2.27?

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
PF_X segment).

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.

-- 
Alan Modra
Australia Development Lab, IBM
More information about the Binutils mailing list