Message-ID: <a7ab2796-d777-df7b-2372-2d76f2906ead@linux.intel.com>
Date:   Wed, 11 Jan 2017 16:49:05 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Khalid Aziz <khalid.aziz@...cle.com>, davem@...emloft.net,
        corbet@....net, arnd@...db.de, akpm@...ux-foundation.org
Cc:     hpa@...or.com, viro@...iv.linux.org.uk, nitin.m.gupta@...cle.com,
        chris.hyser@...cle.com, tushar.n.dave@...cle.com,
        sowmini.varadhan@...cle.com, mike.kravetz@...cle.com,
        adam.buchbinder@...il.com, minchan@...nel.org, hughd@...gle.com,
        kirill.shutemov@...ux.intel.com, keescook@...omium.org,
        allen.pais@...cle.com, aryabinin@...tuozzo.com,
        atish.patra@...cle.com, joe@...ches.com, pmladek@...e.com,
        jslaby@...e.cz, cmetcalf@...lanox.com,
        paul.gortmaker@...driver.com, mhocko@...e.com, jmarchan@...hat.com,
        lstoakes@...il.com, 0x7f454c46@...il.com, vbabka@...e.cz,
        tglx@...utronix.de, mingo@...hat.com, dan.j.williams@...el.com,
        iamjoonsoo.kim@....com, mgorman@...hsingularity.net,
        vdavydov.dev@...il.com, hannes@...xchg.org, namit@...are.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-arch@...r.kernel.org,
        x86@...nel.org, linux-mm@...ck.org
Subject: Re: [PATCH v4 0/4] Application Data Integrity feature introduced by
 SPARC M7

On 01/11/2017 04:22 PM, Khalid Aziz wrote:
...
> All of the tag coordination can happen in userspace. Once a process sets
> a tag on a physical page mapped in its address space, another process
> that has mapped the same physical page in its address space can only set
> the tag to exact same value. Attempts to set a different tag are caught
> by memory controller and result in MCD trap and kernel sends SIGSEGV to
> the process trying to set a different tag.

Again, I don't think these semantics will work for anything other than
explicitly shared memory.  This behavior ensures that it is *entirely*
unsafe to use ADI on any data that any process you do not control might
be able to mmap().  That's a *HUGE* caveat for the feature and can't
imagine ever seeing this get merged without addressing it.

I think it's fairly simple to address, though a bit expensive.  First,
you can't allow the VMA bit to get set on non-writable mappings.
Second, you'll have to force COW to occur on read-only pages in writable
mappings before the PTE bit can get set.  I think you can probably even
do this in the faults that presumably occur when you try to set ADI tags
on memory mapped with non-ADI PTEs.

>> If you want to use it on copy-on-write'able data, you've got to ensure
>> that you've got entirely private copies.  I'm not sure we even have an
>> interface to guarantee that.  How could this work after a fork() on
>> un-COW'd, but COW'able data?
> 
> On COW, kernel maps the the source and destination pages with
> kmap_atomic() and copies the data over to the new page and the new page
> wouldn't be ADI protected unless the child process chooses to do so.

What do you mean by "ADI protection"?

I think of ADI _protection_ as coming from the PTE and/or VMA bits.
Those are copied at fork() from the old VMA to the new one.  Is there a
reason the child won't implicitly inherit these that I missed?

Whether the parent or the child does the COW fault is basically random.
Whether they get the ADI-tagged page, or the non-ADI-tagged copy is thus
effectively random.  Assuming that the new page has its tags cleared
(and thus is tagged not to be protected), whether your data continues to
be protected or not after a fork() is random.

That doesn't seem like workable behavior.

Powered by blists - more mailing lists