On Fri, Feb 2, 2018 at 12:40 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 01-02-18 14:10:07, Michal Hocko wrote: > Thanks a lot to Michael Matz for his background. He has pointed me to > the following two segments from your binary[1] > LOAD 0x0000000000000000 0x0000000010000000 0x0000000010000000 > 0x0000000000013a8c 0x0000000000013a8c R E 10000 > LOAD 0x000000000001fd40 0x000000001002fd40 0x000000001002fd40 > 0x00000000000002c0 0x00000000000005e8 RW 10000 > LOAD 0x0000000000020328 0x0000000010030328 0x0000000010030328 > 0x0000000000000384 0x00000000000094a0 RW 10000 > > That binary has two RW LOAD segments, the first crosses a page border > into the second > 0x1002fd40 (LOAD2-vaddr) + 0x5e8 (LOAD2-memlen) == 0x10030328 (LOAD3-vaddr) > > He says > : This is actually an artifact of RELRO machinism. The first RW mapping > : will be remapped as RO after relocations are applied (to increase > : security). > : Well, to be honest, normal relro binaries also don't have more than > : two LOAD segments, so whatever RHEL did to their compilation options, > : it's something in addition to just relro (which can be detected by > : having a GNU_RELRO program header) > : But it definitely has something to do with relro, it's just not the > : whole story yet. > > I am still trying to wrap my head around all this, but it smells rather > dubious to map different segments over the same page. Is this something > that might happen widely and therefore MAP_FIXED_NOREPLACE is a no-go > when loading ELF segments? Or is this a special case we can detect? Eww. FWIW, I would expect that to be rare and detectable. -Kees -- Kees Cook Pixel Security
