linux-kernel - Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifier interface

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: <4A3A2879.6080909@novell.com>
Date:	Thu, 18 Jun 2009 07:43:53 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Avi Kivity <avi@...hat.com>
CC:	"Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, davidel@...ilserver.org,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifier
 interface

Avi Kivity wrote:
> On 06/16/2009 05:40 PM, Gregory Haskins wrote:
>>
>> Something else to consider:  For iosignalfd, we can assume we will
>> always be called from vcpu process context so we might not really need
>> official affirmation from the system.  For irqfd, we cannot predict who
>> may be injecting the interrupt (for instance, it might be a
>> PCI-passthrough hard-irq context).  I am not sure if this knowledge
>> actually helps to simplify the problem space, but I thought I should
>> mention it.
>>    
>
> We can't assume anything.  Userspace might hand out that eventfd to
> anyone.

Yeah agreed, and I misspoke (mistyped? ;).  It's not that I assume its
from a vcpu.  Its that it doesn't matter (at least for vbus).

The reason is that the memory context is established in vbus via a
different channel (i.e. I never look at "current" in the context of the
eventfd callback).  The eventfd is just telling me that the previously
established memory context needs to be looked at (e.g. the virtio-ring
changed).  Therefore, the origin of the signal doesn't actually matter
(at least w.r.t. safe handling of the request).

Obviously, the question of whether something has really changed in the
memory and whether an errant signal could cause problems is a separate
issue.  But we need to be robust against that anyway, for a multitude of
other reasons (e.g. malicious/broken guest scribbling over the
virtio-ring, etc).

-Greg

Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)