On Wed, Apr 12, 2017 at 08:41:29PM +1000, Michael Ellerman wrote: > Hi Kirill, > > I'm interested in this because we're doing pretty much the same thing on > powerpc at the moment, and I want to make sure x86 & powerpc end up with > compatible behaviour. > > "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes: > > On Fri, Apr 07, 2017 at 07:05:26PM +0530, Anshuman Khandual wrote: > >> On 04/06/2017 07:31 PM, Kirill A. Shutemov wrote: > >> > On x86, 5-level paging enables 56-bit userspace virtual address space. > >> > Not all user space is ready to handle wide addresses. It's known that > >> > at least some JIT compilers use higher bits in pointers to encode their > >> > information. It collides with valid pointers with 5-level paging and > >> > leads to crashes. > >> > > >> > To mitigate this, we are not going to allocate virtual address space > >> > above 47-bit by default. > >> > >> I am wondering if the commitment of virtual space range to the > >> user space is kind of an API which needs to be maintained there > >> after. If that is the case then we need to have some plans when > >> increasing it from the current level. > > > > I don't think we should ever enable full address space for all > > applications. There's no point. > > > > /bin/true doesn't need more than 64TB of virtual memory. > > And I hope never will. > > > > By increasing virtual address space for everybody we will pay (assuming > > current page table format) at least one extra page per process for moving > > stack at very end of address space. > > That assumes the current layout though, it could be different. True. > > Yes, you can gain something in security by having more bits for ASLR, but > > I don't think it worth the cost. > > It may not be worth the cost now, for you, but that trade off will be > different for other people and at other times. > > So I think it's quite likely some folks will be interested in the full > address range for ASLR. We always can extend interface if/when userspace demand materialize. Let's not invent interfaces unless we're sure there's demand. > >> expanding the address range next time around. I think we need > >> to have a plan for this and particularly around 'hint' mechanism > >> and whether it should be decided per mmap() request or at the > >> task level. > > > > I think the reasonable way for an application to claim it's 63-bit clean > > is to make allocations with (void *)-1 as hint address. > > I do like the simplicity of that. > > But I wouldn't be surprised if some (crappy) code out there already > passes an address of -1. Probably it won't break if it starts getting > high addresses, but who knows. To make an application break we need two thing: - it sets hint address to -1 by mistake; - it uses upper bit to encode its info; I would be surprise if such combination exists in real world. But let me know if you have any particular code in mind. > An alternative would be to only interpret the hint as requesting a large > address if it's >= 64TB && < TASK_SIZE_MAX. Nope. That doesn't work if you take into accounting further extension of the address space. Consider extension x86 to 6-level page tables. User-space has 63-bit address space. TASK_SIZE_MAX is bumped to (1UL << 63) - PAGE_SIZE. An application wants access to full address space. It gets recompiled using new TASK_SIZE_MAX as hint address. And everything works fine. But only on machine with 6-level paging enabled. If we run the same application binary on machine with older kernel and 5-level paging, the application will get access to only 47-bit address space, not 56-bit, as hint address is more than TASK_SIZE_MAX in this configuration. > If we're really worried about breaking userspace then a new MMAP flag > seems like the safest option? > > I don't feel particularly strongly about any option, but like I said my > main concern is that x86 & powerpc end up with the same behaviour. > > And whatever we end up with someone will need to do an update to the man > page for mmap. Sure. -- Kirill A. Shutemov
