From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Zolotarov Subject: Re: Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance Date: Wed, 30 Sep 2015 22:10:57 +0300 Message-ID: <560C33C1.7030202@cloudius-systems.com> References: <20150930134533-mutt-send-email-mst@redhat.com> <560BC6C9.4020505@cloudius-systems.com> <20150930143927-mutt-send-email-mst@redhat.com> <560BCD2F.5060505@cloudius-systems.com> <20150930150115-mutt-send-email-mst@redhat.com> <560BD284.7040505@cloudius-systems.com> <20150930151632-mutt-send-email-mst@redhat.com> <560BDA81.6070807@cloudius-systems.com> <20150930182155-mutt-send-email-mst@redhat.com> <560C26DC.80209@cloudius-systems.com> <20150930215027-mutt-send-email-mst@redhat.com> <560C32CC.90708@cloudius-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" To: "Michael S. Tsirkin" Return-path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 76A1C8DAD for ; Wed, 30 Sep 2015 21:10:59 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so209508585wic.1 for ; Wed, 30 Sep 2015 12:10:59 -0700 (PDT) In-Reply-To: <560C32CC.90708@cloudius-systems.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 09/30/15 22:06, Vlad Zolotarov wrote: > > > On 09/30/15 21:55, Michael S. Tsirkin wrote: >> On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote: >>> >>> On 09/30/15 18:26, Michael S. Tsirkin wrote: >>>> On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote: >>>>> How not virtualizing iommu forces "all or nothing" approach? >>>> Looks like you can't limit an assigned device to only access part of >>>> guest memory that belongs to a given process. Either let it access >>>> all >>>> of guest memory ("all") or don't assign the device ("nothing"). >>> Ok. A question then: can u limit the assigned device to only access >>> part of >>> the guest memory even if iommu was virtualized? >> That's exactly what an iommu does - limit the device io access to >> memory. > > If it does - it will continue to do so with or without the patch and > if it doesn't (for any reason) it won't do it even without the patch. > So, again, the above (rhetorical) question stands. ;) > > I think Avi has already explained quite in detail why security is > absolutely a non issue in regard to this patch or in regard to UIO in > general. Security has to be enforced by some other means like iommu. > >> >>> How would iommu >>> virtualization change anything? >> Kernel can use an iommu to limit device access to memory of >> the controlling application. > > Ok, this is obvious but what it has to do with enabling using > MSI/MSI-X interrupts support in uio_pci_generic? kernel may continue > to limit the above access with this support as well. > >> >>> And why do we care about an assigned device >>> to be able to access all Guest memory? >> Because we want to be reasonably sure a kernel memory corruption >> is not a result of a bug in a userspace application. > > Corrupting Guest's memory due to any SW misbehavior (including bugs) > is a non-issue by design - this is what HV and Guest machines were > invented for. So, like Avi also said, instead of trying to enforce > nobody cares about Let me rephrase: by pretending enforcing some security promise that u don't actually fulfill... ;) > we'd rather make the developers life easier instead (by applying the > not-yet-completed patch I'm working on). >> >