Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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... -- Michal Hocko SUSE Labs -- 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)
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)
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)
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)
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)
On 01/04/2017 05:14 PM, Dave Hansen wrote: 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? 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. 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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
