linux-kernel - Re: [PATCH v9 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: <20190829154505.GB10779@mit.edu>
Date:   Thu, 29 Aug 2019 11:45:05 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Hsin-Yi Wang <hsinyi@...omium.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        "David S . Miller" <davem@...emloft.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Arnd Bergmann <arnd@...db.de>, Marc Zyngier <maz@...nel.org>,
        Julien Thierry <julien.thierry.kdev@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Wei Li <liwei391@...wei.com>,
        Anders Roxell <anders.roxell@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Aaro Koskinen <aaro.koskinen@...ia.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Rik van Riel <riel@...riel.com>,
        Waiman Long <longman@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Armijn Hemel <armijn@...ldur.nl>,
        Grzegorz Halat <ghalat@...hat.com>,
        Len Brown <len.brown@...el.com>,
        Shaokun Zhang <zhangshaokun@...ilicon.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Guenter Roeck <groeck@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Yury Norov <ynorov@...vell.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jiri Kosina <jkosina@...e.cz>,
        Mukesh Ojha <mojha@...eaurora.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 2/3] fdt: add support for rng-seed

On Thu, Aug 29, 2019 at 06:03:57PM +0800, Hsin-Yi Wang wrote:
> On Thu, Aug 29, 2019 at 1:36 AM Kees Cook <keescook@...omium.org> wrote:
> >
> > Can this please be a boot param (with the default controlled by the
> > CONFIG)? See how CONFIG_RANDOM_TRUST_CPU is wired up...
> >
>
> Currently rng-seed read and added in setup_arch() -->
> setup_machine_fdt().. -> early_init_dt_scan_chosen(), which is earlier
> than parse_early_param() that initializes early_param.
> 
> If we want to set it as a boot param, add_bootloader_randomness() can
> only be called after parse_early_param(). The seed can't be directly
> added to pool after it's read in. We need to store into global
> variable and load it later.
> If this seems okay then I'll add a patch for this. Thanks

I thought about asking for this, but we really want to do this as
early as possible, so that it can be used by KASLR and other services
that are run super early.  Also, whether or not we can trust the
bootloader is going to be a system-level thing.  This should probably
be defaulted to off, and only enabled by the system integrator if they
are 100%, positively sure, that the entire system is one where we can
trust the source of randomness which the bootloader is using --- or
for that matter, that the bootloader is trustworthy!

Is it really going to be that useful for a random system administrator
to be able to flip this on or off from the command line?  Hopefully
there will be an easy way to configure the firmware or the bootloader
to simply not supply entropy, if for some reason it's not trustworthy.

   	      	     	      	     - Ted