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

On 03/02/2016 12:39 PM, Khalid Aziz wrote: > +long enable_sparc_adi(unsigned long addr, unsigned long len) > +{ > + unsigned long end, pagemask; > + int error; > + struct vm_area_struct *vma, *vma2; > + struct mm_struct *mm; > + > + if (!ADI_CAPABLE()) > + return

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

On 03/07/2016 08:06 AM, Khalid Aziz wrote: > Top 4-bits of sparc64 virtual address are used for version tag only when > a process has its PSTATE.mcde bit set and it is accessing a memory > region that has ADI enabled on it (TTE.mcd set) and a version tag was > set on the virtual address being

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

On 03/07/2016 11:46 AM, Khalid Aziz wrote: > On 03/07/2016 12:22 PM, David Miller wrote: >> Khalid, maybe you should share notes with the folks working on x86 >> protection keys. > > Good idea. Sparc ADI feature is indeed similar to x86 protection keys > sounds like. There are definitely some

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

On 03/02/2016 12:39 PM, Khalid Aziz wrote: > --- a/include/uapi/asm-generic/siginfo.h > +++ b/include/uapi/asm-generic/siginfo.h > @@ -206,7 +206,10 @@ typedef struct siginfo { > #define SEGV_MAPERR (__SI_FAULT|1) /* address not mapped to object */ > #define SEGV_ACCERR (__SI_FAULT|2) /*

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

On 05/02/2016 02:41 PM, Thomas Garnier wrote: > Minor change that allows early boot physical mapping of PUD level virtual > addresses. This change prepares usage of different virtual addresses for > KASLR memory randomization. It has no impact on default usage. ... > diff --git

Re: [PATCH] mm: Add the ram_latent_entropy kernel parameter

On 08/10/2016 03:28 PM, Kees Cook wrote: > + if (ram_latent_entropy && !PageHighMem(page) && > + page_to_pfn(page) < 0x10) { > + u64 hash = 0; > + size_t index, end = PAGE_SIZE * nr_pages / sizeof(hash); > + const u64 *data =

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

On 02/16/2017 07:43 AM, Tom Lendacky wrote: > static inline unsigned long pte_pfn(pte_t pte) > { > - return (pte_val(pte) & PTE_PFN_MASK) >> PAGE_SHIFT; > + return (pte_val(pte) & ~sme_me_mask & PTE_PFN_MASK) >> PAGE_SHIFT; > } > > static inline unsigned long pmd_pfn(pmd_t pmd) > {

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

On 02/16/2017 07:43 AM, Tom Lendacky wrote: > ) > @@ -673,7 +683,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd) > * Currently stuck as a macro due to indirect forward reference to > * linux/mmzone.h's __section_mem_map_addr() definition: > */ > -#define pgd_page(pgd)

[PATCH] x86/pkeys: Update documentation

From: Dave Hansen <dave.han...@intel.com> There are a few items that have gotten stale in the protection keys documentation. The config option description only applied to the execute-only support and is not accurate for the current code. There was also a typo with the number of system

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On 11/09/2016 07:24 PM, Ricardo Neri wrote: > On Wed, 2016-11-09 at 03:02 -0800, Andy Lutomirski wrote: ... >> > What I mean is: why does this need a config option at all? > I intended this feature to be configurable at build time in case someone > wants to build a kernel without it; similar to

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On 11/10/2016 08:08 PM, Ricardo Neri wrote: > Thanks for the suggestions. Perhaps I can include these metrics in my > V2. On th other hand, Dave Hansen gave a good argument on potential > conflicts when, of instance running on an AMD CPU. UMIP is enabled by > setting a bit in CR4.

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

On 01/11/2017 08:56 AM, Khalid Aziz wrote: > On 01/11/2017 09:33 AM, Dave Hansen wrote: >> On 01/11/2017 08:12 AM, Khalid Aziz wrote: >>> A userspace task enables ADI through mprotect(). This patch series adds >>> a page protection bit PROT_ADI and a correspondin

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

On 01/11/2017 10:50 AM, Khalid Aziz wrote: > On 01/11/2017 11:13 AM, Dave Hansen wrote: >> On 01/11/2017 08:56 AM, Khalid Aziz wrote: >> For memory shared by two different processes, do they have to agree on >> what the tags are, or can they differ? > > The two process

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

On 01/11/2017 08:12 AM, Khalid Aziz wrote: > A userspace task enables ADI through mprotect(). This patch series adds > a page protection bit PROT_ADI and a corresponding VMA flag > VM_SPARC_ADI. VM_SPARC_ADI is used to trigger setting TTE.mcd bit in the > sparc pte that enables ADI checking on the

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

On 01/13/2017 07:29 AM, Rob Gardner wrote: > so perhaps ADI should simply be disallowed for memory mapped to > files, and this particular complication can be avoided. Thoughts? What's a "file" from your perspective? In Linux, shared memory is a file. hugetlbfs is done with files. Many

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

On 01/12/2017 08:50 AM, Khalid Aziz wrote: > 2. Any shared page that has ADI protection enabled on it, must stay ADI > protected across all processes sharing it. Is that true? What happens if a page with ADI tags set is accessed via a PTE without the ADI enablement bit set? > COW creates an

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

On 01/11/2017 04:22 PM, Khalid Aziz wrote: ... > All of the tag coordination can happen in userspace. Once a process sets > a tag on a physical page mapped in its address space, another process > that has mapped the same physical page in its address space can only set > the tag to exact same

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

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

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

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? > >

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.

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 =

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. &g

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

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

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. M

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/18/2017 02:22 PM, Tom Lendacky wrote: > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > determine if SME is active. > > A new directory will be created: > /sys/kernel/mm/sme/ > > And two entries within the new directory: > /sys/kernel/mm/sme/active >

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On 04/18/2017 02:17 PM, Tom Lendacky wrote: > @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, > unsigned long vaddr, > __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x))) > > #ifndef __va > -#define __va(x) ((void *)((unsigned >

Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma

On 07/13/2017 01:03 AM, Ram Pai wrote: > On Tue, Jul 11, 2017 at 11:13:56AM -0700, Dave Hansen wrote: >> On 07/05/2017 02:22 PM, Ram Pai wrote: >>> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS >>> +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)

Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Abstracted out the arch specific code into the header file, and > added powerpc specific changes. > > a) added 4k-backed hpte, memory allocator, powerpc specific. > b) added three test case where the key is associated after the page is >

Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently there are only 4bits in the vma flags to support 16 keys > on x86. powerpc supports 32 keys, which needs 5bits. This patch > introduces an addition bit in the vma flags. > > Signed-off-by: Ram Pai > --- >

Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma

On 07/05/2017 02:22 PM, Ram Pai wrote: > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > +{ > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +} > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ This seems like

Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Add documentation updates that capture PowerPC specific changes. > > Signed-off-by: Ram Pai > --- > Documentation/vm/protection-keys.txt | 85 > ++ > 1 files changed, 65 insertions(+), 20

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

On 07/05/2017 02:21 PM, Ram Pai wrote: > Currently sys_pkey_create() provides the ability to disable read > and write permission on the key, at creation. powerpc has the > hardware support to disable execute on a pkey as well.This patch > enhances the interface to let disable execute at key

Re: [RFC v5 13/38] x86: disallow pkey creation with PKEY_DISABLE_EXECUTE

On 07/05/2017 02:21 PM, Ram Pai wrote: > x86 does not support disabling execute permissions on a pkey. > > Signed-off-by: Ram Pai > --- > arch/x86/kernel/fpu/xstate.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

On 07/11/2017 02:51 PM, Ram Pai wrote: > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote: >> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote: >>> On 07/05/2017 02:21 PM, Ram Pai wrote: >>>> Currently sys_pkey_create() provides the ability

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

On 07/11/2017 03:14 PM, Ram Pai wrote: > Now how many does the kernel use to reserve for itself is something > the kernel knows too and hence can expose it, though the information > may change dynamically as the kernel reserves and releases the key > based on its internal needs. > > So i think

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/2017 12:25 AM, Dave Young wrote: > On 04/21/17 at 02:55pm, Dave Hansen wrote: >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can >>> determine if SME is active. >>> >>>

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On 12/18/2017 02:18 PM, Ram Pai wrote: > b) minimum number of keys available to the application. > if libraries consumes a few, they could provide a library > interface to the application informing the number available to > the application. The library interface can leverage (b)

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On 11/06/2017 12:57 AM, Ram Pai wrote: > Expose useful information for programs using memory protection keys. > Provide implementation for powerpc and x86. > > On a powerpc system with pkeys support, here is what is shown: > > $ head /sys/kernel/mm/protection_keys/* > ==>

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

On 11/07/2017 02:39 PM, Ram Pai wrote: > > As per the current semantics of sys_pkey_free(); the way I understand it, > the calling thread is saying disassociate me from this key. No. It is saying: "this *process* no longer has any uses of this key, it can be reused". -- To unsubscribe from this

[PATCH] docs: clarify security-bugs disclosure policy

From: Dave Hansen <dave.han...@linux.intel.com> I think we need to soften the language a bit. It might scare folks off, especially the: We prefer to fully disclose the bug as soon as possible. which is not really the case. As Greg mentioned in private mail, we really do not

[PATCH] [v2] docs: clarify security-bugs disclosure policy

From: Dave Hansen <dave.han...@linux.intel.com> I think we need to soften the language a bit. It might scare folks off, especially the: We prefer to fully disclose the bug as soon as possible. which is not really the case. Linus says: It's not full disclosure

Re: [PATCH v12 02/22] selftests/vm: rename all references to pkru to a generic name

u32 new_pkey_reg; If we're not using the _actual_ instruction names ("rdpkru"), I think I'd rather this be something more readable, like: __read_pkey_reg(). But, it's OK-ish the way it is. Reviewed-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from this list:

Re: [PATCH v12 10/22] selftests/vm: introduce two arch independent abstraction

On 02/21/2018 05:55 PM, Ram Pai wrote: > open_hugepage_file() <- opens the huge page file > get_start_key() <-- provides the first non-reserved key. > Looks reasonable. Reviewed-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from this list: send the line &

Re: [PATCH v12 12/22] selftests/vm: generic cleanup

On 02/21/2018 05:55 PM, Ram Pai wrote: > cleanup the code to satisfy coding styles. > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> > Signed-off-by: Ram Pai <linux...@us.ibm.com> > --- > tools/testin

Re: [PATCH v12 20/22] selftests/vm: testcases must restore pkey-permissions

On 02/21/2018 05:55 PM, Ram Pai wrote: > Generally the signal handler restores the state of the pkey register > before returning. However there are times when the read/write operation > can legitamely fail without invoking the signal handler. Eg: A > sys_read() operaton to a write-protected page

Re: [PATCH v12 21/22] selftests/vm: sub-page allocator

On 02/21/2018 05:55 PM, Ram Pai wrote: ... > @@ -888,6 +917,7 @@ void setup_hugetlbfs(void) > void *(*pkey_malloc[])(long size, int prot, u16 pkey) = { > > malloc_pkey_with_mprotect, > + malloc_pkey_with_mprotect_subpage, > malloc_pkey_anon_huge, > malloc_pkey_hugetlb >

Re: [PATCH v12 05/22] selftests/vm: generic function to handle shadow key register

On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline u32 pkey_to_shift(int pkey) > +{ > + return pkey * PKEY_BITS_PER_PKEY; > +} pkey_bit_position(), perhaps? > +static inline pkey_reg_t reset_bits(int pkey, pkey_reg_t bits) > +{ > + u32 shift = pkey_to_shift(pkey); > + > + return

Re: [PATCH v12 08/22] selftests/vm: clear the bits in shadow reg when a pkey is freed.

On 02/21/2018 05:55 PM, Ram Pai wrote: > When a key is freed, the key is no more effective. > Clear the bits corresponding to the pkey in the shadow > register. Otherwise it will carry some spurious bits > which can trigger false-positive asserts. ... > diff --git

Re: [PATCH v12 11/22] selftests/vm: pkey register should match shadow pkey

w pkey register, which is supposed to track the bits > accurately all throughout > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> > Signed-off-by: Ram Pai <linux...@us.ibm.com> > --- > tools/testing/selftests/vm/protection_key

Re: [PATCH v12 15/22] selftests/vm: powerpc implementation to check support for pkey

On 02/21/2018 05:55 PM, Ram Pai wrote: > #define PAGE_SIZE (0x1UL << 16) > -static inline int cpu_has_pku(void) > +static inline bool is_pkey_supported(void) > { > - return 1; > + /* > + * No simple way to determine this. > + * lets try allocating a key and see if it succeeds.

Re: [PATCH v12 18/22] selftests/vm: associate key on a mapped page and detect write violation

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which write-disabled > key is associated much after the page is mapped. The more tests the merrier. Acked-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from this list: send the line "unsu

Re: [PATCH v12 19/22] selftests/vm: detect write violation on a mapped access-denied-key page

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which access-disabled > key is associated much after the page is mapped. Acked-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

On 02/21/2018 05:55 PM, Ram Pai wrote: > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags) > pkey, pkey, pkey_rights); > pkey_assert(pkey_rights >=

Re: [PATCH v12 16/22] selftests/vm: fix an assertion in test_pkey_alloc_exhaust()

On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline int arch_reserved_keys(void) > +{ > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > + return NR_RESERVED_PKEYS; > +#elif __powerpc64__ /* arch */ > + if (sysconf(_SC_PAGESIZE) == 4096) > + return

Re: [PATCH v12 04/22] selftests/vm: typecast the pkey register

On 02/21/2018 05:55 PM, Ram Pai wrote: > -static inline unsigned int _rdpkey_reg(int line) > +static inline pkey_reg_t _rdpkey_reg(int line) > { > - unsigned int pkey_reg = __rdpkey_reg(); > + pkey_reg_t pkey_reg = __rdpkey_reg(); > > - dprintf4("rdpkey_reg(line=%d) pkey_reg: %x

Re: [PATCH v12 13/22] selftests/vm: powerpc implementation for generic abstraction

On 02/21/2018 05:55 PM, Ram Pai wrote: > static inline u32 pkey_to_shift(int pkey) > { > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > return pkey * PKEY_BITS_PER_PKEY; > +#elif __powerpc64__ /* arch */ > + return (NR_PKEYS - pkey - 1) * PKEY_BITS_PER_PKEY; > +#endif /*

Re: [PATCH v12 06/22] selftests/vm: fix the wrong assert in pkey_disable_set()

On 02/21/2018 05:55 PM, Ram Pai wrote: > If the flag is 0, no bits will be set. Hence we cant expect > the resulting bitmap to have a higher value than what it > was earlier. > > cc: Dave Hansen <dave.han...@intel.com> > cc: Florian Weimer <fwei...@redhat.com> &

Re: [PATCH v12 09/22] selftests/vm: fix alloc_random_pkey() to make it really random

On 02/21/2018 05:55 PM, Ram Pai wrote: > alloc_random_pkey() was allocating the same pkey every time. > Not all pkeys were geting tested. fixed it. ... > @@ -602,13 +603,15 @@ int alloc_random_pkey(void) > int alloced_pkeys[NR_PKEYS]; > int nr_alloced = 0; > int random_index; > +

Re: [PATCH v12 17/22] selftests/vm: associate key on a mapped page and detect access violation

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect access-violation on a page to which access-disabled > key is associated much after the page is mapped. Looks fine to me. Did this actually find a bug for you? Acked-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from thi

Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

e > frozen process: Ugh, yeah, I've run into this too. Acked-by: Dave Hansen <dave.han...@intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

On 02/21/2018 09:15 AM, Khalid Aziz wrote: > +#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr) > +static inline int sparc_validate_prot(unsigned long prot, unsigned long addr) > +{ > + if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI)) > +

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

On 02/21/2018 09:15 AM, Khalid Aziz wrote: > +tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm, > + struct vm_area_struct *vma, > + unsigned long addr) ... > + tags = kzalloc(size, GFP_NOWAIT|__GFP_NOWARN); > + if

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

On 03/05/2018 01:14 PM, Khalid Aziz wrote: > On 03/05/2018 12:22 PM, Dave Hansen wrote: >> On 02/21/2018 09:15 AM, Khalid Aziz wrote: >>> +#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr) >>> +static inline int sparc_validate_prot(unsigned long p

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

On 03/05/2018 01:14 PM, Khalid Aziz wrote: > Are you suggesting that vma returned by find_vma() could be split or > merged underneath me if I do not hold mmap_sem and thus make the flag > check invalid? If so, that is a good point. This part does make me think that this code hasn't been tested

Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

On 03/05/2018 01:37 PM, Khalid Aziz wrote: >> How big can this storage get, btw?  Superficially it seems like it might >> be able to be gigantic for a large, sparse VMA. >> > Tags are stored only for the pages being swapped out, not for the pages > in entire vma. Each tag storage page can hold