On Mon, Jan 29, 2018 at 12:16 PM, Rick Payne <ri...@rossfell.co.uk> wrote:

>
> Maybe I'm not following. The GNU_RELO sections look the same between
> the 2 versions of erlexec. First one (-ubuntu17.10) fails, second one
> is fine:
>
> rickp@mo:~$ readelf --headers /usr/local/packages/OTP-20.0.5-OSv-
> ubuntu17.10/erts-9.0.5/bin/erlexec | grep -2 RELRO
>   GNU_STACK      0x0000000000000000 0x0000000000000000
> 0x0000000000000000
>                  0x0000000000000000 0x0000000000000000  RW     0x10
>   GNU_RELRO      0x000000000000ebe8 0x000000000020ebe8
> 0x000000000020ebe8
>                  0x0000000000000418 0x0000000000000418  R      0x1
>
> rickp@mo:~$ readelf --headers /usr/local/packages/OTP-20.0.5-OSv/erts-
> 9.0.5/bin/erlexec | grep -2 RELRO
>   GNU_STACK      0x0000000000000000 0x0000000000000000
> 0x0000000000000000
>                  0x0000000000000000 0x0000000000000000  RW     0x10
>   GNU_RELRO      0x000000000000ec08 0x000000000020ec08
> 0x000000000020ec08
>                  0x00000000000003f8 0x00000000000003f8  R      0x1
>
> > Only when "-z now" is used during linking (DT_BIND_NOW object flag)
> > do we do all the function lookups on startup (see
> > object::relocate_pltgot()) and then, it's ok that the .GOT.PLT is
> > also marked RELRO and made read-only.
> >
> > I'm *guessing* (with no evidence) that one of the following happened:
> > 1. Your compiler defaults to "full relro" (-Wl,-z,now -Wl,-z,relro)
> > but for some reason object::relocate_pltgot() doesn't recognize the
> > bind_now.
>
> So there is definitely a difference in the binaries. In the one that
> fails, getenv is defined like this, in the .rela.plt section:
>
> 00000020ee30  000100000007 R_X86_64_JUMP_SLO 0000000000000000 getenv@GL
> IBC_2.2.5 + 0
>

So this address,  00000020ee30, is beyond the end of the GNU_RELRO section,
0x000000000020ebe8
So it should NOT have been made read-only.

Maybe we're making a mistake with page alignments... When these addresses
are translated to memory addresses,
they need to be on different pages. Maybe we're doing something wrong?

I don't remember now how these offsets are translated to memory addresses,
we should review that code.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to