From: Theodore Ts'o <tytso@mit.edu>
To: Laura Abbott <labbott@redhat.com>
Cc: Kees Cook <keescook@chromium.org>,
Daniel Micay <danielmicay@gmail.com>,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline
Date: Wed, 16 Aug 2017 23:31:48 -0400 [thread overview]
Message-ID: <20170817033148.ownsmbdzk2vhupme@thunk.org> (raw)
In-Reply-To: <20170816231458.2299-3-labbott@redhat.com>
On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote:
> From: Daniel Micay <danielmicay@gmail.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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-17 3:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 23:14 [PATCHv3 0/2] Command line randomness Laura Abbott
2017-08-16 23:14 ` [PATCHv3 1/2] init: Move stack canary initialization after setup_arch Laura Abbott
2017-08-16 23:14 ` [PATCHv3 2/2] extract early boot entropy from the passed cmdline Laura Abbott
2017-08-16 23:23 ` Kees Cook
2017-08-17 3:31 ` Theodore Ts'o [this message]
2017-08-17 4:23 ` Daniel Micay
2017-08-17 20:57 ` Daniel Micay
2017-08-17 21:44 ` Theodore Ts'o
2017-08-30 9:57 ` Pavel Machek
2017-08-30 13:27 ` [kernel-hardening] " Nick Kralevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170817033148.ownsmbdzk2vhupme@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=danielmicay@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox