Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934302AbdDGQUw convert rfc822-to-8bit (ORCPT ); Fri, 7 Apr 2017 12:20:52 -0400 Received: from terminus.zytor.com ([65.50.211.136]:54005 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933588AbdDGQUn (ORCPT ); Fri, 7 Apr 2017 12:20:43 -0400 Date: Fri, 07 Apr 2017 09:09:27 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20170407155945.7lyapjbwacg3ikw6@node.shutemov.name> References: <20170406140106.78087-1-kirill.shutemov@linux.intel.com> <20170406140106.78087-9-kirill.shutemov@linux.intel.com> <8d68093b-670a-7d7e-2216-bf64b19c7a48@linux.vnet.ibm.com> <20170407155945.7lyapjbwacg3ikw6@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits To: "Kirill A. Shutemov" , Anshuman Khandual CC: "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dmitry Safonov From: hpa@zytor.com Message-ID: <2A1F4E56-9374-4C41-876C-6E6CBD16DB22@zytor.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2407 Lines: 57 On April 7, 2017 8:59:45 AM PDT, "Kirill A. Shutemov" wrote: >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. > >Yes, you can gain something in security by having more bits for ASLR, >but >I don't think it worth the cost. > >> Will those JIT compilers keep using the higher bit positions of >> the pointer for ever ? Then it will limit the ability of the >> kernel to expand the virtual address range later as well. I am >> not saying we should not increase till the extent it does not >> affect any *known* user but then we should not increase twice >> for now, create the hint mechanism to be passed from the user >> to avail beyond that (which will settle in as a expectation >> from the kernel later on). Do the same thing again while >> 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. You realize that people have said that about just about every memory threshold from 64K onward? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.