Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 14 Apr 2018 22:59:21 +0300
From:   Alexey Dobriyan <adobriyan@gmail.com>
To:     linux-kernel@vger.kernel.org, tytso@mit.edu, kvm@vger.kernel.org
Cc:     security@kernel.org
Subject: repeatable boot randomness inside KVM guest
Message-ID: <20180414195921.GA10437@avx2>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.7.2 (2016-11-26)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes
allocation pattern inside a slab:


	#ifdef CONFIG_SLAB_FREELIST_RANDOM
	/* Pre-initialize the random sequence cache */
	static int init_cache_random_seq(struct kmem_cache *s)
	{
		...

Then I printed actual random sequences for each kmem cache.
Turned out they were all the same for most of the caches and
they didn't vary across guest reboots.

	int cache_random_seq_create(struct kmem_cache *cachep, unsigned int count, gfp_t gfp)
	{
		...
		/* Get best entropy at this stage of boot */
	        prandom_seed_state(&state, get_random_long());

Then I searched internet and turned out KVM can pass randomness via
virtio-rng or something. So I linked /dev/urandom.

And it didn't help!

The only way to get randomness for SLAB is to enable RDRAND inside guest.

Is it KVM bug?

For the record I'm using qemu 2.11.1-r2 and whatever F27 ships now.