From: Alex Williamson <alex.williamson@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.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 07:28:54 -0700 [thread overview]
Message-ID: <1324391334.2568.9.camel@bling.home> (raw)
In-Reply-To: <1324372128.22797.6.camel@lappy>
On Tue, 2011-12-20 at 11:08 +0200, Sasha Levin wrote:
> 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.
As Jan said, the option does have historical meaning. Ignoring the flag
adds ambiguity to the API, so I think it's best to make it clear which
path is no longer supported. Either way, we don't get to take the flag
back, so it might as well serve as a sanity check. Thanks,
Alex
next prev parent reply other threads:[~2011-12-20 14:29 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
2011-12-20 9:12 ` Jan Kiszka
2011-12-20 9:14 ` Avi Kivity
2011-12-20 14:28 ` Alex Williamson [this message]
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=1324391334.2568.9.camel@bling.home \
--to=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®