public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: A few KVM security questions
Date: Mon, 07 Dec 2009 14:30:43 +0100	[thread overview]
Message-ID: <4B1D0383.1080306@invisiblethingslab.com> (raw)
In-Reply-To: <4B1D0057.8030707@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Avi Kivity wrote:

>> 1) Do you have any support for para-virtualized VMs?
> 
> Yes, for example, we support paravirtualized timers and mmu for Linux. 
> These are fairly minimal compared to Xen's pv domains.
> 

Can I run a regular Linux as PV-guest? Specifically, can I get rid of
qemu totally, assuming I have only PV guests?

E.g. do you have PV network and disk frontends (PV drivers), that I
could use on guests and that do not use qemu at all?

>> 2) Is it possible to have driver domains in KVM? E.g. I would like to
>> assign my NIC to one VM (a "network domain") and then I would like other
>> domains to use this network domain for networking. In case of Xen, this
>> is done by moving the network backend (which is not qemu BTW) into the
>> network domain, and configuring the network frontends in other VMs to
>> talk to this network domain's backend, rather then to Dom0's backend (in
>> fact you can get rid of all the networking in Dom0).
>>    
> 
> Should be doable by assigning the NIC to a driver domain and bridging it
> to a virtio driver; then have the driver domain's virtio device talk to
> the ordinary guests.

But bridging would still require to have some networking support (+net
backends) on the host (sure, without any real NIC driver, but still),
correct?

>> 4) Do you have some method of excluding particular PCI devices from
>> being initialized by your host Linux? E.g. those devices that are later
>> to be assigned to some VMs (via VT-d passthrough)?
> 
> Yes, there is a stub driver that does this.
> 

Does this stub driver sets DMA protections, so that the device in
question cannot access any host memory?

That is important, because once you assigned a device to some VM, we
should assume the VM might have somehow compromised the device, e.g.
reflashed the firmware of the NIC, perhaps. So, it's important to be
able to protect the hypervisor from such devices.

Thanks,
joanna.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

  reply	other threads:[~2009-12-07 13:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07 13:05 A few KVM security questions Joanna Rutkowska
2009-12-07 13:17 ` Avi Kivity
2009-12-07 13:30   ` Joanna Rutkowska [this message]
2009-12-07 13:38     ` Avi Kivity
2009-12-07 14:06       ` Joanna Rutkowska
2009-12-07 14:09         ` Avi Kivity
2009-12-07 16:44       ` Anthony Liguori
2009-12-07 17:09         ` Joanna Rutkowska
2009-12-07 17:13           ` Avi Kivity
2009-12-07 17:15             ` Joanna Rutkowska
2009-12-07 17:18               ` Avi Kivity
2009-12-07 17:33                 ` Joanna Rutkowska
2009-12-07 18:34                   ` Avi Kivity
2009-12-09 10:43                   ` Pasi Kärkkäinen
2009-12-07 17:38               ` Anthony Liguori
2009-12-07 17:45                 ` Joanna Rutkowska
     [not found]                 ` <20091207181556.GM4679@tyrion.haifa.ibm.com>
2009-12-07 19:58                   ` Anthony Liguori
2009-12-07 17:33           ` Anthony Liguori
2009-12-07 17:58             ` Joanna Rutkowska
2009-12-07 17:47           ` Daniel P. Berrange
2009-12-07 13:55   ` Joanna Rutkowska
2009-12-07 14:01     ` Avi Kivity
2009-12-07 16:47     ` Anthony Liguori

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=4B1D0383.1080306@invisiblethingslab.com \
    --to=joanna@invisiblethingslab.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    /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