From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH] KVM: x86: Deny PIT creation on the absence of in-kernel
 irqchip support
Date: Wed, 14 Dec 2011 18:38:37 +0100
Message-ID: <4EE8DF1D.7080006@siemens.com>
References: <4EE8C61F.8050200@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: kvm <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from goliath.siemens.de ([192.35.17.28]:32177 "EHLO
	goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755460Ab1LNRil (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 14 Dec 2011 12:38:41 -0500
In-Reply-To: <4EE8C61F.8050200@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 2011-12-14 16:51, Jan Kiszka wrote:
> Failing to do this allowed user space to crash the host by creating a
> PIT without in-kernel IRQ controllers and routes in place:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
> IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm]
> ...
> Call Trace:
>  [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm]
>  [<ffffffff81071431>] process_one_work+0x111/0x4d0
>  [<ffffffff81071bb2>] worker_thread+0x152/0x340
>  [<ffffffff81075c8e>] kthread+0x7e/0x90
>  [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Stable material as well.
> 
>  arch/x86/kvm/x86.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 23c93fe..7137a84 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3152,6 +3152,9 @@ long kvm_arch_vm_ioctl(struct file *filp,
>  			goto out;
>  	create_pit:
>  		mutex_lock(&kvm->slots_lock);
> +		r = -ENXIO;
> +		if (!irqchip_in_kernel(kvm))
> +			goto create_pit_unlock;
>  		r = -EEXIST;
>  		if (kvm->arch.vpit)
>  			goto create_pit_unlock;

Hmm, patch breaks existing qemu-kvm user space which creates the PIT
before the irqchips these days. Too bad...

We probably have to detect the inconsistency in place, i.e. when the PIT
timer is about to be started. Hope that covers all cases. Need to check.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux