linux-kernel - Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

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]

Date:   Wed, 16 Aug 2017 23:31:48 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Daniel Micay <danielmicay@...il.com>,
        kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote:
> From: Daniel Micay <danielmicay@...il.com>
> 
> Existing Android bootloaders usually pass data useful as early entropy
> on the kernel command-line. It may also be the case on other embedded
> systems.....

May I suggest a slight adjustment to the beginning commit description?

   Feed the boot command-line as to the /dev/random entropy pool

   Existing Android bootloaders usually pass data which may not be
   known by an external attacker on the kernel command-line.  It may
   also be the case on other embedded systems.  Sample command-line
   from a Google Pixel running CopperheadOS....

The idea here is to if anything, err on the side of under-promising
the amount of security we can guarantee that this technique will
provide.  For example, how hard is it really for an attacker who has
an APK installed locally to get the device serial number?  Or the OS
version?  And how much variability is there in the bootloader stages
in milliseconds?

I think we should definitely do this.  So this is more of a request to
be very careful what we promise in the commit description, not an
objection to the change itself.

Cheers,

					- Ted