From: "Theodore Ts'o" <tytso@mit.edu>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Florian Weimer <fweimer@redhat.com>,
linux-kernel@vger.kernel.org, hpa@zytor.com,
Kees Cook <kees@outflux.net>
Subject: Re: [PATCH] random: Add "initialized" variable to proc
Date: Wed, 30 Apr 2014 22:06:27 -0400 [thread overview]
Message-ID: <20140501020627.GA25248@thunk.org> (raw)
In-Reply-To: <53616293.3080308@mit.edu>
On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
>
> 1. It simply doesn't work on my system. In particular, it never returns
> entropy. It just blocks forever.
Why? Is this a bug in qemu? The host OS? The guest OS? It is qemu
trying to use /dev/random instead of /dev/urandom? Any thing else?
> 3. There should be a way to provide some entropy-free cryptographically
> secure data, too. Regardless of the speed of the hosts's /dev/random,
> the guest should start with at least 256 bits of cryptographically
> secure seed material IMO.
Well, the simplest way to do this is to pass it in via the command
line, and then have the the kernel make sure it gets obscured so it's
not exposed via /proc/cmdline.
Otherwise we would have to define an extension where we pass 32 bytes
or so after the boot command line. But the downside of doing that is
we would have to modify every single architecture to define where
those 32 bytes could be found.
Aside from passing it on the command line as being a bit grotty, the
other big problem this is that some architectures only have 256 bytes
of command line, and if we use a base 64 encoding, 256 bits will take
43 characters. Not a problem on x86, and it seems rather unlikely
that people would want to virtualize a m68k or avr32 CPU. It just
feels really unclean.
I've cc'ed Peter Anvin for his opinion about extending Linux boot
parameter protocol. I agree it would be a lot simpler and easier to
enable things like Kernel ASLR with real randomness on guest OS's if
we didn't have to erect the whole virtio-pci infrastructure during
early boot. :-)
-Ted
next prev parent reply other threads:[~2014-05-01 2:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 19:52 [PATCH] random: Add "initialized" variable to proc Florian Weimer
2014-04-28 21:41 ` Theodore Ts'o
2014-04-29 17:51 ` Florian Weimer
2014-04-29 18:26 ` Theodore Ts'o
2014-04-30 20:52 ` Andy Lutomirski
2014-05-01 2:06 ` Theodore Ts'o [this message]
2014-05-01 4:05 ` H. Peter Anvin
2014-05-01 15:05 ` tytso
2014-05-01 15:35 ` Andy Lutomirski
2014-05-01 18:53 ` Andy Lutomirski
2014-05-01 18:59 ` random: Providing a seed value to VM guests H. Peter Anvin
2014-05-01 5:37 ` [PATCH] random: Add "initialized" variable to proc H. Peter Anvin
2014-05-01 14:33 ` Jason Cooper
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=20140501020627.GA25248@thunk.org \
--to=tytso@mit.edu \
--cc=fweimer@redhat.com \
--cc=hpa@zytor.com \
--cc=kees@outflux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.