From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id DC4338DAD for ; Wed, 30 Sep 2015 21:11:38 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so76319420wic.1 for ; Wed, 30 Sep 2015 12:11:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xP5f2O2b+W3tmcn9d4J+GbUGrJz2WFQbXTBzjnQW9go=; b=FC3el5xzosW9OD9y5gydZZCLkE+4qpq86vOeZyClscIAegPrx9a1VOLGnrJh/o4r91 PntwLDxdiCQn9i4RK2PzMdypwkJZaPJqWu9O5nlrpVNDv8ZgzH+HtcKRva2bnKFfRm0m 92RqvZ0Q+cKjoXhMarGaJf2rOCOeyG/Nz23AlSgkyzpxoQzTW85F3+W9qrfxCJRbG0p8 c0kstqbuTyKYzxDCLc9jq9PKD7S+TaBPxnustHT9I5IVaR31cQsrW0oShi9ZmAB5YSxG 5ImO0qe6yA2bfRC9doFsAhsB9V0Bw5vW06X/Uvb8rDYyQSpXhOXhPo4hSum3Ujep7jmA ImsA== X-Gm-Message-State: ALoCoQlWj5EM6lw75YDLWEcc/64oRk5B7VMUDw0pRpxIcb2oyi3RQQ29IREDjcMbPjjpjBOvmYwq X-Received: by 10.194.206.38 with SMTP id ll6mr6296155wjc.116.1443640298736; Wed, 30 Sep 2015 12:11:38 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-180-197-252.red.bezeqint.net. [79.180.197.252]) by smtp.googlemail.com with ESMTPSA id h7sm2165968wjz.7.2015.09.30.12.11.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 12:11:38 -0700 (PDT) To: "Michael S. Tsirkin" 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> <560C33C1.7030202@cloudius-systems.com> From: Vlad Zolotarov Message-ID: <560C33E8.70206@cloudius-systems.com> Date: Wed, 30 Sep 2015 22:11:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <560C33C1.7030202@cloudius-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 19:11:39 -0000 On 09/30/15 22:10, Vlad Zolotarov wrote: > > > 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... ;) ...the promise nobody really cares about... > >> we'd rather make the developers life easier instead (by applying the >> not-yet-completed patch I'm working on). >>> >> >