From: Sasha Levin <levinsasha928@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"avi@redhat.com" <avi@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] kvm: Remove ability to assign a device without iommu support
Date: Tue, 20 Dec 2011 11:08:48 +0200 [thread overview]
Message-ID: <1324372128.22797.6.camel@lappy> (raw)
In-Reply-To: <4EF04F54.9010500@siemens.com>
On Tue, 2011-12-20 at 10:03 +0100, Jan Kiszka wrote:
> On 2011-12-20 09:49, Sasha Levin wrote:
> > On Mon, 2011-12-19 at 20:19 -0700, Alex Williamson wrote:
> >> This option has no users and it exposes a security hole that we
> >> can allow devices to be assigned without iommu protection. Make
> >> KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.
> >>
> >> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> >> ---
> >>
> >> virt/kvm/assigned-dev.c | 18 +++++++++---------
> >> 1 files changed, 9 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> >> index 3ad0925..a251a28 100644
> >> --- a/virt/kvm/assigned-dev.c
> >> +++ b/virt/kvm/assigned-dev.c
> >> @@ -487,6 +487,9 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
> >> struct kvm_assigned_dev_kernel *match;
> >> struct pci_dev *dev;
> >>
> >> + if (!(assigned_dev->flags & KVM_DEV_ASSIGN_ENABLE_IOMMU))
> >> + return -EINVAL;
> >
> > Could we just drop KVM_DEV_ASSIGN_ENABLE_IOMMU and do it by default?
> > calling KVM_ASSIGN_PCI_DEVICE without that flag set it pretty
> > meaningless.
>
> There is that thing called "backward compatibility". :)
Well, Alex suggested skipping deprecation period because there are
currently no users of KVM_ASSIGN_PCI_DEVICE without
KVM_DEV_ASSIGN_ENABLE_IOMMU, so it should be fine to just make it the
default behavior, no?
We can leave KVM_DEV_ASSIGN_ENABLE_IOMMU itself so userspace won't
break, but theres no reason to enforce it being set in the kernel code.
--
Sasha.
next prev parent reply other threads:[~2011-12-20 9:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 3:19 [PATCH 0/2] kvm: Lock down device assignment Alex Williamson
2011-12-20 3:19 ` [PATCH 1/2] kvm: Remove ability to assign a device without iommu support Alex Williamson
2011-12-20 8:49 ` Sasha Levin
2011-12-20 9:03 ` Jan Kiszka
2011-12-20 9:08 ` Sasha Levin [this message]
2011-12-20 9:12 ` Jan Kiszka
2011-12-20 9:14 ` Avi Kivity
2011-12-20 14:28 ` Alex Williamson
2011-12-20 9:19 ` Avi Kivity
2011-12-20 3:19 ` [PATCH 2/2] kvm: Device assignment permission checks Alex Williamson
2011-12-20 9:23 ` [PATCH 0/2] kvm: Lock down device assignment Avi Kivity
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=1324372128.22797.6.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.