linux-kernel - Re: [PATCH] random: Add "initialized" variable to proc

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, 30 Apr 2014 22:06:27 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Florian Weimer <fweimer@...hat.com>, linux-kernel@...r.kernel.org,
	hpa@...or.com, Kees Cook <kees@...flux.net>
Subject: Re: [PATCH] random: Add "initialized" variable to proc

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/