linux-kernel - Re: [RFC] Deferred interrupt handling.

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]

Date:	Wed, 18 Jul 2007 12:30:40 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Or Sagi" <ors@...is.com>
Cc:	<linux-kernel@...r.kernel.org>, <kvm-devel@...ts.sourceforge.net>
Subject: Re: [RFC] Deferred interrupt handling.

> In particular, this requires interrupt handling to be done by the guest --
> The host shouldn't load the corresponding device driver or otherwise access
> the device. Since the host kernel is not aware of the device semantics it
> cannot acknowledge the interrupt at the device level.

Tricky indeed.

> As far as the host kernel is concerned the VM is a user level process. We
> require the ability to forward interrupt handling to such entities. The
> current kernel interrupt handling path doesn't allow deferring interrupt
> handling _and_ acknowledgement.

We don't support this model at all, and it doesn't appear to work anyway.

> 0. Adding an IRQ_DEFERRED mechanism to the interrupt handling path. ISRs
> returning IRQ_DEFERRED will keep the interrupt masked until future
> acknowledge.

Deadlock. If you get an IRQ for a guest and you block the IRQ until the
guest handles it you may (eg if the IRQ is shared) get priority inversion
with another interrupt source on the same line the guest requires first
(eg disks and other I/O)

> Another issue we are aware of is the effect deferred handling will have on
> other devices sharing the interrupt. This seems to be a problem regardless
> of the solution.

Yes. This is the big reason Linux has never supported this kind of model
for anything but old ISA IRQ handling in vm86.
> 
> We wouldn't like to assume VT-d availability right now.
> 
> Any ideas ? Thoughts ?

Mask the interrupt in the main kernel, pass an event of some kind to the
guest. You can describe most devices from guest to kernel in a safe form
as

device, bar, offset, register size, mask, bits to set, bits to clear

(or bits to test when deciding if it is the irq source)

-
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/