From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWkia-0000yF-FO for qemu-devel@nongnu.org; Mon, 29 Apr 2013 05:49:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWkiZ-0006wF-Bu for qemu-devel@nongnu.org; Mon, 29 Apr 2013 05:49:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWkiZ-0006w6-39 for qemu-devel@nongnu.org; Mon, 29 Apr 2013 05:49:55 -0400 Message-ID: <517E4225.7080804@redhat.com> Date: Mon, 29 Apr 2013 11:49:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1366705795-24732-1-git-send-email-imammedo@redhat.com> <1366705795-24732-18-git-send-email-imammedo@redhat.com> <20130426161754.583e3f6b@thinkpad> <20130426194616.50534c82@thinkpad> <517AFBF8.5090100@redhat.com> <517BC0A0.2080700@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 17/21] introduce memory_region_get_address() and use it in kvm/ioapic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kwolf@redhat.com, peter.maydell@linaro.org, aliguori@us.ibm.com, ehabkost@redhat.com, gleb@redhat.com, mst@redhat.com, jan.kiszka@siemens.com, quintela@redhat.com, claudio.fontana@huawei.com, armbru@redhat.com, aderumier@odiso.com, qemu-devel@nongnu.org, anthony.perard@citrix.com, alex.williamson@redhat.com, kraxel@redhat.com, yang.z.zhang@intel.com, Igor Mammedov , lcapitulino@redhat.com, afaerber@suse.de, stefano.stabellini@eu.citrix.com, rth@twiddle.net Il 27/04/2013 22:57, Blue Swirl ha scritto: >> The questions are, in order of importance: >> >> (1) what privileges would this require in the guest? Answer: a lot. >> >> (2) is this likely to happen by chance? Answer: no, not at all. >> >> (3) is there a workaround? Answer: yes, disable in-kernel irqchip. > > These questions ask if there is a risk of benevolent guests performing > these activities and I agree that the chances are close to zero. > > But the interesting question is to ask if a malevolent guest can bring > down a VM uncontrollably this way and I think it only needs a few > elevated privileges in a guest to do this. If you have them, isn't it simpler to just turn off the VM (using APM or ACPI)? Also, killing your guest is not a very interesting thing to do once you've gotten elevated privileges. ;) >> Simply setting IO_APIC_DEFAULT_ADDRESS is also flawed in my opinion. >> I'm not sure the in-kernel irqchip handles correctly an overlap between >> the IOAPIC and LAPIC regions, maybe an abort is predictable after all. > > At least the guest needs to be stopped. Perhaps we should have a > common function which does this and logs the guest error so we can > start replacing calls to abort() with it. Yes, that's a good idea. We can reuse the internal error runstate for that. Paolo