From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752100AbcFWUF5 (ORCPT ); Thu, 23 Jun 2016 16:05:57 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:36238 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbcFWUFz (ORCPT ); Thu, 23 Jun 2016 16:05:55 -0400 MIME-Version: 1.0 In-Reply-To: References: <1466556426-32664-1-git-send-email-keescook@chromium.org> <20160622124707.GC9922@io.lakedaemon.net> <20160623193358.GL9922@io.lakedaemon.net> From: Ard Biesheuvel Date: Thu, 23 Jun 2016 22:05:53 +0200 Message-ID: Subject: Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR To: Kees Cook Cc: Jason Cooper , 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23 June 2016 at 21:58, Kees Cook wrote: > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: >> Hey Kees, Thomas, >> >> 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. >> Modern systems that receive a seed from the bootloader via the >> random-seed property (typically from the hw-rng) can mix both sources >> for increased resilience. > > Yeah, that could work. > >> Unfortunately, I'm not very familiar with the internals of x86 >> bootstrapping. Could GRUB be scripted to do a similar task? How would >> the address and size of the seed be passed to the kernel? command line? > > Command line could work (though it would need scrubbing to avoid it > leaking into /proc/cmdine), but there's also the "zero-page" used by > bootloaders to pass details to the kernel (see > Documentation/x86/boot.txt). Right now, x86 has sufficient entropy > (though rdrand is best). > > -Kees > > -- > Kees Cook > Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: References: <1466556426-32664-1-git-send-email-keescook@chromium.org> <20160622124707.GC9922@io.lakedaemon.net> <20160623193358.GL9922@io.lakedaemon.net> From: Ard Biesheuvel Date: Thu, 23 Jun 2016 22:05:53 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR To: Kees Cook Cc: Jason Cooper , 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: On 23 June 2016 at 21:58, Kees Cook wrote: > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper wrote: >> Hey Kees, Thomas, >> >> 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. >> Modern systems that receive a seed from the bootloader via the >> random-seed property (typically from the hw-rng) can mix both sources >> for increased resilience. > > Yeah, that could work. > >> Unfortunately, I'm not very familiar with the internals of x86 >> bootstrapping. Could GRUB be scripted to do a similar task? How would >> the address and size of the seed be passed to the kernel? command line? > > Command line could work (though it would need scrubbing to avoid it > leaking into /proc/cmdine), but there's also the "zero-page" used by > bootloaders to pass details to the kernel (see > Documentation/x86/boot.txt). Right now, x86 has sufficient entropy > (though rdrand is best). > > -Kees > > -- > Kees Cook > Chrome OS & Brillo Security