On Wed, Jan 11, 2017 at 10:09:17AM -0800, Andy Lutomirski wrote: > On Wed, Jan 11, 2017 at 6:29 AM, Kirill A. Shutemov > <kirill@xxxxxxxxxxxxx> wrote: > > On Thu, Jan 05, 2017 at 12:49:44PM -0800, Dave Hansen 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. > > > > I think we can do this. See the patch below. > > > > Basically, we refuse to enable MPX and issue warning in dmesg if there's > > anything mapped above 47-bits. Once MPX is enabled, mmap_max_addr() cannot > > be higher than 47-bits too. > > > > Function call from mmap_max_addr() is unfortunate, but I don't see a > > way around. > > How about preventing the max addr from being changed to too high a > value while MPX is on instead of overriding the set value? This would > have the added benefit that it would prevent silent failures where you > think you've enabled large addresses but MPX is also on and mmap > refuses to return large addresses. Setting rlimit high doesn't mean that you necessary will get access to full address space, even without MPX in picture. TASK_SIZE limits the available address space too. I think it's consistent with other resources in rlimit: setting RLIMIT_RSS to unlimited doesn't really means you are not subject to other resource management. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
