Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

["Kirill A. Shutemov" <kirill@shutemov.name>]

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@shutemov.name> 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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>