Message-ID: <b480fdcc-e08a-eea7-9bac-12bc236422c6@oracle.com>
Date:   Thu, 12 Jan 2017 09:50:35 -0700
From:   Khalid Aziz <khalid.aziz@...cle.com>
To:     Dave Hansen <dave.hansen@...ux.intel.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 05:49 PM, Dave Hansen wrote:
> 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.

Hi Dave,

You have brought up an interesting scenario with COW pages. I had 
started out with the following policies regarding ADI that made sense:

1. New data pages do not get full ADI protection by default, i.e. 
TTE.mcd is not set and tags are not set on the new pages. A task that 
creates a new data page must make decision to protect these new pages or 
not.

2. Any shared page that has ADI protection enabled on it, must stay ADI 
protected across all processes sharing it.

COW creates an intersection of the two. It creates a new copy of the 
shared data. It is a new data page and hence the process creating it 
must be the one responsible for enabling ADI protection on it. It is 
also a copy of what was ADI protected data, so should it inherit the 
protection instead?

I misspoke earlier. I had misinterpreted the results of test I ran. 
Changing the tag on shared memory is allowed by memory controller. The 
requirement is every one sharing the page must switch to the new tag or 
else they get SIGSEGV.

I am inclined to suggest we copy the tags to the new data page on COW 
and that will continue to enforce ADI on the COW'd pages even though 
COW'd pages are new data pages. This is the logically consistent 
behavior. Does that make sense?

Thanks,
Khalid

Powered by blists - more mailing lists