[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu8SGsLCbVqDQVtZU4nNf=zzhONSFoSNF_Q29VmD=TZMWw@mail.gmail.com>
Date: Thu, 23 Jun 2016 22:05:53 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Kees Cook <keescook@...omium.org>
Cc: Jason Cooper <jason@...edaemon.net>, 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: [PATCH v7 0/9] x86/mm: memory area address KASLR
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:
>> 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 <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.
>> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
