From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753781AbdKHGIY (ORCPT ); Wed, 8 Nov 2017 01:08:24 -0500 Received: from ozlabs.org ([103.22.144.67]:35465 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750953AbdKHGIX (ORCPT ); Wed, 8 Nov 2017 01:08:23 -0500 From: Michael Ellerman To: "Kirill A. Shutemov" , Florian Weimer , Kees Cook Cc: linux-arch@vger.kernel.org, Dave Hansen , Peter Zijlstra , Linus Torvalds , Ingo Molnar , Linux Kernel Mailing List , Nicholas Piggin , Andy Lutomirski , linux-mm , "Aneesh Kumar K.V" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , "Kirill A. Shutemov" Subject: Re: POWER: Unexpected fault when writing to brk-allocated memory In-Reply-To: <20171107131616.342goolaujjsnjge@node.shutemov.name> References: <20171106174707.19f6c495@roar.ozlabs.ibm.com> <24b93038-76f7-33df-d02e-facb0ce61cd2@redhat.com> <20171106192524.12ea3187@roar.ozlabs.ibm.com> <546d4155-5b7c-6dba-b642-29c103e336bc@redhat.com> <20171107160705.059e0c2b@roar.ozlabs.ibm.com> <20171107111543.ep57evfxxbwwlhdh@node.shutemov.name> <20171107114422.bgnm5k6w2zqjoazc@node.shutemov.name> <7fc1641b-361c-2ee2-c510-f7c64d173bf8@redhat.com> <20171107131616.342goolaujjsnjge@node.shutemov.name> Date: Wed, 08 Nov 2017 17:08:20 +1100 Message-ID: <87vail2tgr.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Kirill A. Shutemov" writes: > On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: >> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: >> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: >> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: >> > > >> > > > > First of all, using addr and MAP_FIXED to develop our heuristic can >> > > > > never really give unchanged ABI. It's an in-band signal. brk() is a >> > > > > good example that steadily keeps incrementing address, so depending >> > > > > on malloc usage and address space randomization, you will get a brk() >> > > > > that ends exactly at 128T, then the next one will be > >> > > > > DEFAULT_MAP_WINDOW, and it will switch you to 56 bit address space. >> > > > >> > > > No, it won't. You will hit stack first. >> > > >> > > That's not actually true on POWER in some cases. See the process maps I >> > > posted here: >> > > >> > > >> > >> > Hm? I see that in all three cases the [stack] is the last mapping. >> > Do I miss something? >> >> Hah, I had not noticed. Occasionally, the order of heap and stack is >> reversed. This happens in approximately 15% of the runs. > > Heh. I guess ASLR on Power is too fancy :) Fancy implies we're doing it on purpose :P > That's strange layout. It doesn't give that much (relatively speaking) > virtual address space for both stack and heap to grow. I'm pretty sure it only happens when you're running an ELF interpreter directly, because of Kees patch which changed the logic to load ELF interpreters in the mmap region, vs PIE binaries which go to ELF_ET_DYN_BASE. (eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")) It only happens with ASLR enabled. Presumably it's because our brk_rnd() is overly aggressive in this case, it randomises up to 1GB, and the heap jumps over the stack. cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 7C06E4403E0 for ; Wed, 8 Nov 2017 01:08:27 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id r18so1650633pgu.9 for ; Tue, 07 Nov 2017 22:08:27 -0800 (PST) Received: from ozlabs.org (ozlabs.org. [2401:3900:2:1::2]) by mx.google.com with ESMTPS id m17si3129430pfh.214.2017.11.07.22.08.25 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Nov 2017 22:08:25 -0800 (PST) From: Michael Ellerman Subject: Re: POWER: Unexpected fault when writing to brk-allocated memory In-Reply-To: <20171107131616.342goolaujjsnjge@node.shutemov.name> References: <20171106174707.19f6c495@roar.ozlabs.ibm.com> <24b93038-76f7-33df-d02e-facb0ce61cd2@redhat.com> <20171106192524.12ea3187@roar.ozlabs.ibm.com> <546d4155-5b7c-6dba-b642-29c103e336bc@redhat.com> <20171107160705.059e0c2b@roar.ozlabs.ibm.com> <20171107111543.ep57evfxxbwwlhdh@node.shutemov.name> <20171107114422.bgnm5k6w2zqjoazc@node.shutemov.name> <7fc1641b-361c-2ee2-c510-f7c64d173bf8@redhat.com> <20171107131616.342goolaujjsnjge@node.shutemov.name> Date: Wed, 08 Nov 2017 17:08:20 +1100 Message-ID: <87vail2tgr.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: "Kirill A. Shutemov" , Florian Weimer , Kees Cook Cc: linux-arch@vger.kernel.org, Dave Hansen , Peter Zijlstra , Linus Torvalds , Ingo Molnar , Linux Kernel Mailing List , Nicholas Piggin , Andy Lutomirski , linux-mm , "Aneesh Kumar K.V" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , "Kirill A. Shutemov" "Kirill A. Shutemov" writes: > On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: >> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: >> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: >> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: >> > > >> > > > > First of all, using addr and MAP_FIXED to develop our heuristic can >> > > > > never really give unchanged ABI. It's an in-band signal. brk() is a >> > > > > good example that steadily keeps incrementing address, so depending >> > > > > on malloc usage and address space randomization, you will get a brk() >> > > > > that ends exactly at 128T, then the next one will be > >> > > > > DEFAULT_MAP_WINDOW, and it will switch you to 56 bit address space. >> > > > >> > > > No, it won't. You will hit stack first. >> > > >> > > That's not actually true on POWER in some cases. See the process maps I >> > > posted here: >> > > >> > > >> > >> > Hm? I see that in all three cases the [stack] is the last mapping. >> > Do I miss something? >> >> Hah, I had not noticed. Occasionally, the order of heap and stack is >> reversed. This happens in approximately 15% of the runs. > > Heh. I guess ASLR on Power is too fancy :) Fancy implies we're doing it on purpose :P > That's strange layout. It doesn't give that much (relatively speaking) > virtual address space for both stack and heap to grow. I'm pretty sure it only happens when you're running an ELF interpreter directly, because of Kees patch which changed the logic to load ELF interpreters in the mmap region, vs PIE binaries which go to ELF_ET_DYN_BASE. (eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")) It only happens with ASLR enabled. Presumably it's because our brk_rnd() is overly aggressive in this case, it randomises up to 1GB, and the heap jumps over the stack. cheers -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (bilbo.ozlabs.org [103.22.144.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yWwpF5BLVzDr62 for ; Wed, 8 Nov 2017 17:08:21 +1100 (AEDT) From: Michael Ellerman To: "Kirill A. Shutemov" , Florian Weimer , Kees Cook Cc: linux-arch@vger.kernel.org, Dave Hansen , Peter Zijlstra , Linus Torvalds , Ingo Molnar , Linux Kernel Mailing List , Nicholas Piggin , Andy Lutomirski , linux-mm , "Aneesh Kumar K.V" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , "Kirill A. Shutemov" Subject: Re: POWER: Unexpected fault when writing to brk-allocated memory In-Reply-To: <20171107131616.342goolaujjsnjge@node.shutemov.name> References: <20171106174707.19f6c495@roar.ozlabs.ibm.com> <24b93038-76f7-33df-d02e-facb0ce61cd2@redhat.com> <20171106192524.12ea3187@roar.ozlabs.ibm.com> <546d4155-5b7c-6dba-b642-29c103e336bc@redhat.com> <20171107160705.059e0c2b@roar.ozlabs.ibm.com> <20171107111543.ep57evfxxbwwlhdh@node.shutemov.name> <20171107114422.bgnm5k6w2zqjoazc@node.shutemov.name> <7fc1641b-361c-2ee2-c510-f7c64d173bf8@redhat.com> <20171107131616.342goolaujjsnjge@node.shutemov.name> Date: Wed, 08 Nov 2017 17:08:20 +1100 Message-ID: <87vail2tgr.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , "Kirill A. Shutemov" writes: > On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: >> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: >> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: >> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: >> > > >> > > > > First of all, using addr and MAP_FIXED to develop our heuristic can >> > > > > never really give unchanged ABI. It's an in-band signal. brk() is a >> > > > > good example that steadily keeps incrementing address, so depending >> > > > > on malloc usage and address space randomization, you will get a brk() >> > > > > that ends exactly at 128T, then the next one will be > >> > > > > DEFAULT_MAP_WINDOW, and it will switch you to 56 bit address space. >> > > > >> > > > No, it won't. You will hit stack first. >> > > >> > > That's not actually true on POWER in some cases. See the process maps I >> > > posted here: >> > > >> > > >> > >> > Hm? I see that in all three cases the [stack] is the last mapping. >> > Do I miss something? >> >> Hah, I had not noticed. Occasionally, the order of heap and stack is >> reversed. This happens in approximately 15% of the runs. > > Heh. I guess ASLR on Power is too fancy :) Fancy implies we're doing it on purpose :P > That's strange layout. It doesn't give that much (relatively speaking) > virtual address space for both stack and heap to grow. I'm pretty sure it only happens when you're running an ELF interpreter directly, because of Kees patch which changed the logic to load ELF interpreters in the mmap region, vs PIE binaries which go to ELF_ET_DYN_BASE. (eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")) It only happens with ASLR enabled. Presumably it's because our brk_rnd() is overly aggressive in this case, it randomises up to 1GB, and the heap jumps over the stack. cheers