Re: random(4) and VMs
On Tue, Sep 18, 2018 at 7:03 PM John Denker wrote: > > Is a fix that only deals with a subset of the problem worth > > considering? Just patch the VM support code so that any time a VM is > > either booted or re-started after a save, the host system drops in > > some entropy, ... > > Good solutions already exist for that subset of the problem. > > Configure your VM so that each guest has a virtual /dev/hwrng > I know this works for qemu. > I imagine it works for other VMs. > > If you find this unsatisfactory, please explain. It may still leave a VM that is snapshotted & restarted vulnerable to replay since the random state is saved & restored. I'm not sure this is much of a problem since an attacker would presumably need privileged access to the host to exploit it & if he has that, all is lost anyway.
Re: random(4) and VMs
On 09/18/2018 10:00 AM, Sandy Harris wrote: > Is a fix that only deals with a subset of the problem worth > considering? Just patch the VM support code so that any time a VM is > either booted or re-started after a save, the host system drops in > some entropy, This looks relatively easy to do, at least for Linux > VMs, and some of the code might be the same as what the more general > approaches would need. Good solutions already exist for that subset of the problem. Configure your VM so that each guest has a virtual /dev/hwrng I know this works for qemu. I imagine it works for other VMs. If you find this unsatisfactory, please explain.
random(4) and VMs
Getting the random driver well initialised early enough is a hard problem, at least on some machines. Solutions have been proposed by various people. If I understand them right, Ted Ts'o suggests modifying the boot loader to provide some entropy & John Denker suggests that every machine should be provisioned with some entropy in the kernel image at install time. Both are general solutions, but I think both would require updating the entropy store later. As far as I know, neither has yet been implemented as accepted patches Is a fix that only deals with a subset of the problem worth considering? Just patch the VM support code so that any time a VM is either booted or re-started after a save, the host system drops in some entropy, This looks relatively easy to do, at least for Linux VMs, and some of the code might be the same as what the more general approaches would need.
