From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] QEMU-KVM: MCE: Relay UCR MCE to guest Date: Wed, 09 Sep 2009 15:10:37 +0300 Message-ID: <4AA79B3D.9040800@redhat.com> References: <1252312353.14648.731.camel@yhuang-dev.sh.intel.com> <4AA57187.5020502@us.ibm.com> <20090908081125.GB9107@basil.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Huang Ying , "kvm@vger.kernel.org" To: Andi Kleen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753085AbZIIMKl (ORCPT ); Wed, 9 Sep 2009 08:10:41 -0400 In-Reply-To: <20090908081125.GB9107@basil.fritz.box> Sender: kvm-owner@vger.kernel.org List-ID: 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). -- error compiling committee.c: too many arguments to function