From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Smith Date: Fri, 23 Mar 2018 17:55:49 +0000 Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Message-Id: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> List-Id: References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Matthew Wilcox Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, Andrew Morton , steve.capper@arm.com, punit.agrawal@arm.com, aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com, Kees Cook , bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com, "Kirill A. Shutemov" , Dan Williams , Jan Kara , ross.zwisler@linux.intel.com, Jerome Glisse , Andrea Arcangeli , Oleg Nesterov , linux-alpha@vger.kernel.org, LKML , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linux-MM > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. > > Why should this be done in the kernel rather than libc? libc is perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random ‘hint’ address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn’t give that much security like randomization address inside kernel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Smith Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Date: Fri, 23 Mar 2018 20:55:49 +0300 Message-ID: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Type: text/plain; charset=utf-8 Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, Andrew Morton , steve.capper@arm.com, punit.agrawal@arm.com, To: Matthew Wilcox Return-path: In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> List-ID: List-Id: linux-parisc.vger.kernel.org > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: >=20 > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. >=20 > Why should this be done in the kernel rather than libc? libc is = perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible = IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random =E2=80=98hint=E2=80=99 address, = but kernel may discard this address if it is occupied for example and allocate just = before closest vma. So this solution doesn=E2=80=99t give that much security = like=20 randomization address inside kernel.= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1521827752; cv=none; d=google.com; s=arc-20160816; b=U6gFmjYKAYYBn4nMDqbvYGR43l/F/65lya4QhJewm5ZvSuPYk9ETd8et0plH7Y7XJJ s4wNBBFzMtM9nrx2K8q5rRNJ7h2IspTcwxPGupSSkzq4GZttRcOoeZKrCcVJptP5ZePG Eluzf4IZc/Vw+qQQEG3CRb8aq3oFW/7n4dKv3DJLOGtc9qSiYP7Fpvqyn9sI5XheTvAa DlR8VPLBeCWEs3CAgkjqKE219lIo83eEodE9glrxY06GjclWqdfVW2GfFsiv+ISnKjOP q8BOwkJmnx9wu95rl9JzZpY9k8v7iWPwRyvii73/FhKPepC/63paYUdqSuCCbqU0O3eq oAjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:dkim-signature :arc-authentication-results; bh=Nn/LegfdgCnPMfgxrP8ldElW5x41AbmrS9XnJZIcO0M=; b=LWmtTWdQvzW0UsuMc06qAAb6CHb3ELLCGt4KVK6jOtc64IXdwurw7Yflvhun1gtLu0 DkvALCQM146HBUEeuMDIRlJti/vWewwFC1WiQU8TGM8jU1MTy68/PwDPs6mEc1x/JHBR sddD9zLV4AvSy8eaEbp1sUUTSAeKPOy9FCWmhW/R8XeavfOZJLuNz9sxmt2t8Ym1xSmV n0SswJP6iaAwm9X+sXDLTibVTX5+H5XASAvXlst1xJreZwJgZpkobEOY2iYdDESj38mI EIE+R9Zeo9JMIHiU+KksUDOlwTRk3be3QUTHAZwE/Yagyk3jaFot0t747axfxynGk/Mr nZGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dmuwuz6Z; spf=pass (google.com: domain of blackzert@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=blackzert@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dmuwuz6Z; spf=pass (google.com: domain of blackzert@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=blackzert@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com X-Google-Smtp-Source: AG47ELvfGoHwG8ZFUTfHtGgnMEMhX5286YUod0rhOtxN+bKDVeOxka7156ZLffopag3GbBdCfb+X5Q== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. From: Ilya Smith In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> Date: Fri, 23 Mar 2018 20:55:49 +0300 Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, Andrew Morton , steve.capper@arm.com, punit.agrawal@arm.com, aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com, Kees Cook , bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com, "Kirill A. Shutemov" , Dan Williams , Jan Kara , ross.zwisler@linux.intel.com, Jerome Glisse , Andrea Arcangeli , Oleg Nesterov , linux-alpha@vger.kernel.org, LKML , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linux-MM Content-Transfer-Encoding: quoted-printable Message-Id: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> To: Matthew Wilcox X-Mailer: Apple Mail (2.3445.5.20) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1595656488556903336?= X-GMAIL-MSGID: =?utf-8?q?1595752056978107135?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: >=20 > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. >=20 > Why should this be done in the kernel rather than libc? libc is = perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible = IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random =E2=80=98hint=E2=80=99 address, = but kernel may discard this address if it is occupied for example and allocate just = before closest vma. So this solution doesn=E2=80=99t give that much security = like=20 randomization address inside kernel.= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 407B6M0gbdzF0wy for ; Sat, 24 Mar 2018 04:55:54 +1100 (AEDT) Received: by mail-lf0-x243.google.com with SMTP id o102-v6so19500470lfg.8 for ; Fri, 23 Mar 2018 10:55:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. From: Ilya Smith In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> Date: Fri, 23 Mar 2018 20:55:49 +0300 Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, Andrew Morton , steve.capper@arm.com, punit.agrawal@arm.com, aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com, Kees Cook , bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com, "Kirill A. Shutemov" , Dan Williams , Jan Kara , ross.zwisler@linux.intel.com, Jerome Glisse , Andrea Arcangeli , Oleg Nesterov , linux-alpha@vger.kernel.org, LKML , linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linux-MM Message-Id: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> To: Matthew Wilcox List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: >=20 > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. >=20 > Why should this be done in the kernel rather than libc? libc is = perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible = IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random =E2=80=98hint=E2=80=99 address, = but kernel may discard this address if it is occupied for example and allocate just = before closest vma. So this solution doesn=E2=80=99t give that much security = like=20 randomization address inside kernel.= From mboxrd@z Thu Jan 1 00:00:00 1970 From: blackzert@gmail.com (Ilya Smith) Date: Fri, 23 Mar 2018 20:55:49 +0300 Subject: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> List-ID: Message-ID: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> To: linux-snps-arc@lists.infradead.org > On 23 Mar 2018,@15:48, Matthew Wilcox wrote: > > On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. > > Why should this be done in the kernel rather than libc? libc is perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random ?hint? address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn?t give that much security like randomization address inside kernel. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Smith Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap. Date: Fri, 23 Mar 2018 20:55:49 +0300 Message-ID: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com> References: <1521736598-12812-1-git-send-email-blackzert@gmail.com> <20180323124806.GA5624@bombadil.infradead.org> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nn/LegfdgCnPMfgxrP8ldElW5x41AbmrS9XnJZIcO0M=; b=dmuwuz6Z424tcCQofiCkpe7cXUJw3+yS9d8dSuF6KIrQ3AS98qcM3znkAh+yQ8N861 DQUFRDwaQ8zsA9zfeG1lYzBYGpXJi8Q50XApUrKoNifIvTjyQXebt0GhEeFeh8udWnN1 SaV+sgwIzdJcB/Q+xKm4AeFiWecFUaKndxiCasm/VGFuPIpnt4oIuMGZ2lfUg8gMc7EF TLbBhWhnBsA501jUsXGVCUu1Ta1OuIi+DgH6N9txRSK0LYwrDOwwO4wBeB3FY9sG34Ee y4n5+NevXgWYxnIIpB+Zzgls02Nrk6ePhuN+gOhnMpVoienq2TVmDFk/zgtFS2MEb0+f QLog== In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: Matthew Wilcox Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org, Helge Deller , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org, deepa.kernel@gmail.com, Michal Hocko , Hugh Dickins , kstewart@linuxfoundation.org, pombredanne@nexb.com, Andrew Morton , steve.capper@arm.com, punit.agrawal@arm.com > On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: >=20 > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: >> Current implementation doesn't randomize address returned by mmap. >> All the entropy ends with choosing mmap_base_addr at the process >> creation. After that mmap build very predictable layout of address >> space. It allows to bypass ASLR in many cases. This patch make >> randomization of address on any mmap call. >=20 > Why should this be done in the kernel rather than libc? libc is = perfectly > capable of specifying random numbers in the first argument of mmap. Well, there is following reasons: 1. It should be done in any libc implementation, what is not possible = IMO; 2. User mode is not that layer which should be responsible for choosing random address or handling entropy; 3. Memory fragmentation is unpredictable in this case Off course user mode could use random =E2=80=98hint=E2=80=99 address, = but kernel may discard this address if it is occupied for example and allocate just = before closest vma. So this solution doesn=E2=80=99t give that much security = like=20 randomization address inside kernel.=