| Message ID | 1462170413-7164-4-git-send-email-tytso@mit.edu (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o <tytso@mit.edu> wrote: > From: Stephan Mueller <smueller@chronox.de> > > The Hyper-V Linux Integration Services use the VMBus implementation for > communication with the Hypervisor. VMBus registers its own interrupt > handler that completely bypasses the common Linux interrupt handling. > This implies that the interrupt entropy collector is not triggered. > ... Stephan correctly identified the problem of virtualized environments in his paper, but there does not appear to be any real defenses in place for VM rollback attacks. Perhpas the following will make interesting reading: * When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments, https://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf * When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography, http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Montag, 2. Mai 2016, 05:00:47 schrieb Jeffrey Walton: Hi Jeffrey, > On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o <tytso@mit.edu> wrote: > > From: Stephan Mueller <smueller@chronox.de> > > > > The Hyper-V Linux Integration Services use the VMBus implementation for > > communication with the Hypervisor. VMBus registers its own interrupt > > handler that completely bypasses the common Linux interrupt handling. > > This implies that the interrupt entropy collector is not triggered. > > ... > > Stephan correctly identified the problem of virtualized environments > in his paper, but there does not appear to be any real defenses in > place for VM rollback attacks. The issue the patch addresses is only that on Hyper-V with para-virt drivers, the /dev/random implementation does not receive interrupts. The issue of rollback (if you refer to activating an earlier saved image of the guest) is a real issue the guest cannot do anything about it that is effective (i.e. the guest can do without the help of the VMM). Note, rollback is just a special case of a much broader issue of the duplication of the RNG state by the VMM (be it snapshots, move of a guest to another VMM, suspend/resume, ...). However, the patch to enable interrupts does not seem to be related to that issue as interrupts are not re-issued in case of rollbacks, are they? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 02, 2016 at 11:14:25AM +0200, Stephan Mueller wrote: > The issue of rollback (if you refer to activating an earlier saved image of > the guest) is a real issue the guest cannot do anything about it that is > effective (i.e. the guest can do without the help of the VMM). Note, rollback > is just a special case of a much broader issue of the duplication of the RNG > state by the VMM (be it snapshots, move of a guest to another VMM, > suspend/resume, ...). However, the patch to enable interrupts does not seem to > be related to that issue as interrupts are not re-issued in case of rollbacks, > are they? Rollback is just a much broader issue of how can you maintain security when the VMM is run by the NSA, and can do arbitrary things to mess with the security of the guest OS (including reading keys straight out of guest kernel memory, etc.). Hint: you can't. :-) If we are talking about someone who is realistically trying to do something useful with duplicating VMM state, I'm not aware of anyone who is actually trying to clone a running VMM in order to launch new worker nodes. People will clone disk snapshots to rapidly bring up rapid nodes, and so making sure we have a way to handle cases where you can't count on /var/state/random.seed on being useful is important. The usual answer is to use something like virtio-rng, but all of the answers are going to assume that the host system is trustworthy. If you are worried about a potential attack where the CIA has cut a deal with Amazon AWS just as the NSA did with RSADSI and DUAL-EC DRBG, you might as well go home... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/char/random.c b/drivers/char/random.c index d5bb3b3..c3f17c9 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1133,6 +1133,7 @@ void add_interrupt_randomness(int irq, int irq_flags) /* award one bit for the contents of the fast pool */ credit_entropy_bits(r, credit + 1); } +EXPORT_SYMBOL_GPL(add_interrupt_randomness); #ifdef CONFIG_BLOCK void add_disk_randomness(struct gendisk *disk) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 64713ff..9af61bb 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -41,6 +41,7 @@ #include <linux/ptrace.h> #include <linux/screen_info.h> #include <linux/kdebug.h> +#include <linux/random.h> #include "hyperv_vmbus.h" static struct acpi_device *hv_acpi_dev; @@ -801,6 +802,8 @@ static void vmbus_isr(void) else tasklet_schedule(hv_context.msg_dpc[cpu]); } + + add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0); }