On 20 September 2017 at 23:13, John Reiser <jrei...@bitwagon.com> wrote: > Now that I know the nature of the conflict, then I will spend a > handful of instructions to avoid [0xf7000000, +), and also the > stack if it gets placed immediately below that.
Cool. I figured out why -R 0xffff0000 didn't work and have sent a patch for that; rth has some patches he's going to respin and resend which will make -R 0xffff0000 the default and should help in the sense of avoiding the guest SIGSEGV. With your test binary and those fixes I now get it exiting early with "PROT_EXEC|PROT_WRITE failed", which seems to be because it does mmap2(0xffff0000,228092,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = -1 errno=22 which is trying to mmap off the end of the valid address space (as well as over the kernel commpage). I'm not sure how it's calculating the address to mmap, because it's different this time around. thanks -- PMM
