Hi Paolo, On Mon, Sep 26, 2022 at 06:07:43PM +0200, Paolo Bonzini wrote: > On Mon, Sep 26, 2022 at 3:45 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > On Thu, Sep 22, 2022 at 5:28 PM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > We don't want it to be possible to re-read the RNG seed after ingesting > > > it, because this ruins forward secrecy. Currently, however, the setup > > > data section can just be re-read. Since the kernel is always read after > > > the setup data, use the selection of the kernel as a trigger to > > > re-initialize the RNG seed, just like we do on reboot, to preserve > > > forward secrecy. > > > > > > Cc: Paolo Bonzini <pbonz...@redhat.com> > > > Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> > > > --- > > > Paolo- this applies on top of the 4 you merged this morning. -Jason > > > > Just bumping this, in hopes that this can go out with the same PULL > > for the other 4 you merged last week. > > Thanks, queued but I have a question.
Thank you. Also hope to see pc-bios/qboot.rom rebuilt based on that new submodule commit. QEMU uses the prebuilt in its tree, rather than rebuilding from the submodule. (I sent a patch earlier rebuilding qboot.rom in the tree, but you should probably do this yourself because it's pretty darn hard to verify binary diffs like that on the mailing list.) > If I understand correctly, this protects against rereading the seed while the > OS is running. If so, does that mean that the device tree-based seed > initialization does not have forward secrecy at all? On both x86 and dtb-based archs, the seed in memory is zeroed out by the kernel after reading. So, as far as the guest is concerned, there's forward secrecy. Except! Except if the guest has someway of re-requesting that seed from the host. This patch prevents that from happening through fw_cfg on x86. Somebody told me last week that device tree archs don't use fw_cfg, so this won't be a problem there. I haven't yet looked to verify that yet, though, or looked if there are other mechanisms. Jason
