From mboxrd@z Thu Jan 1 00:00:00 1970 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 AF4DB11A2 for ; Wed, 30 Sep 2015 14:50:11 +0200 (CEST) Received: by wicfx3 with SMTP id fx3so60134495wic.0 for ; Wed, 30 Sep 2015 05:50:11 -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=NpqPegHhj7T5EfPkaLdT3bxrQjE8G74w4dOBWoZh6Ko=; b=GQCuKng+EiGuGFt/2KwSrLOJvUBRgJMFDewCxBCkNDdmE5WWr4e7CUmRNmgr98+D8j BHLGGNmD39IDG3oFOvsFlmzESi8Edn4oTsqZcv0jQVQuClF/0G7vUjLKvEClHWNgU1fW J8eAzuWZleXHqiIqHxQffWpWXavlv1Ou4mksUVffxwfvtJEbvZ1s3E3Y175D2+1NRuLo 8Jmszz0PwzW4UY91VGr9aRnGOFTKqQhj9rPVvB5Rfp7K5/VGlV3i3L7Tz3Y4xcxiLN+S U7rEYVevJah90und3+kN1H7Nbnzi63geM/d9gfw+59tXiqfWzH3XyaaFfaiUnvlA8Rz4 xh5w== X-Gm-Message-State: ALoCoQkgPGC2aeSpY7ARwXLJf8GEE6vrG/tua/vlPCtT4FPNZuJ2hjEODEdjJhnj9toaLL4peYAA X-Received: by 10.194.118.5 with SMTP id ki5mr3957491wjb.94.1443617411427; Wed, 30 Sep 2015 05:50:11 -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 lf10sm502156wjb.23.2015.09.30.05.50.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 05:50:10 -0700 (PDT) To: "Michael S. Tsirkin" References: <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> <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> From: Vlad Zolotarov Message-ID: <560BDA81.6070807@cloudius-systems.com> Date: Wed, 30 Sep 2015 15:50:09 +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: <20150930151632-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 12:50:12 -0000 On 09/30/15 15:27, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote: >> >> On 09/30/15 15:03, Michael S. Tsirkin wrote: >>> On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote: >>>> On 09/30/15 14:41, Michael S. Tsirkin wrote: >>>>> On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote: >>>>>> The whole idea is to bypass kernel. Especially for networking... >>>>> ... on dumb hardware that doesn't support doing that securely. >>>> On a very capable HW that supports whatever security requirements needed >>>> (e.g. 82599 Intel's SR-IOV VF devices). >>> Network card type is irrelevant as long as you do not have an IOMMU, >>> otherwise you would just use e.g. VFIO. >> Sorry, but I don't follow your logic here - Amazon EC2 environment is a >> example where there *is* iommu but it's not virtualized >> and thus VFIO is >> useless and there is an option to use directly assigned SR-IOV networking >> device there where using the kernel drivers impose a performance impact >> compared to user space UIO-based user space kernel bypass mode of usage. How >> is it irrelevant? Could u, pls, clarify your point? >> > So it's not even dumb hardware, it's another piece of software > that forces an "all or nothing" approach where either > device has access to all VM memory, or none. > And this, unfortunately, leaves you with no secure way to > allow userspace drivers. UIO is not secure even today so what are we arguing about? ;) Adding MSI/MSI-X support won't change this state, so, pls., discard the security argument unless u thing that UIO is completely secure piece of software today. In the later case, could u, pls., clarify what would prevent the userspace program to configure a DMA controller via registers and do whatever it wants? How not virtualizing iommu forces "all or nothing" approach? What insecure in relying on HV to control the iommu and not letting the VF any access to it? As far as I see it - there isn't any security problem here at all. The only problem I see here is that dumb current uio_pci_generic implementation forces people to go and invent the workarounds instead of having a proper MSI/MSI-X support implemented. And as I've mentioned above it has nothing to do with security because there is no such thing as security (on the UIO driver level) when we talk about UIO - it has to be ensured by some other entity like HV. > > So it makes even less sense to add insecure work-arounds in the kernel. > It seems quite likely that by the time the new kernel reaches > production X years from now, EC2 will have a virtual iommu. I'd bet that new kernel would reach production long before Amazon does that... ;) > > >>>>> Colour me unimpressed. >>>>>