linux-kernel - Re: [PATCH v8 2/3] fdt: add support for rng-seed

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: <20190819181349.GE10349@mit.edu>
Date:   Mon, 19 Aug 2019 14:13:49 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Hsin-Yi Wang <hsinyi@...omium.org>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Frank Rowand <frowand.list@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Miles Chen <miles.chen@...iatek.com>,
        James Morse <james.morse@....com>,
        Andrew Murray <andrew.murray@....com>,
        Mark Rutland <mark.rutland@....com>,
        Jun Yao <yaojun8558363@...il.com>, Yu Zhao <yuzhao@...gle.com>,
        Robin Murphy <robin.murphy@....com>,
        Laura Abbott <labbott@...hat.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v8 2/3] fdt: add support for rng-seed

On Mon, Aug 19, 2019 at 03:16:04PM +0800, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in DT.

So it's really cool that you've sent out this patch set.  I've been
wanting this for all platforms / architectures for quite a while.
Question --- are you willing to guarantee that the booloader can be
trusted enough that you *know* the entropy being provided by the
bootloader to be secure?

If so, we could let fdt.c use a different interface, perhaps
add_hwgenerator_randomness(), which allows the bootloader to transfer
trusted entropy for the purposes of initializing the crng and entropy
accounting for /dev/random.

One of the questions is how do we make sure the boot loader is
actually secure, but given that we have to trust the boot loader for
various trusted boot use cases, it seems reasonable to do that.

What do you think?

					- Ted