On Wed, 2009-09-09 at 20:10 +0800, Avi Kivity wrote: > On 09/08/2009 11:11 AM, Andi Kleen wrote: > > > >> Does this potentially open a security hole for us? Consider the following: > >> > >> 1) We happen to read guest memory and that causes an MCE. For instance, > >> say we're in virtio.c and we read the virtio ring. > >> 2) That should trigger the kernel to generate a sigbus. > >> 3) We catch sigbus, and queue an MCE for delivery. > >> 4) After sigbus handler completes, we're back in virtio.c, what was the > >> value of the memory operation we just completed? > >> > > Yes for any errors on accessing qemu internal memory that is not > > owned by the guest image you should abort. I thought Ying's patch > > did that already though, by aborting if there's no slot match. > > > > User-mode qemu access should abort even if accessing guest memory, since > there no way to recover the thread of execution (need a kernel-style > exception table for each instruction that accesses guest memory, which > would be a total overkill). For UCR MCE caused by user space read/write, SIGBUS will be sent via force_sig_info. For guest mode qemu, SIGBUS will be captured, and for user mode qemu, SIGBUS will kill qemu. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
