From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <vladz@cloudius-systems.com>
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 <dev@dpdk.org>; Wed, 30 Sep 2015 21:10:59 +0200 (CEST)
Received: by wicgb1 with SMTP id gb1so209508585wic.1
for <dev@dpdk.org>; Wed, 30 Sep 2015 12:10:59 -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=Gkrmk9eUyH11HgE/RKVQgFc/G/yxZgAnIbPyxmF6L0A=;
b=L4qoBOPTaf04m9pG4oK1QU8vpATXfO7HFF1XZevRIU90qp2N74mkb9N98w68KeU7fk
X8EaOmPE/s3/VAPgj4hQZxUdljyJ5w6Pl+TBSgQIG58OJ3N+/RAHMyIate3NWVL1kJvK
G4P2Yg+kNLp2nOBrIOeUB2UFcYJOw03kST7pSkPtnJyLFxr4zvy7SFz/RKsLkcb6wAJY
bGh/tgVS1IOoKS8nApViMd4QVeSsIROHLym6F8gDhJ85z22ZUsw9hhEpwE8TrZhbutHU
d/Uirt2cqMfzO5S4F4cN+XtQXzXD5/ewg1Wz6TJcixb80UAhiMnPBNjxnUNpv8G1+3G1
nV4Q==
X-Gm-Message-State: ALoCoQm5yHEI/bmKVXXf5Zs+mqXGl4FooBav0X/rUT/ZNHW+hOKfdOEvIVkPlZ535fAqBCYKOlHk
X-Received: by 10.181.8.72 with SMTP id di8mr6809891wid.62.1443640259236;
Wed, 30 Sep 2015 12:10:59 -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 xa5sm2143070wjc.20.2015.09.30.12.10.58
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 30 Sep 2015 12:10:58 -0700 (PDT)
To: "Michael S. Tsirkin" <mst@redhat.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>
From: Vlad Zolotarov <vladz@cloudius-systems.com>
Message-ID: <560C33C1.7030202@cloudius-systems.com>
Date: Wed, 30 Sep 2015 22:10:57 +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: <560C32CC.90708@cloudius-systems.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 19:10:59 -0000
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).
>>
>