Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Rob Gardner 

On 01/06/2017 10:18 AM, Khalid Aziz wrote:

On 01/06/2017 10:54 AM, Rob Gardner wrote:

On 01/06/2017 09:10 AM, Khalid Aziz wrote:

On 01/06/2017 10:02 AM, David Miller wrote:

From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800


Actually, that reminds me...  How does your code interface with
ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?


This reminds me, I consider this feature potentially extremely useful
for
kernel debugging.  So I would like to make sure we don't implement
anything
in a way which would preclude that in the long term.


I agree and please do point out if I have made any implementation
decisions that could preclude that.

Thanks,
Khalid



Khalid, I have already pointed out an implementation decision that
interferes with the potential for kernel debugging with ADI: lazy
clearing of version tags.


This does not preclude kernel debugging. If kernel debugging ends up 
requiring tags be cleared whenever a page is freed, we can add that 
code as part of kernel debugging support code and enable it 
conditionally only when kernel is being debugged. Forcing every task 
to incur the large cost of clearing tags on every "free" all the time 
is just not an acceptable cost only to support kernel debugging. It 
should be a dynamic switch to be toggled on only when debugging 
kernel. PSTATE.mcde being set is not enough to trigger a trap. It is 
easy enough to clear TTE.mcd before block initialization of a page and 
avoid a trap due to tag mismatch, or just use physical address with 
block initialization.


We can evaluate all of these options when we get to implementing 
kernel debugging using ADI.


I didn't say it precludes kernel debugging, just that it interferes, and 
there will be additional work to do if we want kernel debugging 
capability with ADI.


Rob





Thanks,
Khalid




Details: when memory is "freed" the version tags are left alone, as it
is an expensive operation to go through the memory and clear the tag for
each cache line. So this is done lazily whenever memory is "allocated".
More specifically, the first time a user process touches freshly
allocated memory, a fault occurs and the kernel then clears the page. In
the NG4 and M7 variants of clear_user_page, the block init store ASI is
used to optimize, and it has the side effect of clearing the ADI tag for
the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set,
then instead of the ADI tag being cleared, the tag is *checked*, and if
there is a mismatch between the version in the virtual address and the
version in memory, then you'll get a trap and panic. Therefore, with
this design, you cannot have pstate.mcde enabled while in the kernel (in
general). To solve this you have to check the state of pstate.mcde (or
just turn it off) before doing any block init store in clear_user_page,
memset, memcpy, etc.

Rob

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


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


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Khalid Aziz 

On 01/06/2017 10:54 AM, Rob Gardner wrote:

On 01/06/2017 09:10 AM, Khalid Aziz wrote:

On 01/06/2017 10:02 AM, David Miller wrote:

From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800


Actually, that reminds me...  How does your code interface with
ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?


This reminds me, I consider this feature potentially extremely useful
for
kernel debugging.  So I would like to make sure we don't implement
anything
in a way which would preclude that in the long term.


I agree and please do point out if I have made any implementation
decisions that could preclude that.

Thanks,
Khalid



Khalid, I have already pointed out an implementation decision that
interferes with the potential for kernel debugging with ADI: lazy
clearing of version tags.


This does not preclude kernel debugging. If kernel debugging ends up 
requiring tags be cleared whenever a page is freed, we can add that code 
as part of kernel debugging support code and enable it conditionally 
only when kernel is being debugged. Forcing every task to incur the 
large cost of clearing tags on every "free" all the time is just not an 
acceptable cost only to support kernel debugging. It should be a dynamic 
switch to be toggled on only when debugging kernel. PSTATE.mcde being 
set is not enough to trigger a trap. It is easy enough to clear TTE.mcd 
before block initialization of a page and avoid a trap due to tag 
mismatch, or just use physical address with block initialization.


We can evaluate all of these options when we get to implementing kernel 
debugging using ADI.


Thanks,
Khalid




Details: when memory is "freed" the version tags are left alone, as it
is an expensive operation to go through the memory and clear the tag for
each cache line. So this is done lazily whenever memory is "allocated".
More specifically, the first time a user process touches freshly
allocated memory, a fault occurs and the kernel then clears the page. In
the NG4 and M7 variants of clear_user_page, the block init store ASI is
used to optimize, and it has the side effect of clearing the ADI tag for
the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set,
then instead of the ADI tag being cleared, the tag is *checked*, and if
there is a mismatch between the version in the virtual address and the
version in memory, then you'll get a trap and panic. Therefore, with
this design, you cannot have pstate.mcde enabled while in the kernel (in
general). To solve this you have to check the state of pstate.mcde (or
just turn it off) before doing any block init store in clear_user_page,
memset, memcpy, etc.

Rob

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


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Rob Gardner 

On 01/06/2017 09:10 AM, Khalid Aziz wrote:

On 01/06/2017 10:02 AM, David Miller wrote:

From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800

Actually, that reminds me...  How does your code interface with 
ksm?  Or

is there no interaction needed since you're always working on virtual
addresses?


This reminds me, I consider this feature potentially extremely useful 
for
kernel debugging.  So I would like to make sure we don't implement 
anything

in a way which would preclude that in the long term.


I agree and please do point out if I have made any implementation 
decisions that could preclude that.


Thanks,
Khalid



Khalid, I have already pointed out an implementation decision that 
interferes with the potential for kernel debugging with ADI: lazy 
clearing of version tags.


Details: when memory is "freed" the version tags are left alone, as it 
is an expensive operation to go through the memory and clear the tag for 
each cache line. So this is done lazily whenever memory is "allocated". 
More specifically, the first time a user process touches freshly 
allocated memory, a fault occurs and the kernel then clears the page. In 
the NG4 and M7 variants of clear_user_page, the block init store ASI is 
used to optimize, and it has the side effect of clearing the ADI tag for 
the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set, 
then instead of the ADI tag being cleared, the tag is *checked*, and if 
there is a mismatch between the version in the virtual address and the 
version in memory, then you'll get a trap and panic. Therefore, with 
this design, you cannot have pstate.mcde enabled while in the kernel (in 
general). To solve this you have to check the state of pstate.mcde (or 
just turn it off) before doing any block init store in clear_user_page, 
memset, memcpy, etc.


Rob

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Khalid Aziz 

On 01/06/2017 10:02 AM, David Miller wrote:

From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800


Actually, that reminds me...  How does your code interface with ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?


This reminds me, I consider this feature potentially extremely useful for
kernel debugging.  So I would like to make sure we don't implement anything
in a way which would preclude that in the long term.


I agree and please do point out if I have made any implementation 
decisions that could preclude 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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Khalid Aziz 

On 01/06/2017 09:55 AM, Dave Hansen wrote:

On 01/06/2017 08:22 AM, Khalid Aziz wrote:

On 01/06/2017 08:36 AM, Dave Hansen wrote:

On 01/06/2017 07:32 AM, Khalid Aziz wrote:

I agree with you on simplicity first. Subpage granularity is complex,
but the architecture allows for subpage granularity. Maybe the right
approach is to support this at page granularity first for swappable
pages and then expand to subpage granularity in a subsequent patch?
Pages locked in memory can already use subpage granularity with my
patch.


What do you mean by "locked in memory"?  mlock()'d memory can still be
migrated around and still requires "swap" ptes, for instance.


You are right. Page migration can invalidate subpage granularity even
for locked pages. Is it possible to use cpusets to keep a task and its
memory locked on a single node?


It's going to be hard to impossible to guarantee.  mlock() doesn't
guarantee that things won't change physical addresses.  You'd have to
change that guarantee or chase all the things in the kernel that might
change physical addresses (compaction, ksm, etc...).

Actually, that reminds me...  How does your code interface with ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?



Yes, version tags are interpreted at virtual address level.

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread David Miller 
From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800

> Actually, that reminds me...  How does your code interface with ksm?  Or
> is there no interaction needed since you're always working on virtual
> addresses?

This reminds me, I consider this feature potentially extremely useful for
kernel debugging.  So I would like to make sure we don't implement anything
in a way which would preclude that in the long term.
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Dave Hansen 
On 01/06/2017 08:22 AM, Khalid Aziz wrote:
> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>> I agree with you on simplicity first. Subpage granularity is complex,
>>> but the architecture allows for subpage granularity. Maybe the right
>>> approach is to support this at page granularity first for swappable
>>> pages and then expand to subpage granularity in a subsequent patch?
>>> Pages locked in memory can already use subpage granularity with my
>>> patch.
>>
>> What do you mean by "locked in memory"?  mlock()'d memory can still be
>> migrated around and still requires "swap" ptes, for instance.
> 
> You are right. Page migration can invalidate subpage granularity even
> for locked pages. Is it possible to use cpusets to keep a task and its
> memory locked on a single node?

It's going to be hard to impossible to guarantee.  mlock() doesn't
guarantee that things won't change physical addresses.  You'd have to
change that guarantee or chase all the things in the kernel that might
change physical addresses (compaction, ksm, etc...).

Actually, that reminds me...  How does your code interface with ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread David Miller 
From: Khalid Aziz 
Date: Fri, 6 Jan 2017 09:22:13 -0700

> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>> I agree with you on simplicity first. Subpage granularity is complex,
>>> but the architecture allows for subpage granularity. Maybe the right
>>> approach is to support this at page granularity first for swappable
>>> pages and then expand to subpage granularity in a subsequent patch?
>>> Pages locked in memory can already use subpage granularity with my
>>> patch.
>>
>> What do you mean by "locked in memory"?  mlock()'d memory can still be
>> migrated around and still requires "swap" ptes, for instance.
> 
> You are right. Page migration can invalidate subpage granularity even
> for locked pages. Is it possible to use cpusets to keep a task and its
> memory locked on a single node? Just wondering if there are limited
> cases where subpage granularity could work without supporting subpage
> granularity for tags in swap. It still sounds like the right thing to
> do is to get a reliable implementation in place with page size
> granularity and then add the complexity of subpage granularity.

It sounds to me, in all of this, that if the kernel manages the
movement of the pages, it thus must handle making sure the tags move
around with that page 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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Khalid Aziz 

On 01/06/2017 08:36 AM, Dave Hansen wrote:

On 01/06/2017 07:32 AM, Khalid Aziz wrote:

I agree with you on simplicity first. Subpage granularity is complex,
but the architecture allows for subpage granularity. Maybe the right
approach is to support this at page granularity first for swappable
pages and then expand to subpage granularity in a subsequent patch?
Pages locked in memory can already use subpage granularity with my patch.


What do you mean by "locked in memory"?  mlock()'d memory can still be
migrated around and still requires "swap" ptes, for instance.


You are right. Page migration can invalidate subpage granularity even 
for locked pages. Is it possible to use cpusets to keep a task and its 
memory locked on a single node? Just wondering if there are limited 
cases where subpage granularity could work without supporting subpage 
granularity for tags in swap. It still sounds like the right thing to do 
is to get a reliable implementation in place with page size granularity 
and then add the complexity of subpage granularity.


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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Dave Hansen 
On 01/06/2017 07:32 AM, Khalid Aziz wrote:
> I agree with you on simplicity first. Subpage granularity is complex,
> but the architecture allows for subpage granularity. Maybe the right
> approach is to support this at page granularity first for swappable
> pages and then expand to subpage granularity in a subsequent patch?
> Pages locked in memory can already use subpage granularity with my patch.

What do you mean by "locked in memory"?  mlock()'d memory can still be
migrated around and still requires "swap" ptes, for instance.
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-06 Thread Khalid Aziz 

On 01/06/2017 02:19 AM, Michal Hocko wrote:

On Thu 05-01-17 13:30:10, Khalid Aziz wrote:
[...]

It is very tempting to restrict tags to PAGE_SIZE granularity since it makes
code noticeably simpler and that is indeed going to be the majority of
cases. Sooner or later somebody would want to use multiple tags per page
though.


I didn't get to read the patch throughly yet but I am really confused by
this statement. The api is mprotect based which makes it ineherently
PAGE_SIZE granular. How do you want to achieve cache line granularity
with this API?

And I would really vote for simplicity first... Subpage granularity
sounds way too tricky...



Hi Michal,

ADI can be enabled for subsets of a task's address space. It takes three 
steps to enable ADI completely:


1. Enable the task to use ADI by setting PSTATE.mcde bit. This is the 
master switch for ADI. mprotect() does this in my patch. Granularity for 
this operation is entire address space for the task.


2. Set TTE.mcd bit for each page translation for the pages one wants ADI 
enabled on. mprotect() does this as well in my patch. Granularity for 
this operation is per page.


3. Set version tag for the addresses task wants to enable ADI on using 
"stxa" instruction. This is done entirely in userspace with no 
assistance or intervention needed from the kernel. Granularity for this 
operation is cache line size which is 64 bytes on Sparc M7.


I agree with you on simplicity first. Subpage granularity is complex, 
but the architecture allows for subpage granularity. Maybe the right 
approach is to support this at page granularity first for swappable 
pages and then expand to subpage granularity in a subsequent patch? 
Pages locked in memory can already use subpage granularity with my patch.


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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-05 Thread Khalid Aziz 

On 01/05/2017 12:22 PM, Dave Hansen wrote:

On 01/04/2017 04:26 PM, Khalid Aziz wrote:
...

No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte.
There is enough space for just one tag per page. DaveM had suggested
doing this since the usual case is for a task to set one tag per page
even though MMU does not require it. I have implemented this as first
pass to start a discussion and get feedback on whether rest of the
swapping implementation and other changes look right, hence the patch is
"RFC". If this all looks good, I can expand swapping support in a
subsequent patch or iteration of this patch to allocate space in
mm_context_t possibly to store per cacheline tags. I am open to any
other ideas on storing this larger number of version tags.


FWIW, This is the kind of thing that would be really useful to point out
to reviewers instead of requiring them to ferret it out of the code.  It
has huge implications for how applications use this feature.


Hi Dave,

Thanks for taking the time to review this. I appreciate your patience. I 
will add more details.




As for where to store the tags...  It's potentially a *lot* of data, so
I think it'll be a pain any way you do it.

If you, instead, can live with doing things on a PAGE_SIZE granularity
like pkeys does, you could just store it in the VMA and have the kernel
tag the data at the same time it zeroes the pages.


It is very tempting to restrict tags to PAGE_SIZE granularity since it 
makes code noticeably simpler and that is indeed going to be the 
majority of cases. Sooner or later somebody would want to use multiple 
tags per page though. There can be 128 4-bit tags per 8K page which 
requires 64 bytes of tag storage for each page. This can add up. What I 
am considering doing is store the tag in swp pte if I find only one tag 
on the page. A VMA can cover multiple pages and we have unused bits in 
swp pte. It makes more sense to store the tags in swp pte. If I find 
more than one tag on the page, I can allocate memory, attach it to a 
data structure in mm_context_t and store the tags there. I will need to 
use an rb tree or some other way to keep the data sorted to make it 
quick to retrieve the tags for one of the millions of pages a task might 
have. As I said, it gets complex trying to store tags per cacheline as 
opposed to per page :)


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-05 Thread Dave Hansen 
On 01/04/2017 04:26 PM, Khalid Aziz wrote:
...
> No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte.
> There is enough space for just one tag per page. DaveM had suggested
> doing this since the usual case is for a task to set one tag per page
> even though MMU does not require it. I have implemented this as first
> pass to start a discussion and get feedback on whether rest of the
> swapping implementation and other changes look right, hence the patch is
> "RFC". If this all looks good, I can expand swapping support in a
> subsequent patch or iteration of this patch to allocate space in
> mm_context_t possibly to store per cacheline tags. I am open to any
> other ideas on storing this larger number of version tags.

FWIW, This is the kind of thing that would be really useful to point out
to reviewers instead of requiring them to ferret it out of the code.  It
has huge implications for how applications use this feature.

As for where to store the tags...  It's potentially a *lot* of data, so
I think it'll be a pain any way you do it.

If you, instead, can live with doing things on a PAGE_SIZE granularity
like pkeys does, you could just store it in the VMA and have the kernel
tag the data at the same time it zeroes the pages.
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-05 Thread Khalid Aziz 

On 01/05/2017 02:37 AM, Jerome Marchand wrote:

On 01/04/2017 11:46 PM, Khalid Aziz wrote:

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.

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.  It also adds handlers for all traps
related to MCD. 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 
---
v2:
- Fixed a build error

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

 Documentation/sparc/adi.txt | 239 
 arch/sparc/include/asm/adi.h|   6 +
 arch/sparc/include/asm/adi_64.h |  46 ++
 arch/sparc/include/asm/elf_64.h |   8 ++
 arch/sparc/include/asm/hugetlb.h|  13 ++
 arch/sparc/include/asm/hypervisor.h |   2 +
 arch/sparc/include/asm/mman.h   |  40 +-
 arch/sparc/include/asm/mmu_64.h |   2 +
 arch/sparc/include/asm/mmu_context_64.h |  32 +
 arch/sparc/include/asm/pgtable_64.h |  97 -
 arch/sparc/include/asm/ttable.h |  10 ++
 arch/sparc/include/asm/uaccess_64.h | 120 +++-
 arch/sparc/include/uapi/asm/asi.h   |   5 +
 arch/sparc/include/uapi/asm/auxvec.h|   8 ++
 arch/sparc/include/uapi/asm/mman.h  |   2 +
 arch/sparc/include/uapi/asm/pstate.h|  10 ++
 arch/sparc/kernel/Makefile  |   1 +
 arch/sparc/kernel/adi_64.c  |  93 +
 arch/sparc/kernel/entry.h   |   3 +
 arch/sparc/kernel/head_64.S |   1 +
 arch/sparc/kernel/mdesc.c   |   4 +
 arch/sparc/kernel/process_64.c  |  21 +++
 arch/sparc/kernel/sun4v_mcd.S   |  16 +++
 arch/sparc/kernel/traps_64.c| 142 ++-
 arch/sparc/kernel/ttable_64.S   |   6 +-
 arch/sparc/mm/gup.c |  37 +
 arch/sparc/mm/tlb.c |  28 
 arch/x86/kernel/signal_compat.c |   2 +-
 include/asm-generic/pgtable.h   |   5 +
 include/linux/mm.h  |   2 +
 include/uapi/asm-generic/siginfo.h  |   5 +-
 mm/memory.c |   2 +-
 mm/rmap.c   |   4 +-


I haven't actually reviewed the code and looked at why you need
set_swp_pte_at() function, but the code that add the generic version of
this function need to be separated from the rest of the patch. Also,
given the size of this patch, I suspect the rest also need to be broken
into more patches.

Jerome



Sure, I can do that. Code to add new signal codes can be one patch, 
generic changes to swap infrastructure can be another and I can look for 
logical breaks for the rest of the sparc specific code.


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-05 Thread Jerome Marchand 
On 01/04/2017 11:46 PM, Khalid Aziz wrote:
> 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.
> 
> 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.  It also adds handlers for all traps
> related to MCD. 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 
> ---
> v2:
>   - Fixed a build error
> 
> v3:
>   - Removed CONFIG_SPARC_ADI
>   - Replaced prctl commands with mprotect
>   - Added auxiliary vectors for ADI parameters
>   - Enabled ADI for swappable pages
> 
>  Documentation/sparc/adi.txt | 239 
> 
>  arch/sparc/include/asm/adi.h|   6 +
>  arch/sparc/include/asm/adi_64.h |  46 ++
>  arch/sparc/include/asm/elf_64.h |   8 ++
>  arch/sparc/include/asm/hugetlb.h|  13 ++
>  arch/sparc/include/asm/hypervisor.h |   2 +
>  arch/sparc/include/asm/mman.h   |  40 +-
>  arch/sparc/include/asm/mmu_64.h |   2 +
>  arch/sparc/include/asm/mmu_context_64.h |  32 +
>  arch/sparc/include/asm/pgtable_64.h |  97 -
>  arch/sparc/include/asm/ttable.h |  10 ++
>  arch/sparc/include/asm/uaccess_64.h | 120 +++-
>  arch/sparc/include/uapi/asm/asi.h   |   5 +
>  arch/sparc/include/uapi/asm/auxvec.h|   8 ++
>  arch/sparc/include/uapi/asm/mman.h  |   2 +
>  arch/sparc/include/uapi/asm/pstate.h|  10 ++
>  arch/sparc/kernel/Makefile  |   1 +
>  arch/sparc/kernel/adi_64.c  |  93 +
>  arch/sparc/kernel/entry.h   |   3 +
>  arch/sparc/kernel/head_64.S |   1 +
>  arch/sparc/kernel/mdesc.c   |   4 +
>  arch/sparc/kernel/process_64.c  |  21 +++
>  arch/sparc/kernel/sun4v_mcd.S   |  16 +++
>  arch/sparc/kernel/traps_64.c| 142 ++-
>  arch/sparc/kernel/ttable_64.S   |   6 +-
>  arch/sparc/mm/gup.c |  37 +
>  arch/sparc/mm/tlb.c |  28 
>  arch/x86/kernel/signal_compat.c |   2 +-
>  include/asm-generic/pgtable.h   |   5 +
>  include/linux/mm.h  |   2 +
>  include/uapi/asm-generic/siginfo.h  |   5 +-
>  mm/memory.c |   2 +-
>  mm/rmap.c   |   4 +-

I haven't actually reviewed the code and looked at why you need
set_swp_pte_at() function, but the code that add the generic version of
this function need to be separated from the rest of the patch. Also,
given the size of this patch, I suspect the rest also need to be broken
into more patches.

Jerome



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 04:05 PM, Rob Gardner wrote:
>> What if two different small pages have different tags and khugepaged
>> comes along and tries to collapse them?  Will the page be split if a
>> user attempts to set two different tags inside two different small-page
>> portions of a single THP?
> 
> The MCD tags operate at a resolution of cache lines (64 bytes). Page
> sizes don't matter except that each virtual page must have a bit set in
> its TTE to allow MCD to be enabled on the page. Any page can have many
> different tags, one for each cache line.

Is an "MCD tag" the same thing as a "ADI version tag"?

The thing that confused me here is that we're taking an entire page of
"ADI version tags" and stuffing them into a swap pte (in
set_swp_pte_at()).  Do we somehow have enough space in a swap pte on
sparc to fit PAGE_SIZE/64 "ADI version tag"s in there?
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Rob Gardner 

On 01/04/2017 04:01 PM, Dave Hansen wrote:

On 01/04/2017 03:58 PM, Khalid Aziz wrote:

How does this all work with large pages?

It works with large pages the same way as normal sized pages. The TTE
for a large page also will have the mcd bit set in it and tags are set
and referenced the same way.

But does the user setting the tags need to know what the page size is?

What if two different small pages have different tags and khugepaged
comes along and tries to collapse them?  Will the page be split if a
user attempts to set two different tags inside two different small-page
portions of a single THP?


The MCD tags operate at a resolution of cache lines (64 bytes). Page 
sizes don't matter except that each virtual page must have a bit set in 
its TTE to allow MCD to be enabled on the page. Any page can have many 
different tags, one for each cache line.


Rob

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 03:58 PM, Khalid Aziz wrote:
>> How does this all work with large pages?
> 
> It works with large pages the same way as normal sized pages. The TTE
> for a large page also will have the mcd bit set in it and tags are set
> and referenced the same way.

But does the user setting the tags need to know what the page size is?

What if two different small pages have different tags and khugepaged
comes along and tries to collapse them?  Will the page be split if a
user attempts to set two different tags inside two different small-page
portions of a single THP?
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Khalid Aziz 

On 01/04/2017 04:49 PM, Dave Hansen wrote:

On 01/04/2017 03:44 PM, Rob Gardner wrote:

On 01/04/2017 03:40 PM, Dave Hansen wrote:

On 01/04/2017 03:35 PM, Rob Gardner wrote:

Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.

What does "allocated" mean in this context?  Physical or virtual? What
does this do, for instance?


The first time a virtual page is touched by a process after the malloc,
the kernel does clear_user_page() or something similar, which zeroes the
memory. At the same time, the memory tags are cleared.


OK, so the tags can't survive a MADV_FREE.  That's definitely something
for apps to understand that use MADV_FREE as a substitute for memset().
It also means that tags can't be set for physically unallocated memory.

Neither of those are deal killers, but it would be nice to document it.


This can go into the adi.txt doc file.



How does this all work with large pages?


It works with large pages the same way as normal sized pages. The TTE 
for a large page also will have the mcd bit set in it and tags are set 
and referenced the same way.


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Rob Gardner 

On 01/04/2017 03:49 PM, Dave Hansen wrote:

On 01/04/2017 03:44 PM, Rob Gardner wrote:

On 01/04/2017 03:40 PM, Dave Hansen wrote:

On 01/04/2017 03:35 PM, Rob Gardner wrote:

Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.

What does "allocated" mean in this context?  Physical or virtual? What
does this do, for instance?

The first time a virtual page is touched by a process after the malloc,
the kernel does clear_user_page() or something similar, which zeroes the
memory. At the same time, the memory tags are cleared.

OK, so the tags can't survive a MADV_FREE.  That's definitely something
for apps to understand that use MADV_FREE as a substitute for memset().
It also means that tags can't be set for physically unallocated memory.

Neither of those are deal killers, but it would be nice to document it.

How does this all work with large pages?


It all works completely with large pages.

Rob

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 03:46 PM, Khalid Aziz wrote:
>> It would also be really nice to see a high-level breakdown explaining
>> what you had to modify, especially since this affects all of the system
>> calls that take a PROT_* argument.  The sample code is nice, but it's no
>> substitute for writing it down.
> 
> I will expand the explanation in Documentation/sparc/adi.txt.

I think (partially) duplicating that in a cover letter would also be
nice.  The documentation is a bit buried in the 1,000 lines of 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

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 03:44 PM, Rob Gardner wrote:
> On 01/04/2017 03:40 PM, Dave Hansen wrote:
>> On 01/04/2017 03:35 PM, Rob Gardner wrote:
>>> Tags are not cleared at all when memory is freed, but rather, lazily
>>> (and automatically) cleared when memory is allocated.
>> What does "allocated" mean in this context?  Physical or virtual? What
>> does this do, for instance?
> 
> The first time a virtual page is touched by a process after the malloc,
> the kernel does clear_user_page() or something similar, which zeroes the
> memory. At the same time, the memory tags are cleared.

OK, so the tags can't survive a MADV_FREE.  That's definitely something
for apps to understand that use MADV_FREE as a substitute for memset().
It also means that tags can't be set for physically unallocated memory.

Neither of those are deal killers, but it would be nice to document it.

How does this all work with large pages?
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Khalid Aziz 

On 01/04/2017 04:31 PM, Dave Hansen wrote:

One other high-level comment:  It would be nice to see the
arch-independent and x86 portions broken out and explained in their own
right, even if they're small patches.  It's a bit cruel to make us
scroll through a thousand lines of sparc code to see the bits
interesting to us.


Sure, that is very reasonable. I will do that.



It would also be really nice to see a high-level breakdown explaining
what you had to modify, especially since this affects all of the system
calls that take a PROT_* argument.  The sample code is nice, but it's no
substitute for writing it down.


I will expand the explanation in Documentation/sparc/adi.txt.

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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Khalid Aziz 

On 01/04/2017 04:27 PM, Dave Hansen wrote:

On 01/04/2017 02:46 PM, Khalid Aziz wrote:

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.


I'm a bit confused why we need all the mechanics with set_swp_pte_at().
For pkeys, for instance, all of the PTEs under a given VMA share a pkey.
 When swapping something in, we just get the pkey out of the VMA and
populate the PTE.

ADI doesn't seem to have a similar restriction.  The feature is turned
on or off at a VMA granularity, but we do not (or can enforce that all
pages under a given VMA must share a tag.

But this leads to an interesting question: is the tag associated with
the (populated?) pte, or the virtual address?  Can you have tags
associated with non-present addresses?  What's the mechanism that clears
the tags at munmap() or MADV_FREE time?


Hi Dave,

Tag is associated with virtual address and all pages in a singular VMA 
do not share the same tag. When a page is swapped out, we need to save 
the tag that was set on it so we can restore it when we bring the page 
back in. When MMU translates a vitrtual address into physical address, 
it expects to see the same tag set on the physical page as is set in the 
VA before it will allow access. Tags are cleared on a page by 
NG4clear_page() and NG4clear_user_page() when a page is allocated to a task.




Is the tag storage a precious resource?  Can it be exhausted?


There is a metadata area in RAM that stores the tags and it has enough 
space to cover all the tags for the RAM size.


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Rob Gardner 

On 01/04/2017 03:40 PM, Dave Hansen wrote:

On 01/04/2017 03:35 PM, Rob Gardner wrote:

Tags are not cleared at all when memory is freed, but rather, lazily
(and automatically) cleared when memory is allocated.

What does "allocated" mean in this context?  Physical or virtual? What
does this do, for instance?


The first time a virtual page is touched by a process after the malloc, 
the kernel does clear_user_page() or something similar, which zeroes the 
memory. At the same time, the memory tags are cleared.


Rob




ptr = malloc(PAGE_SIZE);
set_tag(ptr, 14);
madvise(ptr, PAGE_SIZE, MADV_FREE);
printf("tag: %d\n", get_tag(ptr));
free(ptr);
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 03:35 PM, Rob Gardner wrote:
> Tags are not cleared at all when memory is freed, but rather, lazily
> (and automatically) cleared when memory is allocated.

What does "allocated" mean in this context?  Physical or virtual? What
does this do, for instance?

ptr = malloc(PAGE_SIZE);
set_tag(ptr, 14);
madvise(ptr, PAGE_SIZE, MADV_FREE);
printf("tag: %d\n", get_tag(ptr));
free(ptr);
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Rob Gardner 

On 01/04/2017 03:27 PM, Dave Hansen wrote:

On 01/04/2017 02:46 PM, Khalid Aziz wrote:

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.

I'm a bit confused why we need all the mechanics with set_swp_pte_at().
For pkeys, for instance, all of the PTEs under a given VMA share a pkey.
  When swapping something in, we just get the pkey out of the VMA and
populate the PTE.

ADI doesn't seem to have a similar restriction.  The feature is turned
on or off at a VMA granularity, but we do not (or can enforce that all
pages under a given VMA must share a tag.

But this leads to an interesting question: is the tag associated with
the (populated?) pte, or the virtual address?  Can you have tags
associated with non-present addresses?  What's the mechanism that clears
the tags at munmap() or MADV_FREE time?

Is the tag storage a precious resource?  Can it be exhausted?



Tags are stored in physical memory, so there is no "tag storage" that 
can be exhausted.


Tags are not cleared at all when memory is freed, but rather, lazily 
(and automatically) cleared when memory is allocated.



Rob

--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
One other high-level comment:  It would be nice to see the
arch-independent and x86 portions broken out and explained in their own
right, even if they're small patches.  It's a bit cruel to make us
scroll through a thousand lines of sparc code to see the bits
interesting to us.

It would also be really nice to see a high-level breakdown explaining
what you had to modify, especially since this affects all of the system
calls that take a PROT_* argument.  The sample code is nice, but it's no
substitute for writing it down.
--
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: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

2017-01-04 Thread Dave Hansen 
On 01/04/2017 02:46 PM, Khalid Aziz wrote:
> 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. 

I'm a bit confused why we need all the mechanics with set_swp_pte_at().
For pkeys, for instance, all of the PTEs under a given VMA share a pkey.
 When swapping something in, we just get the pkey out of the VMA and
populate the PTE.

ADI doesn't seem to have a similar restriction.  The feature is turned
on or off at a VMA granularity, but we do not (or can enforce that all
pages under a given VMA must share a tag.

But this leads to an interesting question: is the tag associated with
the (populated?) pte, or the virtual address?  Can you have tags
associated with non-present addresses?  What's the mechanism that clears
the tags at munmap() or MADV_FREE time?

Is the tag storage a precious resource?  Can it be exhausted?
--
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