From: Jan Kiszka <jan.kiszka@web.de>
To: Abel Gordon <ABELG@il.ibm.com>
Cc: Alex Landau <LALEX@il.ibm.com>,
Dan Tsafrir <dan.tsafrir@gmail.com>,
sheng qiu <herbert1984106@gmail.com>, kvm <kvm@vger.kernel.org>,
Muli Ben-Yehuda <muli@cs.technion.ac.il>,
Nadav Har'El <NYH@il.ibm.com>, Nadav Amit <nadav.amit@gmail.com>
Subject: Re: KVM handling external interrupts
Date: Thu, 07 Jun 2012 13:40:57 +0200 [thread overview]
Message-ID: <4FD09349.6090305@web.de> (raw)
In-Reply-To: <OFB1DF9654.3F7DAE26-ONC2257A16.0035B4BD-C2257A16.00368575@il.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
On 2012-06-07 11:55, Abel Gordon wrote:
> Security holes: not if you are OK with the threat model we describe in the
> paper
Back to this: I don't get your threat model completely. How should the
guest be able to manipulate the shadow IDT if we a) mark it read-only in
the host's page table that maps the guest physical memory and b) prevent
via the IOMMU that any assigned devices can address this page via DMA?
But even if we consider the IDT unsafe, what does that IDT limiting buy
us? The guest can still mask interrupts above that limit via cli, no?
Also, unless I misunderstood your suggestions, I wouldn't try to run
normal interrupt handlers in NMI context. That's asking for lots of
troubles or lots of code changes.
So the only measures that save us from CPU hogging guests are the
preemption timer and kicking via NMI. Or what am I missing?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-06-07 11:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 0:12 KVM handling external interrupts sheng qiu
2012-06-07 7:51 ` Abel Gordon
2012-06-07 8:13 ` Jan Kiszka
2012-06-07 9:02 ` Jan Kiszka
2012-06-07 10:47 ` Abel Gordon
2012-06-07 10:51 ` Jan Kiszka
2012-06-07 11:05 ` Abel Gordon
2012-06-07 11:13 ` Jan Kiszka
2012-06-07 11:51 ` Abel Gordon
2012-06-07 11:54 ` Jan Kiszka
2012-06-07 12:02 ` Abel Gordon
2012-06-07 11:10 ` Jan Kiszka
2012-06-07 11:49 ` Abel Gordon
2012-06-07 12:11 ` Jan Kiszka
2012-06-07 12:25 ` Abel Gordon
2012-06-07 15:05 ` Jan Kiszka
2012-06-10 8:41 ` Abel Gordon
2012-06-10 10:16 ` Jan Kiszka
2012-06-10 10:43 ` Abel Gordon
2012-06-10 12:16 ` Jan Kiszka
2012-06-10 13:30 ` Abel Gordon
2012-06-07 9:55 ` Abel Gordon
2012-06-07 10:23 ` Jan Kiszka
2012-06-07 10:34 ` Nadav Har'El
2012-06-07 10:48 ` Jan Kiszka
2012-06-07 11:40 ` Jan Kiszka [this message]
2012-06-07 12:17 ` Abel Gordon
2012-06-07 12:19 ` Jan Kiszka
2012-06-07 12:32 ` Abel Gordon
2012-06-07 15:07 ` Jan Kiszka
2012-06-10 10:12 ` Abel Gordon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FD09349.6090305@web.de \
--to=jan.kiszka@web.de \
--cc=ABELG@il.ibm.com \
--cc=LALEX@il.ibm.com \
--cc=NYH@il.ibm.com \
--cc=dan.tsafrir@gmail.com \
--cc=herbert1984106@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=muli@cs.technion.ac.il \
--cc=nadav.amit@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox