linux-kernel - Re: [PATCHv8 00/11] Linear Address Masking enabling

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:   Wed, 21 Sep 2022 10:29:29 -0700
From:   Ashok Raj <ashok.raj@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>
CC:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Jacob Pan <jacob.jun.pan@...el.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Ashok Raj <ashok_raj@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Peter Zijlstra" <peterz@...radead.org>, <x86@...nel.org>,
        Kostya Serebryany <kcc@...gle.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        "Taras Madan" <tarasmadan@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "H . J . Lu" <hjl.tools@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        Jason Gunthorpe <jgg@...dia.com>,
        "Joerg Roedel" <joro@...tes.org>, Ashok Raj <ashok.raj@...el.com>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling

On Wed, Sep 21, 2022 at 10:11:46AM -0700, Dave Hansen wrote:
> On 9/21/22 10:08, Ashok Raj wrote:
> > On Wed, Sep 21, 2022 at 09:57:47AM -0700, Dave Hansen wrote:
> >> On 9/15/22 10:28, Kirill A. Shutemov wrote:> +	/* Serialize against
> >> address tagging enabling *
> >>> +	if (mmap_write_lock_killable(mm))
> >>> +		return -EINTR;
> >>> +
> >>> +	if (!arch_can_alloc_pasid(mm)) {
> >>> +		mmap_write_unlock(mm);
> >>> +		return -EBUSY;
> >>> +	}
> >> Shouldn't this actually be some kind of *device* check?
> > The device will enable svm only when its capable of it, and performs all
> > the normal capability checks like PASID, ATS etc before enabling it.
> > This is the final step before the mm is hooked up with the IOMMU.
> 
> What does that mean, though?
> 
> Are you saying that any device compatibility with an mm is solely
> determined by the IOMMU in play, so the IOMMU code should host the mm
> compatibility checks?
> 

To check if a device supports SVM like capabilities it needs to support
the following PCIe capabilities.

- PASID
- Page Request Interface (PRI) for dynamic page-faulting
- ATS - For quick VA->PA lookups.

The device purely works only with memory addresses and caches them in
its device TLB after a lookup via ATS. 

When device does ATS, it sends a translation request, and IOMMU will
walk the page-tables to give the PA back. It can use it until it gets an
invalidation. 

So the device doesn't need to know page-table formats. but if you use
tagged pointers its something you want to check device support for it. I
don't think there is any plans right now to support something like the
following.

- Check device ability to work with tagged pointers.
- OS should configure the width to ignore etc
- Device TLB's properly handle the tagged portion without creating
  aliasing etc.

In order for LAM and SVM to play nicely you need 

#1 IOMMU support for tagged pointers 
#2 Device ability to handle tagged pointers. 

#2 above is an additional check to perform in addition to PASID,PRI,ATS
   checks we do today.

Cheers,
Ashok