From mboxrd@z Thu Jan 1 00:00:00 1970 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hpa@zytor.com Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits Date: Fri, 07 Apr 2017 09:09:27 -0700 Message-ID: <2A1F4E56-9374-4C41-876C-6E6CBD16DB22@zytor.com> 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: quoted-printable Return-path: In-Reply-To: <20170407155945.7lyapjbwacg3ikw6@node.shutemov.name> Sender: owner-linux-mm@kvack.org 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 List-Id: linux-arch.vger.kernel.org On April 7, 2017 8:59:45 AM PDT, "Kirill A=2E Shutemov" wrote: >On Fri, Apr 07, 2017 at 07:05:26PM +0530, Anshuman Khandual wrote: >> On 04/06/2017 07:31 PM, Kirill A=2E Shutemov wrote: >> > On x86, 5-level paging enables 56-bit userspace virtual address >space=2E >> > Not all user space is ready to handle wide addresses=2E It's known >that >> > at least some JIT compilers use higher bits in pointers to encode >their >> > information=2E It collides with valid pointers with 5-level paging >and >> > leads to crashes=2E >> >=20 >> > To mitigate this, we are not going to allocate virtual address >space >> > above 47-bit by default=2E >>=20 >> 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=2E If that is the case then we need to have some plans when >> increasing it from the current level=2E > >I don't think we should ever enable full address space for all >applications=2E There's no point=2E > >/bin/true doesn't need more than 64TB of virtual memory=2E >And I hope never will=2E > >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=2E > >Yes, you can gain something in security by having more bits for ASLR, >but >I don't think it worth the cost=2E > >> 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=2E 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)=2E Do the same thing again while >> expanding the address range next time around=2E 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=2E > >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=2E You realize that people have said that about just about every memory thres= hold from 64K onward? --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E -- 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: email@kvack.org