linux-kernel - Re: [PATCH 5/5] KVM: Allow host IRQ sharing for passed-through PCI 2.3 devices

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]

Message-ID: <4CFD1377.7030008@siemens.com>
Date:	Mon, 06 Dec 2010 17:46:47 +0100
From:	Jan Kiszka <jan.kiszka@...mens.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Jan Kiszka <jan.kiszka@....de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>, Tom Lyon <pugs@...co.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH 5/5] KVM: Allow host IRQ sharing for passed-through PCI
 2.3 devices

Am 06.12.2010 17:40, Avi Kivity wrote:
> On 12/06/2010 06:34 PM, Jan Kiszka wrote:
>>>
>>>  What's the protocol for doing this?  I suppose userspace has to disable
>>>  interrupts, ioctl(SET_INTX_MASK, masked), ..., ioctl(SET_INTX_MASK,
>>>  unmasked), enable interrupts?
>>
>> Userspace just has to synchronize against itself - what it already does:
>> qemu_mutex, and masking/unmasking is synchronous /wrt the the executing
>> VCPU. Otherwise, masking/unmasking is naturally racy, also in Real Life.
>> The guest resolves the remaining races.
> 
> I meant when qemu sets INTX_MASK and the kernel clears it immediately 
> afterwards because the two are not synchronized.  I guess that won't 
> happen in practice because playing with INTX_MASK is very rare.

Ah, there is indeed a race, and the qemu-kvm patches I did not post yet
(to wait for the kernel interface to settle) actually suffer from it:
userspace needs to set the kernel mask before writing the config space
(it's the other way around ATM). This avoids that the kernel overwrites
what userspace just wrote out. We always suffer from the race the other
way around, see below.

> 
> 
>>>
>>>  Isn't there a race window between the two operations?
>>>
>>>  Maybe we should give the kernel full ownership of that bit.
>>
>> I think this is what VFIO does and is surely cleaner than this approach.
>> But it's not possible with the existing interface (sysfs + KVM ioctls) -
>> or can you restrict the sysfs access to the config space in such details?
> 
> I'm sure you can, not sure it's worth it.  Can the situation be 
> exploited?  what if userspace lies?

That's also the above scenario inverted: Userspace can mask or unmask at
any time. If it unmasks a yet unhandled, thus raise interrupt, it will
trigger another one. The kernel will catch it and mask it again. That
can repeat forever with the frequency userspace is able to run its
unmasking code. Not nice, but nothing to leverage for a DoS.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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/