[lkml]   [2012]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: bugs in page colouring code
    On Thu, Jun 14, 2012 at 03:20:07PM +0200, Borislav Petkov wrote:

    > > However, I expect that on x86 many applications expect
    > > MAP_FIXED to just work, and enforcing that would be
    > > more trouble than it's worth.
    > Right, but if MAP_FIXED mappings succeed, then all processes sharing
    > that mapping will have it at the same virtual address, correct? And
    > if so, then we don't have the aliasing issue either so MAP_FIXED is a
    > don't-care from that perspective.

    Once upon a time every real program carried its own malloc around. I'm
    sure many of these malloc implementations rely on MAP_FIXED.

    These days the big user of MAP_FIXED is glibc's dynamic loader. It
    doesn't use MAP_FIXED for the first segment, only for all subsequent
    segments and the addresses are chosen such this will succeed. ld(1)
    has the necessary knowledge about alignment.

    Problem: If you raise the alignment for mappings you want to make damn
    sure that any non-broken executable ever created uses sufficient alignment
    or bad things may happen.

    MIPS used to use a very large alignment in ld linker scripts allowing
    for up to 1MB page size. Then somebody clueless who shall smoulder in
    hell reduced it to a very small value, something like 4k or 16k. When
    we went for bigger page size (MIPS allows 64K page size) all binaries
    created with the broken linker had to be rebuilt.

    So you probably want to do a little dumpster diving in very old binutils
    before doing anything that raises alignment of file mappings.

    > > >Linus said that without this we are probably breaking old userspace
    > > >which can't stomach ASLR so we had to respect such userspace which
    > > >clears that flag.
    > >
    > > I wonder if that is true, since those userspace programs
    > > probably run fine on ARM, MIPS and other architectures...
    > Well, I'm too young to know that :) Reportedly, those were some obscure
    > old binaries and we added the PF_RANDOMIZE check out of caution, so as
    > to not break them, if at all.

    See above - ld linker scripts are a big part of why things are working :)
    I'm however not aware of any breakage caused by PF_RANDOMIZE.


     \ /
      Last update: 2012-06-14 17:01    [W:0.038 / U:20.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site