On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 01/05/2017 12:14 PM, Andy Lutomirski wrote: >>> I'm not sure I'm comfortable with this. Do other rlimit changes cause >>> silent data corruption? I'm pretty sure doing this to MPX would. >>> >> What actually goes wrong in this case? That is, what combination of >> MPX setup of subsequent allocations will cause a problem, and is the >> problem worse than just a segfault? IMO it would be really nice to >> keep the messy case confined to MPX. > > The MPX bounds tables are indexed by virtual address. They need to grow > if the virtual address space grows. There's an MSR that controls > whether we use the 48-bit or 57-bit layout. It basically decides > whether we need a 2GB (48-bit) or 1TB (57-bit) bounds directory. > > The question is what we do with legacy MPX applications. We obviously > can't let them just allocate a 2GB table and then go let the hardware > pretend it's 1TB in size. We also can't hand the hardware using a 2GB > table an address >48-bits. > > Ideally, I'd like to make sure that legacy MPX can't be enabled if this > RLIMIT is set over 48-bits (really 47). I'd also like to make sure that > legacy MPX is active, that the RLIMIT can't be raised because all hell > will break loose when the new addresses show up. > > Remember, we already have (legacy MPX) binaries in the wild that have no > knowledge of this stuff. So, we can implicitly have the kernel bump > this rlimit around, but we can't expect userspace to do it, ever. If you s/rlimit/prctl, then I think this all makes sense with one exception. It would be a bit sad if the personality-setting tool didn't work if compiled with MPX. So what if we had a second prctl field that is the value that kicks in after execve()? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
