Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Steven Sistare]

On 9/6/2017 6:32 PM, Pavel Machek wrote:
> On Tue 2017-09-05 14:44:56, David Miller wrote:
>> From: Pavel Machek 
>> Date: Mon, 4 Sep 2017 18:25:30 +0200
>>
>>> Will gcc be able to compile code that uses these automatically? That
>>> does not sound easy to me. Can libc automatically use this in malloc()
>>> to prevent accessing freed data when buffers are overrun?
>>>
>>> Is this for benefit of JITs?
>>
>> Anything that can control mappings and the virtual address used to
>> access memory can use ADI.
>>
>> malloc() is of course one such case.  It can map memory with ADI
>> enabled, and return buffer addresses to malloc() callers with the
>> proper virtual address bits set to satisfy the ADI key checks.
>>
>> And by induction anything using malloc() for it's memory allocation
>> gets ADI protection as well.
> 
> I see; that's actually quite a nice trick.
> 
> I guess it does not protect against stack-based overflows, but should
> help against heap-based overflows, so it improves security a bit, too.
> 
> Nice, thanks for explanation.

ADI can also be used to protect the stack.  Modify ADI versions for
a 64B aligned portion of the register save area in the kernel spill
and fill handlers,  and accidental or malicious access to the area 
from userland will trap.  Other data on the stack can be corrupted, 
but one cannot linearly overflow into the next stack frame without 
tripping over the ADI canary.  There are a few other details to handle,
such as setjmp/longjmp and JITs that modify the stack, but that is the gist.  
This is not part of the current patch, but has been implemented on
Solaris.

ADI could protect other data on the stack, but that requires 
compiler code generation changes.

- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Pavel Machek]

On Tue 2017-09-05 14:44:56, David Miller wrote:
> From: Pavel Machek 
> Date: Mon, 4 Sep 2017 18:25:30 +0200
> 
> > Will gcc be able to compile code that uses these automatically? That
> > does not sound easy to me. Can libc automatically use this in malloc()
> > to prevent accessing freed data when buffers are overrun?
> > 
> > Is this for benefit of JITs?
> 
> Anything that can control mappings and the virtual address used to
> access memory can use ADI.
> 
> malloc() is of course one such case.  It can map memory with ADI
> enabled, and return buffer addresses to malloc() callers with the
> proper virtual address bits set to satisfy the ADI key checks.
> 
> And by induction anything using malloc() for it's memory allocation
> gets ADI protection as well.

I see; that's actually quite a nice trick.

I guess it does not protect against stack-based overflows, but should
help against heap-based overflows, so it improves security a bit, too.

Nice, thanks for explanation.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 09/04/2017 10:25 AM, Pavel Machek wrote:

Hi!


ADI is a new feature supported on SPARC M7 and newer processors to allow
hardware to catch rogue accesses to memory. ADI is supported for data
fetches only and not instruction fetches. An app can enable ADI on its
data pages, set version tags on them and use versioned addresses to
access the data pages. Upper bits of the address contain the version
tag. On M7 processors, upper four bits (bits 63-60) contain the version
tag. If a rogue app attempts to access ADI enabled data pages, its
access is blocked and processor generates an exception. Please see
Documentation/sparc/adi.txt for further details.


I'm afraid I still don't understand what this is meant to prevent.

IOMMU ignores these, so this is not to prevent rogue DMA from doing
bad stuff.

Will gcc be able to compile code that uses these automatically? That
does not sound easy to me. Can libc automatically use this in malloc()
to prevent accessing freed data when buffers are overrun?

Is this for benefit of JITs?



David explained it well. Yes, preventing buffer overflow is one of the 
uses of ADI. Protecting critical data from wild writes caused by 
programming errors is another use. ADI can be used for debugging as well 
during development.


Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Pavel Machek 
Date: Mon, 4 Sep 2017 18:25:30 +0200

> Will gcc be able to compile code that uses these automatically? That
> does not sound easy to me. Can libc automatically use this in malloc()
> to prevent accessing freed data when buffers are overrun?
> 
> Is this for benefit of JITs?

Anything that can control mappings and the virtual address used to
access memory can use ADI.

malloc() is of course one such case.  It can map memory with ADI
enabled, and return buffer addresses to malloc() callers with the
proper virtual address bits set to satisfy the ADI key checks.

And by induction anything using malloc() for it's memory allocation
gets ADI protection as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Anthony Yznaga]

Hi Khalid,

> On Aug 30, 2017, at 3:27 PM, Khalid Aziz  wrote:
> 
> Hi Anthony,
> 
> Thanks for taking the time to provide feedback. My comments inline below.
> 
> On 08/25/2017 04:31 PM, Anthony Yznaga wrote:
>>> On Aug 9, 2017, at 2:26 PM, Khalid Aziz  wrote:
>>> ..deleted..
>>> +provided by the hypervisor to the kernel.  Kernel returns the value of
>>> +ADI block size to userspace using auxiliary vector along with other ADI
>>> +info. Following auxiliary vectors are provided by the kernel:
>>> +
>>> +   AT_ADI_BLKSZADI block size. This is the granularity and
>>> +   alignment, in bytes, of ADI versioning.
>>> +   AT_ADI_NBITSNumber of ADI version bits in the VA
>> The previous patch series also defined AT_ADI_UEONADI.  Why was that
>> removed?
> 
> This was based upon a conversation we had when you mentioned future 
> processors may not implement this or change the way this is interpreted and 
> any applications depending upon this value would break at that point. I 
> removed it to eliminate building an unreliable dependency. If I misunderstood 
> what you said, please let me know.

On M7 there is an array of versions maintained for cachelines in the L2
cache. If a UE is detected in this array it results in the flush of all
eight ways of the array.  Clean lines go away, but dirty lines are
written back to memory with the version forced to 0xE.  The ue-on-adp MD
property communicates this tag value that may result from a UE in order
to give the guest the opportunity to avoid using the tag value.  An
application that intentionally used ADI in a way that relied on ADI
exceptions for its functionality may not want to have to consider
whether the mismatch was legitimate or due to a UE.

On M8 the HW implementation is changed and a tag value will never be
forced to another value.  That said, I think the ue-on-adp property
value was unfortunately inadvertently carried forward to M8.

It could probably be argued that the likelihood of seeing the UE is so
low that SW can ignore the possibility, but including the information
in an auxvec shouldn't break anything.


> 
>>> +
>>> +
>>> +IMPORTANT NOTES:
>>> +
>>> +- Version tag values of 0x0 and 0xf are reserved.
>> The documentation should probably state more specifically that an
>> in-memory tag value of 0x0 or 0xf is treated as "match all" by the HW
>> meaning that a mismatch exception will never be generated regardless
>> of the tag bits set in the VA accessing the memory.
> 
> Will do.
> 
>>> +
>>> +- Version tags are set on virtual addresses from userspace even though
>>> +  tags are stored in physical memory. Tags are set on a physical page
>>> +  after it has been allocated to a task and a pte has been created for
>>> +  it.
>>> +
>>> +- When a task frees a memory page it had set version tags on, the page
>>> +  goes back to free page pool. When this page is re-allocated to a task,
>>> +  kernel clears the page using block initialization ASI which clears the
>>> +  version tags as well for the page. If a page allocated to a task is
>>> +  freed and allocated back to the same task, old version tags set by the
>>> +  task on that page will no longer be present.
>> The specifics should be included here, too, so someone doesn't have
>> to guess what's going on if they make changes and the tags are no longer
>> cleared.  The HW clears the tag for a cacheline for block initializing
>> stores to 64-byte aligned addresses if PSTATE.mcde=0 or TTE.mcd=0.
>> PSTATE.mce is set when executing in the kernel, but pages are cleared
>> using kernel physical mapping VAs which are mapped with TTE.mcd=0.
>> Another HW behavior that should be mentioned is that tag mismatches
>> are not detected for non-faulting loads.
> 
> Sure, I can add that.
> 
>>> +
>>> +- Kernel does not set any tags for user pages and it is entirely a
>>> +  task's responsibility to set any version tags. Kernel does ensure the
>>> +  version tags are preserved if a page is swapped out to the disk and
>>> +  swapped back in. It also preserves that version tags if a page is
>>> +  migrated.
>> I only have a cursory understanding of how page migration works, but
>> I could not see how the tags would be preserved if a page were migrated.
>> I figured the place to copy the tags would be migrate_page_copy(), but
>> I don't see changes there.
> 
> For migrating user pages, the way I understand the code works is if the page 
> is mapped (which is the only time ADI tags are even in place), try_to_unmap() 
> is called with TTU_MIGRATION flag set. try_to_unmap() will call 
> arch_unmap_one() which saves the tags from currently mapped page. When the 
> new page has been allocated, contents of the old page are faulted in through 
> do_swap_page() which will call arch_do_swap_page(). arch_do_swap_page() then 
> restores the ADI tags.

My understanding from reading the code is that __unmap_and_move() calls
try_to_unmap() which unmaps the 

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 08/30/2017 06:09 PM, David Miller wrote:

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 17:23:37 -0600


That is an interesting idea. This would enable TSTATE_MCDE on all
threads of a process as soon as one thread enables it. If we consider
the case where the parent creates a shared memory area and spawns a
bunch of threads. These threads access the shared memory without ADI
enabled. Now one of the threads decides to enable ADI on the shared
memory. As soon as it does that, we enable TSTATE_MCDE across all
threads and since threads are all using the same TTE for the shared
memory, every thread becomes subject to ADI verification. If one of
the other threads was in the middle of accessing the shared memory, it
will get a sigsegv. If we did not enable TSTATE_MCDE across all
threads, it could have continued execution without fault. In other
words, updating TSTATE_MCDE across all threads will eliminate the
option of running some threads with ADI enabled and some not while
accessing the same shared memory. This could be necessary at least for
short periods of time before threads can communicate with each other
and all switch to accessing shared memory with ADI enabled using same
tag. Does that sound like a valid use case or am I off in the weeds
here?


A threaded application needs to synchronize and properly orchestrate
access to shared memory.

When a change is made to a mappping, in this case setting ADI
attributes, it's being done for the address space not the thread.

And the address space is shared amongst threads.

Therefore ADI is not really a per-thread property but rather
a per-address-space property.



That does make sense.

Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 17:23:37 -0600

> That is an interesting idea. This would enable TSTATE_MCDE on all
> threads of a process as soon as one thread enables it. If we consider
> the case where the parent creates a shared memory area and spawns a
> bunch of threads. These threads access the shared memory without ADI
> enabled. Now one of the threads decides to enable ADI on the shared
> memory. As soon as it does that, we enable TSTATE_MCDE across all
> threads and since threads are all using the same TTE for the shared
> memory, every thread becomes subject to ADI verification. If one of
> the other threads was in the middle of accessing the shared memory, it
> will get a sigsegv. If we did not enable TSTATE_MCDE across all
> threads, it could have continued execution without fault. In other
> words, updating TSTATE_MCDE across all threads will eliminate the
> option of running some threads with ADI enabled and some not while
> accessing the same shared memory. This could be necessary at least for
> short periods of time before threads can communicate with each other
> and all switch to accessing shared memory with ADI enabled using same
> tag. Does that sound like a valid use case or am I off in the weeds
> here?

A threaded application needs to synchronize and properly orchestrate
access to shared memory.

When a change is made to a mappping, in this case setting ADI
attributes, it's being done for the address space not the thread.

And the address space is shared amongst threads.

Therefore ADI is not really a per-thread property but rather
a per-address-space property.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 08/30/2017 04:38 PM, David Miller wrote:

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 16:27:54 -0600


+#define arch_calc_vm_prot_bits(prot, pkey)
sparc_calc_vm_prot_bits(prot)
+static inline unsigned long sparc_calc_vm_prot_bits(unsigned long
prot)
+{
+   if (prot & PROT_ADI) {
+   struct pt_regs *regs;
+
+   if (!current->mm->context.adi) {
+   regs = task_pt_regs(current);
+   regs->tstate |= TSTATE_MCDE;
+   current->mm->context.adi = true;

If a process is multi-threaded when it enables ADI on some memory for
the first time, TSTATE_MCDE will only be set for the calling thread
and it will not be possible to enable it for the other threads.
One possible way to handle this is to enable TSTATE_MCDE for all user
threads when they are initialized if adi_capable() returns true.



Or set TSTATE_MCDE unconditionally here by removing "if
(!current->mm->context.adi)"?


I think you have to make "ADI enabled" a property of the mm_struct.

Then you can broadcast to mm->cpu_vm_mask a per-cpu interrupt that
updates regs->tstate of a thread using 'mm' is currently executing.

And in the context switch code you set TSTATE_MCDE if it's not set
already.

That should cover all threaded case.


That is an interesting idea. This would enable TSTATE_MCDE on all 
threads of a process as soon as one thread enables it. If we consider 
the case where the parent creates a shared memory area and spawns a 
bunch of threads. These threads access the shared memory without ADI 
enabled. Now one of the threads decides to enable ADI on the shared 
memory. As soon as it does that, we enable TSTATE_MCDE across all 
threads and since threads are all using the same TTE for the shared 
memory, every thread becomes subject to ADI verification. If one of the 
other threads was in the middle of accessing the shared memory, it will 
get a sigsegv. If we did not enable TSTATE_MCDE across all threads, it 
could have continued execution without fault. In other words, updating 
TSTATE_MCDE across all threads will eliminate the option of running some 
threads with ADI enabled and some not while accessing the same shared 
memory. This could be necessary at least for short periods of time 
before threads can communicate with each other and all switch to 
accessing shared memory with ADI enabled using same tag. Does that sound 
like a valid use case or am I off in the weeds here?


Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 16:27:54 -0600

>>> +#define arch_calc_vm_prot_bits(prot, pkey)
>>> sparc_calc_vm_prot_bits(prot)
>>> +static inline unsigned long sparc_calc_vm_prot_bits(unsigned long
>>> prot)
>>> +{
>>> +   if (prot & PROT_ADI) {
>>> +   struct pt_regs *regs;
>>> +
>>> +   if (!current->mm->context.adi) {
>>> +   regs = task_pt_regs(current);
>>> +   regs->tstate |= TSTATE_MCDE;
>>> +   current->mm->context.adi = true;
>> If a process is multi-threaded when it enables ADI on some memory for
>> the first time, TSTATE_MCDE will only be set for the calling thread
>> and it will not be possible to enable it for the other threads.
>> One possible way to handle this is to enable TSTATE_MCDE for all user
>> threads when they are initialized if adi_capable() returns true.
>> 
> 
> Or set TSTATE_MCDE unconditionally here by removing "if
> (!current->mm->context.adi)"?

I think you have to make "ADI enabled" a property of the mm_struct.

Then you can broadcast to mm->cpu_vm_mask a per-cpu interrupt that
updates regs->tstate of a thread using 'mm' is currently executing.

And in the context switch code you set TSTATE_MCDE if it's not set
already.

That should cover all threaded case.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

On 08/15/2017 10:58 PM, David Miller wrote:

From: Khalid Aziz 
Date: Wed,  9 Aug 2017 15:26:02 -0600


+void adi_restore_tags(struct mm_struct *mm, struct vm_area_struct *vma,
+ unsigned long addr, pte_t pte)
+{

  ...

+   tag = tag_start(addr, tag_desc);
+   paddr = pte_val(pte) & _PAGE_PADDR_4V;
+   for (tmp = paddr; tmp < (paddr+PAGE_SIZE); tmp += adi_blksize()) {
+   version1 = (*tag) >> 4;
+   version2 = (*tag) & 0x0f;
+   *tag++ = 0;
+   asm volatile("stxa %0, [%1] %2\n\t"
+   :
+   : "r" (version1), "r" (tmp),
+ "i" (ASI_MCD_REAL));
+   tmp += adi_blksize();
+   asm volatile("stxa %0, [%1] %2\n\t"
+   :
+   : "r" (version2), "r" (tmp),
+ "i" (ASI_MCD_REAL));
+   }
+   asm volatile("membar #Sync\n\t");


You do a membar here.


+   for (i = pfrom; i < (pfrom + PAGE_SIZE); i += adi_blksize()) {
+   asm volatile("ldxa [%1] %2, %0\n\t"
+   : "=r" (adi_tag)
+   :  "r" (i), "i" (ASI_MCD_REAL));
+   asm volatile("stxa %0, [%1] %2\n\t"
+   :
+   : "r" (adi_tag), "r" (pto),
+ "i" (ASI_MCD_REAL));


But not here.

Is this OK?  I suspect you need to add a membar this this second piece
of MCD tag storing code.


Hi Dave,

You are right. This tag storing code needs membar as well. I will add that.

Thanks,
Khalid

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed,  9 Aug 2017 15:26:02 -0600

> +void adi_restore_tags(struct mm_struct *mm, struct vm_area_struct *vma,
> +   unsigned long addr, pte_t pte)
> +{
 ...
> + tag = tag_start(addr, tag_desc);
> + paddr = pte_val(pte) & _PAGE_PADDR_4V;
> + for (tmp = paddr; tmp < (paddr+PAGE_SIZE); tmp += adi_blksize()) {
> + version1 = (*tag) >> 4;
> + version2 = (*tag) & 0x0f;
> + *tag++ = 0;
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (version1), "r" (tmp),
> +   "i" (ASI_MCD_REAL));
> + tmp += adi_blksize();
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (version2), "r" (tmp),
> +   "i" (ASI_MCD_REAL));
> + }
> + asm volatile("membar #Sync\n\t");

You do a membar here.

> + for (i = pfrom; i < (pfrom + PAGE_SIZE); i += adi_blksize()) {
> + asm volatile("ldxa [%1] %2, %0\n\t"
> + : "=r" (adi_tag)
> + :  "r" (i), "i" (ASI_MCD_REAL));
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (adi_tag), "r" (pto),
> +   "i" (ASI_MCD_REAL));

But not here.

Is this OK?  I suspect you need to add a membar this this second piece
of MCD tag storing code.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[Khalid Aziz]

ADI is a new feature supported on SPARC M7 and newer processors to allow
hardware to catch rogue accesses to memory. ADI is supported for data
fetches only and not instruction fetches. An app can enable ADI on its
data pages, set version tags on them and use versioned addresses to
access the data pages. Upper bits of the address contain the version
tag. On M7 processors, upper four bits (bits 63-60) contain the version
tag. If a rogue app attempts to access ADI enabled data pages, its
access is blocked and processor generates an exception. Please see
Documentation/sparc/adi.txt for further details.

This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable
MCD (Memory Corruption Detection) on selected memory ranges, enable
TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI
version tags on page swap out/in or migration. ADI is not enabled by
default for any task. A task must explicitly enable ADI on a memory
range and set version tag for ADI to be effective for the task.

Signed-off-by: Khalid Aziz 
Cc: Khalid Aziz 
---
v7:
- Enhanced arch_validate_prot() to enable ADI only on writable
  addresses backed by physical RAM
- Added support for saving/restoring ADI tags for each ADI
  block size address range on a page on swap in/out
- Added code to copy ADI tags on COW
- Updated values for auxiliary vectors to not conflict with
  values on other architectures to avoid conflict in glibc. glibc
  consolidates all auxiliary vectors into its headers and
  duplicate values in consolidated header are problematic
- Disable same page merging on ADI enabled pages since ADI tags
  may not match on pages with identical data
- Broke the patch up further into smaller patches

v6:
- Eliminated instructions to read and write PSTATE as well as
  MCDPER and PMCDPER on every access to userspace addresses
  by setting PSTATE and PMCDPER correctly upon entry into
  kernel. PSTATE.mcde and PMCDPER are set upon entry into
  kernel when running on an M7 processor. PSTATE.mcde being
  set only affects memory accesses that have TTE.mcd set.
  PMCDPER being set only affects writes to memory addresses
  that have TTE.mcd set. This ensures any faults caused by
  ADI tag mismatch on a write are exposed before kernel returns
  to userspace.

v5:
- Fixed indentation issues and instrcuctions in assembly code
- Removed CONFIG_SPARC64 from mdesc.c
- Changed to maintain state of MCDPER register in thread info
  flags as opposed to in mm context. MCDPER is a per-thread
  state and belongs in thread info flag as opposed to mm context
  which is shared across threads. Added comments to clarify this
  is a lazily maintained state and must be updated on context
  switch and copy_process()
- Updated code to use the new arch_do_swap_page() and
  arch_unmap_one() functions

v4:
- Broke patch up into smaller patches

v3:
- Removed CONFIG_SPARC_ADI
- Replaced prctl commands with mprotect
- Added auxiliary vectors for ADI parameters
- Enabled ADI for swappable pages

v2:
- Fixed a build error

 Documentation/sparc/adi.txt | 272 +++
 arch/sparc/include/asm/mman.h   |  72 -
 arch/sparc/include/asm/mmu_64.h |  17 ++
 arch/sparc/include/asm/mmu_context_64.h |  43 +
 arch/sparc/include/asm/page_64.h|   4 +
 arch/sparc/include/asm/pgtable_64.h |  46 ++
 arch/sparc/include/asm/thread_info_64.h |   2 +-
 arch/sparc/include/asm/trap_block.h |   2 +
 arch/sparc/include/uapi/asm/mman.h  |   2 +
 arch/sparc/kernel/adi_64.c  | 277 
 arch/sparc/kernel/etrap_64.S|  28 +++-
 arch/sparc/kernel/process_64.c  |  25 +++
 arch/sparc/kernel/setup_64.c|  11 +-
 arch/sparc/kernel/vmlinux.lds.S |   5 +
 arch/sparc/mm/gup.c |  37 +
 arch/sparc/mm/hugetlbpage.c |  14 +-
 arch/sparc/mm/init_64.c |  33 
 arch/sparc/mm/tsb.c |  21 +++
 include/linux/mm.h  |   3 +
 mm/ksm.c|   4 +
 20 files changed, 913 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/sparc/adi.txt

diff --git a/Documentation/sparc/adi.txt b/Documentation/sparc/adi.txt
new file mode 100644
index ..383bc65fec1e
--- /dev/null
+++ b/Documentation/sparc/adi.txt
@@ -0,0 +1,272 @@
+Application Data Integrity (ADI)
+
+
+SPARC M7 processor adds the Application Data Integrity (ADI) feature.
+ADI allows a task to set version tags on any subset of its address
+space. Once ADI is enabled and