Re: bugs in page colouring code

[Ralf Baechle]

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.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/