Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]