On Mon, Jan 29, 2018 at 3:51 PM, Nadav Har'El <n...@scylladb.com> wrote:
> > 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 have a feeling - though I am really rusty on the details - that we're indeed doing something wrong here (and above we can see the evidence that something is wrong - an address outside the GNU_RELRO area was made read-only). https://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-March/007647.html explains (though I didn't fully understand...) how although the RELRO addresses look like they are not page aligned, they actually are. But if I add printouts in fix_permissions() I see information like start 0x216d68 (not page aligned!) sz 0x298, and then we "align" those to vstart 0x216000 memsz 0x1000 but when doing that, we make too much memory read-only! I have a vague feeling that fix_permissions() cannot just work on the whole object it needs to know which of the PT_LOAD segments (see file::load_segment()) the RELRO falls in, but I'm hazy on the details. Maybe even file::load_segment() maps the segment with the wrong alignment? But unfortunately, I cannot even reproduce the problem you are seeing (even though I do have gcc 7.2.1), let alone fix it. > > 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.
