linux-kernel - RE: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dd52760ab65a40328b4c1a26ddd0e1d0@intel.com>
Date:   Thu, 13 May 2021 16:44:14 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     Christoph Hellwig <hch@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Joerg Roedel <joro@...tes.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "wangzhou1@...ilicon.com" <wangzhou1@...ilicon.com>,
        "zhangfei.gao@...aro.org" <zhangfei.gao@...aro.org>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        David Woodhouse <dwmw2@...radead.org>
Subject: RE: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit
 flags

> For shared workqueue, it can only generate DMA request with PASID. The
> submission is done by ENQCMDS (S for supervisor) instruction.
>
> If we were not to share page tables with init_mm, we need a system PASID
> that doing the same direct mapping in IOMMU page tables.

Note that for the currently envisioned kernel use cases for accelerators it
would be OK for this system PASID to just provide either:

1) A 1:1 mapping for physical addresses.  Kernel users of the accelerators
  would provide physical addresses in descriptors.
2) The same mapping that the kernel uses for its "1:1" map of all physical
    memory. Users would use kernel virtual addresses in that "1:1" range
    (e.g. those obtained from page_to_virt(struct page *p);)

If people want to use an accelerator on memory allocated by vmalloc()
things will get more complicated. But maybe we can delay solving that
problem until someone comes up with a real use case that needs to
do this?

-Tony