From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751080AbcFXBLo (ORCPT ); Thu, 23 Jun 2016 21:11:44 -0400 Received: from outbound1.eu.mailhop.org ([52.28.251.132]:38945 "EHLO outbound1.eu.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbcFXBLl (ORCPT ); Thu, 23 Jun 2016 21:11:41 -0400 X-MHO-User: 96a85610-39a8-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 74.99.78.160 X-Mail-Handler: DuoCircle Outbound SMTP X-DKIM: OpenDKIM Filter v2.6.8 io 19F498002F Date: Fri, 24 Jun 2016 01:11:15 +0000 From: Jason Cooper To: Ard Biesheuvel Cc: Kees Cook , Thomas Garnier , "kernel-hardening@lists.openwall.com" , Ingo Molnar , Andy Lutomirski , "x86@kernel.org" , Borislav Petkov , Baoquan He , Yinghai Lu , Juergen Gross , Matt Fleming , Toshi Kani , Andrew Morton , Dan Williams , "Kirill A. Shutemov" , Dave Hansen , Xiao Guangrong , Martin Schwidefsky , "Aneesh Kumar K.V" , Alexander Kuleshov , Alexander Popov , Dave Young , Joerg Roedel , Lv Zheng , Mark Salter , Dmitry Vyukov , Stephen Smalley , Boris Ostrovsky , Christian Borntraeger , Jan Beulich , LKML , Jonathan Corbet , "linux-doc@vger.kernel.org" Subject: Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Message-ID: <20160624011115.GU9922@io.lakedaemon.net> References: <1466556426-32664-1-git-send-email-keescook@chromium.org> <20160622124707.GC9922@io.lakedaemon.net> <20160623193358.GL9922@io.lakedaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote: > On 23 June 2016 at 21:58, Kees Cook wrote: > > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: > >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: > >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier wrote: > >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: > >>> >> Hey Kees, > >>> >> > >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: > >>> >>> Notable problems that needed solving: > >>> >> ... > >>> >>> - Reasonable entropy is needed early at boot before get_random_bytes() > >>> >>> is available. > >>> >> > >>> >> This series is targetting x86, which typically has RDRAND/RDSEED > >>> >> instructions. Are you referring to other arches? Older x86? Also, > >>> >> isn't this the same requirement for base address KASLR? > >>> >> > >>> >> Don't get me wrong, I want more diverse entropy sources available > >>> >> earlier in the boot process as well. :-) I'm just wondering what's > >>> >> different about this series vs base address KASLR wrt early entropy > >>> >> sources. > >>> >> > >>> > > >>> > I think Kees was referring to the refactor I did to get the similar > >>> > entropy generation than KASLR module randomization. Our approach was > >>> > to provide best entropy possible even if you have an older processor > >>> > or under virtualization without support for these instructions. > >>> > Unfortunately common on companies with a large number of older > >>> > machines. > >>> > >>> Right, the memory offset KASLR uses the same routines as the kernel > >>> base KASLR. The issue is with older x86 systems, which continue to be > >>> very common. > >> > >> We have the same issue in embedded. :-( Compounded by the fact that > >> there is no rand instruction (at least not on ARM). So, even if there's > >> a HW-RNG, you can't access it until the driver is loaded. > >> > >> This is compounded by the fact that most systems deployed today have > >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c) > >> without dtb support at all. > >> > >> My current thinking is to add a devicetree property > >> "userspace,random-seed" . This way, existing, deployed > >> boards can append a dtb to a modern kernel with the property set. > >> The factory bootloader then only needs to amend its boot scripts to read > >> random-seed from the fs to the given address. > > > > The arm64 KASLR implementation has defined a way for boot loaders to > > pass in an seed similar to this. It might be nice to have a fall-back > > to a DT entry, though, then the bootloaders don't need to changed. > > > > Ard might have some thoughts on why DT wasn't used for KASLR (I assume > > the early parsing overhead, but I don't remember the discussion any > > more). > > > > On arm64, only DT is used for KASLR (even when booting via ACPI). My > first draft used register x1, but this turned out to be too much of a > hassle, since parsing the DT is also necessary to discover whether > there is a 'nokaslr' argument on the kernel command line. So the > current implementation only supports a single method, which is the > /chosen/kaslr-seed uint64 property. Ok, just to clarify (after a short offline chat), my goal is to set a userspace,random-seed property in the device tree once. The bootloader scripts would also only need to be altered once. Then, at each boot, the bootloader reads the entirety of /var/lib/misc/random-seed (512 bytes) into the configured address. random-seed could be in /boot, or on a flash partition. The decompressor would consume a small portion of that seed for kaslr and such. After that, the rest would be consumed by random.c to initialize the entropy pools. thx, Jason. From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Fri, 24 Jun 2016 01:11:15 +0000 From: Jason Cooper Message-ID: <20160624011115.GU9922@io.lakedaemon.net> References: <1466556426-32664-1-git-send-email-keescook@chromium.org> <20160622124707.GC9922@io.lakedaemon.net> <20160623193358.GL9922@io.lakedaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR To: Ard Biesheuvel Cc: Kees Cook , Thomas Garnier , "kernel-hardening@lists.openwall.com" , Ingo Molnar , Andy Lutomirski , "x86@kernel.org" , Borislav Petkov , Baoquan He , Yinghai Lu , Juergen Gross , Matt Fleming , Toshi Kani , Andrew Morton , Dan Williams , "Kirill A. Shutemov" , Dave Hansen , Xiao Guangrong , Martin Schwidefsky , "Aneesh Kumar K.V" , Alexander Kuleshov , Alexander Popov , Dave Young , Joerg Roedel , Lv Zheng , Mark Salter , Dmitry Vyukov , Stephen Smalley , Boris Ostrovsky , Christian Borntraeger , Jan Beulich , LKML , Jonathan Corbet , "linux-doc@vger.kernel.org" List-ID: Hi Ard, On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote: > On 23 June 2016 at 21:58, Kees Cook wrote: > > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: > >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote: > >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier wrote: > >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper wrote: > >>> >> Hey Kees, > >>> >> > >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote: > >>> >>> Notable problems that needed solving: > >>> >> ... > >>> >>> - Reasonable entropy is needed early at boot before get_random_bytes() > >>> >>> is available. > >>> >> > >>> >> This series is targetting x86, which typically has RDRAND/RDSEED > >>> >> instructions. Are you referring to other arches? Older x86? Also, > >>> >> isn't this the same requirement for base address KASLR? > >>> >> > >>> >> Don't get me wrong, I want more diverse entropy sources available > >>> >> earlier in the boot process as well. :-) I'm just wondering what's > >>> >> different about this series vs base address KASLR wrt early entropy > >>> >> sources. > >>> >> > >>> > > >>> > I think Kees was referring to the refactor I did to get the similar > >>> > entropy generation than KASLR module randomization. Our approach was > >>> > to provide best entropy possible even if you have an older processor > >>> > or under virtualization without support for these instructions. > >>> > Unfortunately common on companies with a large number of older > >>> > machines. > >>> > >>> Right, the memory offset KASLR uses the same routines as the kernel > >>> base KASLR. The issue is with older x86 systems, which continue to be > >>> very common. > >> > >> We have the same issue in embedded. :-( Compounded by the fact that > >> there is no rand instruction (at least not on ARM). So, even if there's > >> a HW-RNG, you can't access it until the driver is loaded. > >> > >> This is compounded by the fact that most systems deployed today have > >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c) > >> without dtb support at all. > >> > >> My current thinking is to add a devicetree property > >> "userspace,random-seed" . This way, existing, deployed > >> boards can append a dtb to a modern kernel with the property set. > >> The factory bootloader then only needs to amend its boot scripts to read > >> random-seed from the fs to the given address. > > > > The arm64 KASLR implementation has defined a way for boot loaders to > > pass in an seed similar to this. It might be nice to have a fall-back > > to a DT entry, though, then the bootloaders don't need to changed. > > > > Ard might have some thoughts on why DT wasn't used for KASLR (I assume > > the early parsing overhead, but I don't remember the discussion any > > more). > > > > On arm64, only DT is used for KASLR (even when booting via ACPI). My > first draft used register x1, but this turned out to be too much of a > hassle, since parsing the DT is also necessary to discover whether > there is a 'nokaslr' argument on the kernel command line. So the > current implementation only supports a single method, which is the > /chosen/kaslr-seed uint64 property. Ok, just to clarify (after a short offline chat), my goal is to set a userspace,random-seed property in the device tree once. The bootloader scripts would also only need to be altered once. Then, at each boot, the bootloader reads the entirety of /var/lib/misc/random-seed (512 bytes) into the configured address. random-seed could be in /boot, or on a flash partition. The decompressor would consume a small portion of that seed for kaslr and such. After that, the rest would be consumed by random.c to initialize the entropy pools. thx, Jason.