On Mon, Aug 7, 2017 at 11:51 AM, Evgenii Stepanov <eugenis@xxxxxxxxxx> wrote: > On Mon, Aug 7, 2017 at 11:40 AM, Kees Cook <keescook@xxxxxxxxxx> wrote: >> On Mon, Aug 7, 2017 at 11:36 AM, Evgenii Stepanov <eugenis@xxxxxxxxxx> wrote: >>> MSan is 64-bit only and does not allow any mappings _outside_ of these regions: >>> 000000000000 - 010000000000 app-1 >>> 510000000000 - 600000000000 app-2 >>> 700000000000 - 800000000000 app-3 >>> >>> https://github.com/google/sanitizers/issues/579 >>> >>> It sounds like the ELF_ET_DYN_BASE change should not break MSan. >> >> Hah, so the proposed move to 0x1000 8000 0000 for ASan would break >> MSan. Lovely! :P > > That's unfortunate. > This will not help existing binaries, but going forward the mapping > can be adjusted at runtime to anything like > 000000000000 .. A > 500000000000 + A .. 600000000000 > 700000000000 .. 800000000000 > i.e. we can look at where the binary is mapped and set A to anything > in the range of [0, 1000 0000 0000). That's still not compatible with > 0x1000 8000 0000 though. So A is considered to be < 0x1000 0000 0000? And a future MSan could handle a PIE base of 0x2000 0000 0000? If ASan an TSan can handle that too, then we could use that as the future PIE base. Existing systems will need some sort of reversion. The primary concerns with the CVEs fixed with the PIE base commit was for 32-bit. While it is possible to collide on 64-bit, it is much more rare. As long as we have no problems with the new 32-bit PIE base, we can revert the 64-bit base default back to 0x5555 5555 4000. -Kees -- Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>