From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id 6A1388D9F for ; Wed, 30 Sep 2015 13:26:04 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so193065141wic.0 for ; Wed, 30 Sep 2015 04:26:04 -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=gua2gA6p/nKRhFVTkGs17L77BGWbXNeCEvY/VVOUoMQ=; b=X/87ol3nrN104vZUleshwvgssyJtPGT6zvsQq0GisDtcz3IYqWV1NeCcuB6XEH++ac LgBjrpYhHpPxqt8Ps3NtGwlqfYL8Min7gyavGTmkaJxyFoGtot9vK+FcmvoaEHoBW9yw mWADOmRhvF80jzgeeC1pu4i/FrsbGOzSFJh+l8YUtRXvS9W5YgWUJlUgLrprwaKv1a5z MbGHO8Rtpb6IIOp5oEYSXIL2eVPVuCXwdu40AXxcXeRwb2WVlSr0F/nRwaYdWbZaONjQ DJLNx9sQw7vwIYtc6iSy41Py+atP6JagIf4kk83OmXwQap/2f0rkevRxA2hna9zCLIti OXow== X-Gm-Message-State: ALoCoQm0bhlUroX5FM3BrwkRwncM9tRFwlYL1W+0MuCJQftWRkvxDKkXEFg+SVDD6tMLnbWVCbdY X-Received: by 10.194.179.137 with SMTP id dg9mr3559600wjc.55.1443612363973; Wed, 30 Sep 2015 04:26:03 -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 b5sm124013wjf.16.2015.09.30.04.26.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 04:26:03 -0700 (PDT) To: "Michael S. Tsirkin" References: <56079527.3000802@cloudius-systems.com> <20150927123914-mutt-send-email-mst@redhat.com> <560ABF25.9030300@cloudius-systems.com> <20150929235122-mutt-send-email-mst@redhat.com> <20150929144616.4e70b44c@urahara> <20150930004714-mutt-send-email-mst@redhat.com> <560BBB62.3050502@cloudius-systems.com> <20150930134533-mutt-send-email-mst@redhat.com> From: Vlad Zolotarov Message-ID: <560BC6C9.4020505@cloudius-systems.com> Date: Wed, 30 Sep 2015 14:26:01 +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: <20150930134533-mutt-send-email-mst@redhat.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 11:26:04 -0000 On 09/30/15 13:58, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 01:37:22PM +0300, Vlad Zolotarov wrote: >> >> On 09/30/15 00:49, Michael S. Tsirkin wrote: >>> On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote: >>>> On Tue, 29 Sep 2015 23:54:54 +0300 >>>> "Michael S. Tsirkin" wrote: >>>> >>>>> On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrote: >>>>>> The security breach motivation u brought in "[RFC PATCH] uio: >>>>>> uio_pci_generic: Add support for MSI interrupts" thread seems a bit weak >>>>>> since one u let the userland access to the bar it may do any funny thing >>>>>> using the DMA engine of the device. This kind of stuff should be prevented >>>>>> using the iommu and if it's enabled then any funny tricks using MSI/MSI-X >>>>>> configuration will be prevented too. >>>>>> >>>>>> I'm about to send the patch to main Linux mailing list. Let's continue this >>>>>> discussion there. >>>>> Basically UIO shouldn't be used with devices capable of DMA. >>>>> Use VFIO for that (yes, this implies an emulated or PV IOMMU). >> If there is an IOMMU in the picture there shouldn't be any problem to use >> UIO with DMA capable devices. > UIO doesn't enforce the IOMMU though. That's why it's not a good fit. Having said all that - does UIO denies to work with the devices with DMA capability today? Either i have missed that logic or it's not there. So all what u are so worried about may already be done today. That's why I don't understand why adding a support for MSI/MSI-X interrupts would change anything here. U are right that UIO *today* has a security hole however it should be addressed separately and the same solution that will cover the the security breach in the current code will cover the "MSI/MSI-X security vulnerability" because they are actually exactly the same issue. > >>>>> I don't think this can change. >>>> Given there is no PV IOMMU and even if there was it would be too slow for DPDK >>>> use, I can't accept that. >>> QEMU does allow emulating an iommu. >> Amazon's EC2 xen HV doesn't. At least today. Therefore VFIO is not an option >> there. > Not only that, a bunch of boxes have their IOMMU disabled. > So for such systems, you can't have userspace poking at > device registers. You need a kernel driver to validate > userspace requests before passing them on to devices. I think u are describing a HV functionality here. ;) And yes, u are absolutely right, HV has to control the non-privileged userland. For HV/non-virtualized boxes a possible solution could be to allow UIO only for some privileged group of processes. > >> And again, it's a general issue not DPDK specific. >> Today one has to develop some proprietary modules (like igb_uio) to >> workaround the issue and this is lame. > Of course it is lame. So don't bypass the kernel then, use the upstream drivers. This would impose a heavy performance penalty. The whole idea is to bypass kernel. Especially for networking... > >> IMHO uio_pci_generic should >> be fixed to be able to properly work within any virtualized environment and >> not only with KVM. > The motivation for UIO is pretty clear: > > For many types of devices, creating a Linux kernel driver is > overkill. All that is really needed is some way to handle an > interrupt and provide access to the memory space of the > device. The logic of controlling the device does not > necessarily have to be within the kernel, as the device does > not need to take advantage of any of other resources that the > kernel provides. One such common class of devices that are > like this are for industrial I/O cards. > > Devices doing DMA do need to take advantage of memory protection > that the kernel provides. Well, yeah - but who said I has to be forbidden to work with the device if MSI-X interrupts is my only option? Kernel may provide a protection in the way that it would check the process permissions and deny the UIO access to non-privileged processes. I'm not sure it's the case today and if it's not the case then, as mentioned above, this would rather be fixed ASAP exactly due to reasons u bring up here. And once it's done there shouldn't be any limitation to allow MSI or MSI-X interrupts along with INT#X. > >>> DPDK uses static mappings, so I >>> doubt it's speed matters at all. >>> >>> Anyway, DPDK is doing polling all the time. I don't see why does it >>> insist on using interrupts to detect link up events. Just poll for that >>> too. >>>