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

To do something cross-arch putting it in memory and having something point to it is probably easiest, but again, with an in-VM boot loader the command line rather sucks.  This then becomes a matter for device tree/ACPI with all that entails.

In that sense it would be better to do something arch-specififc, because what is easy to do early is rather inherently arch-specific.

Sent from my tablet, pardon any formatting problems.

> On Apr 30, 2014, at 19:06, "Theodore Ts'o" <tytso@....edu> wrote:
> 
>> 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/