From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A944FC48BCF for ; Wed, 9 Jun 2021 15:51:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 93AD561078 for ; Wed, 9 Jun 2021 15:51:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237264AbhFIPx0 (ORCPT ); Wed, 9 Jun 2021 11:53:26 -0400 Received: from 8bytes.org ([81.169.241.247]:43546 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237156AbhFIPxX (ORCPT ); Wed, 9 Jun 2021 11:53:23 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 9B3CD434; Wed, 9 Jun 2021 17:51:27 +0200 (CEST) Date: Wed, 9 Jun 2021 17:51:26 +0200 From: Joerg Roedel To: Jason Gunthorpe Cc: "Tian, Kevin" , "Alex Williamson (alex.williamson@redhat.com)" , Jean-Philippe Brucker , David Gibson , Jason Wang , "parav@mellanox.com" , "Enrico Weigelt, metux IT consult" , Paolo Bonzini , Shenming Lu , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Kirti Wankhede , Robin Murphy , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" , David Woodhouse , LKML , Lu Baolu Subject: Re: Plan for /dev/ioasid RFC v2 Message-ID: References: <20210609123919.GA1002214@nvidia.com> <20210609150009.GE1002214@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210609150009.GE1002214@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote: > Only *drivers* know what the actual device is going to do, devices do > not. Since the group doesn't have drivers it is the wrong layer to be > making choices about how to configure the IOMMU. Groups don't carry how to configure IOMMUs, that information is mostly in the IOMMU domains. And those (or an abstraction of them) is configured through /dev/ioasid. So not sure what you wanted to say with the above. All a group carries is information about which devices are not sufficiently isolated from each other and thus need to always be in the same domain. > The device centric approach is my attempt at this, and it is pretty > clean, I think. Clean, but still insecure. > All ACS does is prevent P2P operations, if you assign all the group > devices into the same /dev/iommu then you may not care about that > security isolation property. At the very least it is policy for user > to decide, not kernel. It is a kernel decision, because a fundamental task of the kernel is to ensure isolation between user-space tasks as good as it can. And if a device assigned to one task can interfer with a device of another task (e.g. by sending P2P messages), then the promise of isolation is broken. > Groups should be primarily about isolation security, not about IOASID > matching. That doesn't make any sense, what do you mean by 'IOASID matching'? > Blocking this forever in the new uAPI just because group = IOASID is > some historical convenience makes no sense to me. I think it is safe to assume that devices supporting PASID will most often be the only ones in their group. But for the non-PASID IOASID use-cases like plain old device assignment to a VM it needs to be group-centric. Regards, Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_RED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CA27C48BCF for ; Wed, 9 Jun 2021 15:51:38 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C9456136D for ; Wed, 9 Jun 2021 15:51:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C9456136D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4A65640572; Wed, 9 Jun 2021 15:51:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F44o-_jvONDY; Wed, 9 Jun 2021 15:51:35 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id C230440292; Wed, 9 Jun 2021 15:51:34 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 871C5C000E; Wed, 9 Jun 2021 15:51:34 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CC2A8C000B for ; Wed, 9 Jun 2021 15:51:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B8B2440292 for ; Wed, 9 Jun 2021 15:51:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RwBG1Cowjp1 for ; Wed, 9 Jun 2021 15:51:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by smtp4.osuosl.org (Postfix) with ESMTPS id 5623F4055A for ; Wed, 9 Jun 2021 15:51:30 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 9B3CD434; Wed, 9 Jun 2021 17:51:27 +0200 (CEST) Date: Wed, 9 Jun 2021 17:51:26 +0200 From: Joerg Roedel To: Jason Gunthorpe Subject: Re: Plan for /dev/ioasid RFC v2 Message-ID: References: <20210609123919.GA1002214@nvidia.com> <20210609150009.GE1002214@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210609150009.GE1002214@nvidia.com> Cc: "kvm@vger.kernel.org" , Jason Wang , Kirti Wankhede , Jean-Philippe Brucker , "Jiang, Dave" , "Raj, Ashok" , Jonathan Corbet , "Tian, Kevin" , "parav@mellanox.com" , "Alex Williamson \(alex.williamson@redhat.com\)" , "Enrico Weigelt, metux IT consult" , David Gibson , Robin Murphy , LKML , Shenming Lu , "iommu@lists.linux-foundation.org" , Paolo Bonzini , David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote: > Only *drivers* know what the actual device is going to do, devices do > not. Since the group doesn't have drivers it is the wrong layer to be > making choices about how to configure the IOMMU. Groups don't carry how to configure IOMMUs, that information is mostly in the IOMMU domains. And those (or an abstraction of them) is configured through /dev/ioasid. So not sure what you wanted to say with the above. All a group carries is information about which devices are not sufficiently isolated from each other and thus need to always be in the same domain. > The device centric approach is my attempt at this, and it is pretty > clean, I think. Clean, but still insecure. > All ACS does is prevent P2P operations, if you assign all the group > devices into the same /dev/iommu then you may not care about that > security isolation property. At the very least it is policy for user > to decide, not kernel. It is a kernel decision, because a fundamental task of the kernel is to ensure isolation between user-space tasks as good as it can. And if a device assigned to one task can interfer with a device of another task (e.g. by sending P2P messages), then the promise of isolation is broken. > Groups should be primarily about isolation security, not about IOASID > matching. That doesn't make any sense, what do you mean by 'IOASID matching'? > Blocking this forever in the new uAPI just because group = IOASID is > some historical convenience makes no sense to me. I think it is safe to assume that devices supporting PASID will most often be the only ones in their group. But for the non-PASID IOASID use-cases like plain old device assignment to a VM it needs to be group-centric. Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu