linux-kernel - Re: [PATCH] [2/2] KVM: Add VT-x machine check support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Jun 2009 14:51:24 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Avi Kivity <avi@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>, ying.huang@...el.com,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [2/2] KVM: Add VT-x machine check support

On Thu, Jun 04, 2009 at 02:48:17PM +0300, Avi Kivity wrote:
> Andi Kleen wrote:
> >[Avi could you please still consider this patch for your 2.6.31 patchqueue?
> >It's fairly simple, but important to handle memory errors in guests]
> >  
> 
> Oh yes, and it'll be needed for -stable.  IIUC, right now a machine 
> check is trapped by the guest, so the guest is killed instead of the host?

Yes the guest will receive int 18.

But it will not kill itmelf because the guest cannot access the machine check
MSRs, so it will not see any machine check. So it's kind of ignored,
which is pretty bad.

> 
> >+/*
> >+ * Trigger machine check on the host. We assume all the MSRs are already 
> >set up
> >+ * by the CPU and that we still run on the same CPU as the MCE occurred 
> >on.
> >+ * We pass a fake environment to the machine check handler because we want
> >+ * the guest to be always treated like user space, no matter what context
> >+ * it used internally.
> >+ */
> >  
> 
> This assumption is incorrect.  This code is executed after preemption 
> has been enabled, and we may have even slept before reaching it.

The only thing that counts here is the context before the machine
check event. If there was a vmexit we know it was in guest context.

The only requirement we have is that we're running still on the same
CPU. I assume that's true, otherwise the vmcb accesses wouldn't work?

> > 	[EXIT_REASON_EPT_VIOLATION]	      = handle_ept_violation,
> >+	[EXIT_REASON_MACHINE_CHECK]	      = handle_machine_check,
> > };
> > 
> > static const int kvm_vmx_max_exit_handlers =
> >  
> 
> We get both an explicit EXIT_REASON and an exception?

These are different cases. The exception is #MC in guest context,
the EXIT_REASON is when a #MC happens while the CPU is executing
the VM entry microcode.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/