lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Dec 2021 08:57:15 -0800
From:   "Raj, Ashok" <ashok.raj@...el.com>
To:     Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Joerg Roedel <joro@...tes.org>,
        Jason Gunthorpe <jgg@...dia.com>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>, Barry Song <21cnbao@...il.com>,
        "Zanussi, Tom" <tom.zanussi@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Ashok Raj <ashok.raj@...el.com>
Subject: Re: [PATCH 2/4] iommu: Add PASID support for DMA mapping API users

On Thu, Dec 09, 2021 at 08:32:49AM -0800, Jacob Pan wrote:
> Hi Lu,
> 
> On Thu, 9 Dec 2021 10:21:38 +0800, Lu Baolu <baolu.lu@...ux.intel.com>
> wrote:
> 
> > On 12/9/21 9:56 AM, Tian, Kevin wrote:
> > >> From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
> > >> Sent: Thursday, December 9, 2021 2:50 AM
> > >>  
> > >>> Can a device issue DMA requests with PASID even there's no system  
> > >> IOMMU  
> > >>> or the system IOMMU is disabled?
> > >>>  
> > >> Good point.
> > >> If IOMMU is not enabled, device cannot issue DMA requests with PASID.
> > >> This API will not be available. Forgot to add dummy functions to the
> > >> header. 
> > > 
> > > PASID is a PCI thing, not defined by IOMMU.

True, but RP is just a forwarding agent on these EETLP prefixes. I'm not
sure how RP's will behave if they receive a TLP they don't understand
and I suspect they might pull the system down via some UR type response
when IOMMU isn't enabled.

> > > 
> > > I think the key is physically if IOMMU is disabled, how will root
> > > complex handle a PCI memory request including a PASID TLP prefix? Does
> > > it block such request due to no IOMMU to consume PASID or simply ignore
> > > PASID and continue routing the request to the memory controller?
> > > 
> > > If block, then having an iommu interface makes sense.
> > > 
> > > If ignore, possibly a DMA API call makes more sense instead, implying
> > > that this extension can be used even when iommu is disabled.
> > > 
> > > I think that is what Baolu wants to point out.  
> > 
> Thanks for clarifying, very good point.
> Looking at the PCIe spec. I don't see specific rules for RC to ignore or
> block PASID TLP if not enabled.
> "- A Root Complex that supports PASID TLP Prefixes must have a device
> specific mechanism for enabling them. By default usage of PASID TLP
> Prefixes is disabled
>  - Root Complexes may optionally support TLPs with PASID TLP Prefixes. The
> mechanism used to detect whether a Root Complex supports the PASID TLP
> Prefix is implementation specific

Isn't implementation specific mechanism is IOMMU?

> "
> For all practical purposes, why would someone sets up PASID for DMA just to
> be ignored? An IOMMU interface makes sense to me.
> 
> > Yes, exactly. Imagining in the VM guest environment, do we require a
> > vIOMMU for this functionality? vIOMMU is not performance friendly if we
> > put aside the security considerations.
> > 
> The primary use case for accelerators to use in-kernel DMA will be in
> pass-through mode. vIOMMU should be able to do PT with good performance,
> right? no nesting, IO page faults.

But from an enabling perspective when PASID is in use we have to mandate
either the presence of an IOMMU, or some hypercall that will do the
required plumbing for PASID isn't it? 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ