From patchwork Fri Jun 24 16:02:38 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Cooper X-Patchwork-Id: 9197865 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 78DB66075F for ; Fri, 24 Jun 2016 16:03:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5E3EF28499 for ; Fri, 24 Jun 2016 16:03:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 52AE5284BC; Fri, 24 Jun 2016 16:03:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 7757A28499 for ; Fri, 24 Jun 2016 16:02:59 +0000 (UTC) Received: (qmail 24189 invoked by uid 550); 24 Jun 2016 16:02:57 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: kernel-hardening@lists.openwall.com Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 24168 invoked from network); 24 Jun 2016 16:02:56 -0000 X-MHO-User: 259a574f-3a25-11e6-a0ff-e511cd071b9b 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 435B3800BC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lakedaemon.net; s=mail; t=1466784158; bh=J2ReGjIasjpUdmxkXg4o6Grqwo4b2UbPvolFNM3Z/0E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=DFZDxXoSW96qehwmRgHe8btmqUYBJ2bRd5uemHG4cLT+00IlkrWTgyD2sX1svUuMc plN6ioIeSotVHhne+qSNdIYLdzqqItN5Yeow7lFzkR9yosK+175z5VMPwd8fqkM0x0 kKEtPjKw0Ulxc+P+r9HqRZwFG5ZhIIFaAYFJiXEeIQnIWDtjyH1DCwePMK/hfRBTAT HdvJV+/8ureF/Bnwy6PrR3gzrGRMO6ifbUC4/zgPw1O8DYduYHxssiB1kTtUpn+gpe Lk8KJS0c41gA6oBujXkz/JCA3imSWQ+UCYpIRcpicS2jDda2ZtjM91lr3jJA6HtnBw +itBdRaV5rpRQ== Date: Fri, 24 Jun 2016 16:02:38 +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" Message-ID: <20160624160238.GV9922@io.lakedaemon.net> References: <1466556426-32664-1-git-send-email-keescook@chromium.org> <20160622124707.GC9922@io.lakedaemon.net> <20160623193358.GL9922@io.lakedaemon.net> <20160624011115.GU9922@io.lakedaemon.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [kernel-hardening] devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR" X-Virus-Scanned: ClamAV using ClamSMTP Thomas, Sorry for wandering off the topic of your series. The big take away for me is that you and Kees are concerned about x86 systems pre-RDRAND. Just as I'm concerned about deployed embedded systems without bootloader support for hw-rngs and so forth. Whatever final form the approach takes for ARM/dt, I'll make sure we can extend it to legacy x86 systems. Ard, On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote: > On 24 June 2016 at 03:11, Jason Cooper wrote: > > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote: ... > >> 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. > > > > I see. This indeed has little to do with the arm64 KASLR case, other > than that they both use a DT property. > > In the arm64 KASLR case, I deliberately chose to leave it up to the > bootloader/firmware to roll the dice, for the same reason you pointed > out, i.e., that there is no architected way on ARM to obtain random > bits. So in that sense, what you are doing is complimentary to my > work, and a KASLR aware arm64 bootloader would copy some of its > random bits taken from /var/lib/misc/random-seed into the > /chosen/kaslr-seed DT property. Here I disagree. We have two distinct entropy sources; the hw-rng currently feeding kaslr via the /chosen/kaslr-seed property, and the seasoned userspace seed I propose handed in via an extra property. Having the bootloader conflate those two sources as if they are equal seems to muddy the waters. I prefer to have bootloaders tell me where they got the data rather than to hope the bootloader sourced and mixed it well. > Note that, at the moment, this DT property is only an internal > contract between the kernel's UEFI stub and the kernel proper, so we > could still easily change that if necessary. Ideally, I'd prefer to be deliberate with the DT properties, e.g. random-seed,hwrng <--- bootloader reads from hw-rng random-seed,userspace <--- bootloader reads file from us to addr The kernel decompressor can init kaslr with only one of the two properties populated. If both properties are present, then the decompressor can extract a u64 from userspace-seed and mix it with hwrng-seed before use. The small devicetree portion of my brain feels like 'kaslr-seed' is telling the OS what to do with the value. Whereas devicetree is supposed to be describing the hardware. Or, in this case, describing the source of the data. Given that more entropy from more sources is useful for random.c a bit later in the boot process, it might be worth making hwrng-seed larger than u64 as well. This way we can potentially seed random.c from two sources *before* init even starts. Without having to depend on the kernel's hw-rng driver being probed. After all, it might not have been built, or it could be a module that's loaded later. I've attached a draft patch to chosen.txt. thx, Jason. --------------->8--------------------------------- diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index 6ae9d82d4c37..61f15f04bc0a 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found. However, the "linux,stdout-path" and "stdout" properties are deprecated. New platforms should only use the "stdout-path" property. +random-seed properties +---------------------- + +The goal of these properties are to provide an entropy seed early in the boot +process. Typically, this is needed by the kernel decompressor for +initializing KASLR. At that point, the kernel entropy pools haven't been +initialized yet, and any hardware rng drivers haven't been loaded yet, if they +exist. + +The bootloader can attain these seeds and pass them to the kernel via the +respective properties. The bootloader is not expected to mix or condition +this data in any way, simply read and pass. Either one or both properties can +be set if the data is available. + +random-seed,hwrng property +-------------------------- + +For bootloaders with support for reading from the system's hardware random +number generator. The bootloader can read a chunk of data from the hw-rng +and set it as the value for this binary blob property. + +/ { + chosen { + random-seed,hwrng = <0x1f 0x07 0x4d 0x91 ...>; + }; +}; + +random-seed,userspace property +------------------------------ + +The goal of this property is to also provide backwards compatibility with +existing systems. The bootloaders on these deployed systems typically lack +the ability to edit a devicetree or read from an hwrng. The only requirement +for a bootloader is that it be able to read a seed file generated by the +previous boot into a pre-determined physical address and size. This is +typically done via boot scripting. + +This property can then be set in the devicetree statically and parsed by a +modern kernel without requiring a bootloader update. + +/ { + chosen { + random-seed,userspace = <0x40000 0x200>; + }; +}; + linux,booted-from-kexec -----------------------