From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754074AbdDLLV0 (ORCPT ); Wed, 12 Apr 2017 07:21:26 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35049 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753920AbdDLLVW (ORCPT ); Wed, 12 Apr 2017 07:21:22 -0400 Date: Wed, 12 Apr 2017 14:11:57 +0300 From: "Kirill A. Shutemov" To: Michael Ellerman Cc: Anshuman Khandual , "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dmitry Safonov , "Aneesh Kumar K.V" Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits Message-ID: <20170412111157.h6tjryt7jbum4tfg@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> <87wpap6h7q.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wpap6h7q.fsf@concordia.ellerman.id.au> User-Agent: NeoMutt/20170306 (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirill A. Shutemov" Subject: Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits Date: Wed, 12 Apr 2017 14:11:57 +0300 Message-ID: <20170412111157.h6tjryt7jbum4tfg@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> <87wpap6h7q.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <87wpap6h7q.fsf@concordia.ellerman.id.au> Sender: owner-linux-mm@kvack.org To: Michael Ellerman Cc: Anshuman Khandual , "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dmitry Safonov , "Aneesh Kumar K.V" List-Id: linux-arch.vger.kernel.org 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" 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: email@kvack.org