[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9r_WZ7hTaPpq=JKzVj-9bfnbE=J_z+aMHzrjPv=6y2_CA@mail.gmail.com>
Date: Fri, 25 Feb 2022 12:43:53 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-hyperv@...r.kernel.org, KVM list <kvm@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
QEMU Developers <qemu-devel@...gnu.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
adrian@...ity.io, "Woodhouse, David" <dwmw@...zon.co.uk>,
Alexander Graf <graf@...zon.com>,
Colm MacCarthaigh <colmmacc@...zon.com>,
"Weiss, Radu" <raduweis@...zon.com>,
Daniel P. Berrangé <berrange@...hat.com>,
Laszlo Ersek <lersek@...hat.com>,
Igor Mammedov <imammedo@...hat.com>,
Eduardo Habkost <ehabkost@...hat.com>, ben@...portsystems.com,
"Michael S. Tsirkin" <mst@...hat.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Eric Biggers <ebiggers@...nel.org>,
Jann Horn <jannh@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Theodore Y. Ts'o" <tytso@....edu>,
Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH v3 1/2] random: add mechanism for VM forks to reinitialize crng
On Fri, Feb 25, 2022 at 12:26 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Thu, 24 Feb 2022 at 14:39, Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > When a VM forks, we must immediately mix in additional information to
> > the stream of random output so that two forks or a rollback don't
> > produce the same stream of random numbers, which could have catastrophic
> > cryptographic consequences. This commit adds a simple API, add_vmfork_
> > randomness(), for that, by force reseeding the crng.
> >
> > This has the added benefit of also draining the entropy pool and setting
> > its timer back, so that any old entropy that was there prior -- which
> > could have already been used by a different fork, or generally gone
> > stale -- does not contribute to the accounting of the next 256 bits.
> >
> > Cc: Dominik Brodowski <linux@...inikbrodowski.net>
> > Cc: Theodore Ts'o <tytso@....edu>
> > Cc: Jann Horn <jannh@...gle.com>
> > Cc: Eric Biggers <ebiggers@...gle.com>
> > Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
>
> Acked-by: Ard Biesheuvel <ardb@...nel.org>
Okay if I treat this as a Reviewed-by instead?
Powered by blists - more mailing lists