This is the mail archive of the
binutils@sourceware.org
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 <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