linux-kernel - Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160624011115.GU9922@io.lakedaemon.net>
Date:	Fri, 24 Jun 2016 01:11:15 +0000
From:	Jason Cooper <jason@...edaemon.net>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	Kees Cook <keescook@...omium.org>,
	Thomas Garnier <thgarnie@...gle.com>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	Ingo Molnar <mingo@...nel.org>,
	Andy Lutomirski <luto@...nel.org>,
	"x86@...nel.org" <x86@...nel.org>, Borislav Petkov <bp@...e.de>,
	Baoquan He <bhe@...hat.com>, Yinghai Lu <yinghai@...nel.org>,
	Juergen Gross <jgross@...e.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Toshi Kani <toshi.kani@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Williams <dan.j.williams@...el.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Alexander Kuleshov <kuleshovmail@...il.com>,
	Alexander Popov <alpopov@...ecurity.com>,
	Dave Young <dyoung@...hat.com>, Joerg Roedel <jroedel@...e.de>,
	Lv Zheng <lv.zheng@...el.com>,
	Mark Salter <msalter@...hat.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Jan Beulich <JBeulich@...e.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address
 KASLR

Hi Ard,

On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> On 23 June 2016 at 21:58, Kees Cook <keescook@...omium.org> wrote:
> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@...edaemon.net> 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 <thgarnie@...gle.com> wrote:
> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper <jason@...edaemon.net> 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" <address, len>.  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 <addr, len> 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.