From: Khalid Aziz <khalid.aziz@oracle.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
davem@davemloft.net, corbet@lwn.net, arnd@arndb.de,
akpm@linux-foundation.org
Cc: hpa@zytor.com, viro@zeniv.linux.org.uk, nitin.m.gupta@oracle.com,
chris.hyser@oracle.com, tushar.n.dave@oracle.com,
sowmini.varadhan@oracle.com, mike.kravetz@oracle.com,
adam.buchbinder@gmail.com, minchan@kernel.org, hughd@google.com,
kirill.shutemov@linux.intel.com, keescook@chromium.org,
allen.pais@oracle.com, aryabinin@virtuozzo.com,
atish.patra@oracle.com, joe@perches.com, pmladek@suse.com,
jslaby@suse.cz, cmetcalf@mellanox.com,
paul.gortmaker@windriver.com, mhocko@suse.com,
jmarchan@redhat.com, lstoakes@gmail.com, 0x7f454c46@gmail.com,
vbabka@suse.cz, tglx@linutronix.de, mingo@redhat.com,
dan.j.williams@intel.com, iamjoonsoo.kim@lge.com,
mgorman@techsingularity.net, vdavydov.dev@gmail.com,
hannes@cmpxchg.org, namit@vmware.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7
Date: Wed, 11 Jan 2017 17:22:06 -0700 [thread overview]
Message-ID: <5d28f71e-1ad2-b2f9-1174-ea4eb6399d23@oracle.com> (raw)
In-Reply-To: <558ad70b-4b19-3a78-038a-b12dc7af8585@linux.intel.com>
On 01/11/2017 12:11 PM, Dave Hansen wrote:
> On 01/11/2017 10:50 AM, Khalid Aziz wrote:
>> On 01/11/2017 11:13 AM, Dave Hansen wrote:
>>> On 01/11/2017 08:56 AM, Khalid Aziz wrote:
>>> For memory shared by two different processes, do they have to agree on
>>> what the tags are, or can they differ?
>>
>> The two processes have to agree on the tag. This is part of the security
>> design to prevent other processes from accessing pages belonging to
>> another process unless they know the tag set on those pages.
>
> So what do you do with static data, say from a shared executable? You
> need to ensure that two different processes from two different privilege
> domains can't set different tags on the same physical memory. That
> would seem to mean that you must not allow tags to be set of memory
> unless you have write access to it. Or, you have to ensure that any
> file that you might want to use this feature on is entirely unreadable
> (well, un-mmap()-able really) by anybody that you are not coordinating with.
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.
>
> 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.
This wouldn't change with ADI as far as private copies are concerned.
Please do correct me if I get something wrong here. Quick tests with COW
data show everything working as expected but your asking about COW has
raised a few questions in my own mind. I am researching through docs and
running experiments to validate my thinking and I will give you more
definite information on whether COW would mess ADI up.
Thanks,
Khalid
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-01-12 0:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 16:12 Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 2/4] mm: Add function to support extra actions on swap in/out Khalid Aziz
2017-01-11 16:56 ` Dave Hansen
2017-01-11 17:15 ` Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 4/4] sparc64: Add support for ADI (Application Data Integrity) Khalid Aziz
2017-01-17 4:39 ` David Miller
2017-01-17 19:32 ` Khalid Aziz
2017-01-17 19:42 ` David Miller
2017-01-17 20:12 ` Khalid Aziz
2017-01-18 0:14 ` Khalid Aziz
2017-01-11 16:33 ` [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7 Dave Hansen
2017-01-11 16:56 ` Khalid Aziz
2017-01-11 18:13 ` Dave Hansen
2017-01-11 18:50 ` Khalid Aziz
2017-01-11 19:11 ` Dave Hansen
2017-01-12 0:22 ` Khalid Aziz [this message]
2017-01-12 0:49 ` Dave Hansen
2017-01-12 16:50 ` Khalid Aziz
2017-01-12 17:53 ` Dave Hansen
2017-01-13 0:22 ` Khalid Aziz
2017-01-13 1:31 ` Rob Gardner
2017-01-13 14:48 ` Khalid Aziz
2017-01-13 15:29 ` Rob Gardner
2017-01-13 15:59 ` Khalid Aziz
2017-01-13 16:08 ` Dave Hansen
2017-01-13 17:36 ` Rob Gardner
2017-01-17 4:47 ` David Miller
2017-01-17 21:43 ` Khalid Aziz
2017-01-17 4:42 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d28f71e-1ad2-b2f9-1174-ea4eb6399d23@oracle.com \
--to=khalid.aziz@oracle.com \
--cc=0x7f454c46@gmail.com \
--cc=adam.buchbinder@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=allen.pais@oracle.com \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=atish.patra@oracle.com \
--cc=chris.hyser@oracle.com \
--cc=cmetcalf@mellanox.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jmarchan@redhat.com \
--cc=joe@perches.com \
--cc=jslaby@suse.cz \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=nitin.m.gupta@oracle.com \
--cc=paul.gortmaker@windriver.com \
--cc=pmladek@suse.com \
--cc=sowmini.varadhan@oracle.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tushar.n.dave@oracle.com \
--cc=vbabka@suse.cz \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox