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;
MIME-Version: 1.0
In-Reply-To: <20180414195921.GA10437@avx2>
References: <20180414195921.GA10437@avx2>
From:   Andy Lutomirski <luto@amacapital.net>
Date:   Sat, 14 Apr 2018 15:41:42 -0700
Message-ID: <CALCETrV2NdGnVose-xRRPG2jDCo6K9MTayYR8XUZFw5j6nU2hg@mail.gmail.com>
Subject: Re: repeatable boot randomness inside KVM guest
To:     Alexey Dobriyan <adobriyan@gmail.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, "Ted Ts'o" <tytso@mit.edu>,
        kvm list <kvm@vger.kernel.org>, security@kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Apr 14, 2018 at 12:59 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> 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.

virtio-rng doesn't really do that.  I have an ancient patch set to do
exactly what you want, and I should dust it off.