On 09/07/2009 11:48 PM, Anthony Liguori wrote:
#ifdef KVM_CAP_IRQCHIP
int kvm_set_irq_level(kvm_context_t kvm, int irq, int level, int
*status)
@@ -1515,6 +1546,38 @@ static void sig_ipi_handler(int n)
{
}
+static void sigbus_handler(int n, struct signalfd_siginfo *siginfo,
void *ctx)
+{
+ if (siginfo->ssi_code == BUS_MCEERR_AO) {
+ uint64_t status;
+ unsigned long paddr;
+ CPUState *cenv;
+
+ /* Hope we are lucky for AO MCE */
Even if the error was limited to guest memory, it could have been
generated by either the kernel or userspace reading guest memory, no?
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?
If the instruction gets skipped, we may be leaking host memory because
the access never happened.
I think it's a lot safer to only report guest mode accesses to the
guest, and let user mode accesses terminate qemu. The guest wouldn't
expect 100% recovery; for example if an uncorrectable error hit a vital
kernel data structure.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
