On 9/15/23 03:59, Matteo Rizzo wrote:
> The goal of this patch series is to deterministically prevent cross-cache
> attacks in the SLUB allocator.
What's the cost?
On 9/15/23 14:13, Kees Cook wrote:
> On Fri, Sep 15, 2023 at 10:59:29AM +, Matteo Rizzo wrote:
>> From: Jann Horn
>>
>> SLAB_VIRTUAL reserves 512 GiB of virtual memory and uses them for both
>> struct slab and the actual slab memory. The pointers returned by
>> kmem_cache_alloc will point to t
On 9/15/23 03:59, Matteo Rizzo wrote:
> + spin_lock_irqsave(&slub_kworker_lock, irq_flags);
> + list_splice_init(&slub_tlbflush_queue, &local_queue);
> + list_for_each_entry(slab, &local_queue, flush_list_elem) {
> + unsigned long start = (unsigned long)slab_to_virt(slab);
>
On 9/19/23 06:42, Matteo Rizzo wrote:
> On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
>> What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
>> user-space execution and kernel-space execution?
>>
> Same benchmark as before (compiling a kernel on a system running the pat
On 9/19/23 08:48, Matteo Rizzo wrote:
>> I think the whole "make it one single compile-time option" model is
>> completely and fundamentally broken.
> Wouldn't making this toggleable at boot time or runtime make performance
> even worse?
Maybe.
But you can tolerate even more of a performance impa
On 2/23/24 09:42, John Groves wrote:
> One of the key requirements for famfs is that it service vma faults
> efficiently. Our metadata helps - the search order is n for n extents,
> and n is usually 1. But we can still observe gnarly lock contention
> in mm if PTE faults are happening. This commit
On 2/23/24 12:39, John Groves wrote:
>> We had similar unit test regression concerns with fsdax where some
>> upstream change silently broke PMD faults. The solution there was trace
>> points in the fault handlers and a basic test that knows apriori that it
>> *should* be triggering a certain numbe
On 7/25/19 6:50 AM, Vincenzo Frascino wrote:
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
I don't see a lot of description of why this
On 8/7/19 8:53 AM, Catalin Marinas wrote:
> +- mmap() done by the process itself (or its parent), where either:
> +
> + - flags have the **MAP_ANONYMOUS** bit set
> + - the file descriptor refers to a regular file (including those returned
> +by memfd_create()) or **/dev/zero**
What's a "reg
On 8/8/19 10:27 AM, Catalin Marinas wrote:
> On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:
> Extending the interface is still possible even with the current
> proposal, by changing arg2 etc. We also don't seem to be consistent in
> sys_prctl().
We are not consisten
On 8/13/19 1:52 PM, Yu-cheng Yu wrote:
> To prevent function call/return spills into the next shadow stack
> area, do not merge shadow stack areas.
How does this prevent call/return spills?
> +#if defined(CONFIG_X86_INTEL_SHADOW_STACK_USER)
> +static inline pte_t pte_move_flags(pte_t pte, pteval_t from, pteval_t to)
> +{
> + if (pte_flags(pte) & from)
> + pte = pte_set_flags(pte_clear_flags(pte, from), to);
> + return pte;
Why is this conditional on the compile op
On 8/14/19 9:27 AM, Yu-cheng Yu wrote:
> On Tue, 2019-08-13 at 15:55 -0700, Andy Lutomirski wrote:
>> On Tue, Aug 13, 2019 at 2:02 PM Yu-cheng Yu wrote:
>>> When a task does fork(), its shadow stack (SHSTK) must be duplicated
>>> for the child. This patch implements a flow similar to copy-on-writ
On 8/14/19 9:42 AM, Yu-cheng Yu wrote:
> On Tue, 2019-08-13 at 16:02 -0700, Dave Hansen wrote:
> [...]
>> Please also reconcile the supervisor XSAVE portion of your patches with
>> the ones that Fenghua has been sending around. I've given quite a bit
>> of feedb
Intel will adhere to this process for future hardware embargoed
issues. This series contains a patch from Tony Luck with him
volunteering to be Intel's ambassador for this process.
These are some minor improvements here to the process document. I've
had the pleasure of seeing some of the problem
From: Dave Hansen
Hardware companies like Intel have lots of information which they
want to disclose to some folks but not others. Non-disclosure
agreements are a tool of choice for helping to ensure that the
flow of information is controlled.
But, they have caused problems in mitigation
-by: Tony Luck
Signed-off-by: Dave Hansen
---
b/Documentation/process/embargoed-hardware-issues.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
Documentation/process/embargoed-hardware-issues.rst~Documentation-process-Volunteer-as-the-ambassador-for-Intel
Documentation
From: Dave Hansen
Transparency is good. It it essential for everyone working under an
embargo to know who is involved and who else is a "knower". Being
transparent allows everyone to always make informed decisions about
ongoing participating in a mitigation effort.
Add a s
From: Dave Hansen
Both hardware companies and the kernel community prefer coordinated
disclosure to the alternatives. It is also obvious that sitting on
ready-to-go mitigations for months is not so nice for kernel
maintainers.
I want to ensure that the patched text can not be read as &quo
On 9/11/19 3:11 AM, Sasha Levin wrote:
>> +Disclosing parties may have shared information about an issue under a
>> +non-disclosure agreement with third parties. In order to ensure that
>> +these agreements do not interfere with the mitigation development
>> +process, the disclosing party must pro
On 9/11/19 8:44 AM, Greg KH wrote:
> Intel had months of review time for this document before this was
> published. Your lawyers had it and never objected to this lack of
> inclusion at all, and explictitly said that the document as written was
> fine with them. So I'm sorry, but it is much too l
esses the concerns I had about individuals who the community
needs to participate but which might be encumbered by an agreement
between their employer and the disclosing party.
To be explicit, this ack does not represent any official Intel position
and has not been reviewed by anyone at Intel
On 10/16/19 1:39 AM, Marco Elver wrote:
> This patch enables KCSAN for x86, with updates to build rules to not use
> KCSAN for several incompatible compilation units.
First of all KCSAN looks really interesting!
For the x86 code, though, I'd really appreciate some specific notes on
why individual
> +/*
> + * Helpers for changing XSAVES system states.
> + */
> +static inline void modify_fpu_regs_begin(void)
> +{
> + fpregs_lock();
> + if (test_thread_flag(TIF_NEED_FPU_LOAD))
> + __fpregs_load_activate();
> +}
> +
> +static inline void modify_fpu_regs_end(void)
> +{
> +
On 6/6/19 3:04 PM, Andy Lutomirski wrote:
>> But, that seems broken. If we have supervisor state, we can't
>> always defer the load until return to userspace, so we'll never??
>> have TIF_NEED_FPU_LOAD. That would certainly be true for
>> cet_kernel_state.
>
> Ugh. I was sort of imagining
On 6/7/19 9:35 AM, Andy Lutomirski wrote:
> One might reasonably wonder why this state is privileged in the first
> place and, given that, why we’re allowing it to be written like
> this.
I think it's generally a good architectural practice to make things like
this privileged. They're infrequent
On 6/7/19 10:43 AM, Peter Zijlstra wrote:
> I've no idea what the kernel should do; since you failed to answer the
> question what happens when you point this to garbage.
>
> Does it then fault or what?
Yeah, I think you'll fault with a rather mysterious CR2 value since
you'll go look at the inst
On 6/7/19 11:29 AM, Andy Lutomirski wrote:
...
>> I think this new MSR probably needs to get included in oops output when
>> CET is enabled.
>
> This shouldn’t be able to OOPS because it only happens at CPL 3,
> right? We should put it into core dumps, though.
Good point.
Yu-cheng, can you just
On 6/6/19 1:09 PM, Yu-cheng Yu wrote:
> + modify_fpu_regs_begin();
> + rdmsrl(MSR_IA32_U_CET, r);
> + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> + wrmsrl(MSR_IA32_U_CET, r);
> + modify_fpu_regs_end();
Isn't there a bunch of other stuff in this MSR? It seems like the
bitmap valu
On 6/7/19 12:49 PM, Yu-cheng Yu wrote:
>>
>> This also gives us an excellent opportunity to make it read-only as seen from
>> userspace to prevent exploits from just poking it full of ones before
>> redirecting execution.
> GLIBC sets bits only for legacy code, and then makes the bitmap read-only.
On 6/7/19 1:40 PM, Andy Lutomirski wrote:
>>> Hmm. Can we be creative and skip populating it with zeros? The
>>> CPU
>> should only ever touch a page if we miss an ENDBR on it, so, in
>> normal operation, we don’t need anything to be there. We could try
>> to prevent anyone from *reading* it out
On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>> Huh, how does glibc know about all possible past and future legacy code
>> in the application?
> When dlopen() gets a legacy binary and the policy allows that, it will manage
> the bitmap:
>
> If a bitmap has not been created, create one.
> Set bits for
On 6/10/19 9:05 AM, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:
>> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>>>> Huh, how does glibc know about all possible past and future legacy code
>>>> in the application?
>>> When dlopen()
On 6/10/19 8:22 AM, Yu-cheng Yu wrote:
>> How does glibc know the linear address space size? We don’t want LA64 to
>> break old binaries because the address calculation changed.
> When an application starts, its highest stack address is determined.
> It uses that as the maximum the bitmap needs to
On 6/10/19 12:38 PM, Yu-cheng Yu wrote:
>>> When an application starts, its highest stack address is determined.
>>> It uses that as the maximum the bitmap needs to cover.
>> Huh, I didn't think we ran code from the stack. ;)
>>
>> Especially given the way that we implemented the new 5-level-paging
On 6/10/19 1:27 PM, Yu-cheng Yu wrote:
>>> If the loader cannot allocate a big bitmap to cover all 5-level
>>> address space (the bitmap will be large), it can put all legacy lib's
>>> at lower address. We cannot do these easily in the kernel.
>> This is actually an argument to do it in the kernel
On 6/10/19 1:58 PM, Yu-cheng Yu wrote:
>>> On each memory request, the kernel then must consider a percentage of
>>> allocated space in its calculation, and on systems with less memory
>>> this quickly becomes a problem.
>> I'm not sure what you're referring to here? Are you referring to our
>> ov
On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
> VM_DONTDUMP. The bitmap will cover only 48-bit address space.
Could you make sure to discuss the downsides of only doing a 48-bit
address space?
What are the reasons behind and implica
On 6/10/19 4:20 PM, H.J. Lu wrote:
>>> Perhaps we still let the app fill the bitmap?
>> I think I'd want to see some performance data on it first.
> Updating legacy bitmap in user space from kernel requires
>
> long q;
>
> get_user(q, ...);
> q |= mask;
> put_user(q, ...);
>
> instead of
>
> *p
On 6/10/19 4:54 PM, Andy Lutomirski wrote:
> Another benefit of kernel management: we could plausibly auto-clear
> the bits corresponding to munmapped regions. Is this worth it?
I did it for MPX. I think I even went to the trouble of zapping the
whole pages that got unused.
But, MPX tables took
On 6/6/19 1:06 PM, Yu-cheng Yu wrote:
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1703,6 +1703,9 @@ static inline int accountable_mapping(struct file
> *file, vm_flags_t vm_flags)
> if (file && is_file_hugepages(file))
> return 0;
>
> + if (arch_copy_pte_mapping(vm_flags))
On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
> On Mon, 2019-06-10 at 15:59 -0700, Dave Hansen wrote:
>> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
>>> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
>>> VM_DONTDUMP. The bitmap will cover only 48-bit address
On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
>> On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
>>> The bitmap is very big.
>>
>> Really? It's actually, what, 8*4096=32k, so 1/32,768th of the size of
>> the lib
On 6/14/19 2:34 PM, Yu-cheng Yu wrote:
> On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
>>> I have a related question:
>>>
>>> Do we allow the application to read the bitmap, or any fault from the
>>> application on bitmap pages?
>>
>> We h
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 granular
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. Mayb
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
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
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
On 01/11/2017 04:22 PM, Khalid Aziz wrote:
...
> All of the tag coordination can happen in userspace. Once a process sets
> a tag on a physical page mapped in its address space, another process
> that has mapped the same physical page in its address space can only set
> the tag to exact same value.
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 inte
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
databases
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)
> {
>
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)
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
> long)(
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
> /sys/ke
On 04/24/2017 08:53 AM, Tom Lendacky wrote:
> On 4/21/2017 4:52 PM, Dave Hansen wrote:
>> 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_sym
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.
>>>
>>>
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
> accessed/allo
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
> ---
> fs/proc/task_mmu.c |6 +-
> inc
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 c
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 a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/f
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 k
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 deletions(-)
>
> diff --git a/D
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
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 we
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)
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/*
> ==> /sys/kernel/mm/protectio
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)
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))
> +
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 (tags
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
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 ver
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 tags
From: Dave Hansen
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 prefer to disclose things until
From: Dave Hansen
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, it's not coordinated
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
--
To unsubscribe from this list: send the line &q
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 shad
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
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
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/sel
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 >= 0)
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 a/tools/testing/selftests/v
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;
> +
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc"
w pkey register, which is supposed to track the bits
> accurately all throughout
>
> cc: Dave Hansen
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/selftests/vm/protection_keys.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
On 02/21/2018 05:55 PM, Ram Pai wrote:
> cleanup the code to satisfy coding styles.
>
> cc: Dave Hansen
> cc: Florian Weimer
> Signed-off-by: Ram Pai
> ---
> tools/testing/selftests/vm/protection_keys.c | 81
> ++
> 1 files changed, 43
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 /* arc
On 02/21/2018 05:55 PM, Ram Pai wrote:
> diff --git a/tools/testing/selftests/vm/protection_keys.c
> b/tools/testing/selftests/vm/protection_keys.c
> index c4c73e6..e82bd88 100644
> --- a/tools/testing/selftests/vm/protection_keys.c
> +++ b/tools/testing/selftests/vm/protection_keys.c
> @@ -586,7
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.
>
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 NR_RESERVED_PKEY
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
--
To unsubscribe from this list: send the line "
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc"
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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a m
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 s
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
> /*
eah, I've run into this too.
Acked-by: Dave Hansen
--
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
On 03/28/2018 01:47 PM, Thiago Jung Bauermann wrote:
>>> if (flags)
>>> - assert(rdpkey_reg() > orig_pkey_reg);
>>> + assert(rdpkey_reg() < orig_pkey_reg);
>>> }
>>>
>>> void pkey_write_allow(int pkey)
>> This seems so horribly wrong that I wonder how it worked in the firs
On 12/10/18 3:12 PM, Josh Triplett wrote:
>> Or maybe even python/shell scripts? It looked to me like virtual
>> memory will be "interesting" for enclaves.
> Memory management doesn't seem that hard to deal with.
The problems are:
1. SGX enclave memory (EPC) is statically allocated at boot and ca
On 1/7/19 6:15 AM, Matthew Wilcox wrote:
> You're going to get data corruption doing this. try_to_unmap_one()
> does:
>
> /* Move the dirty bit to the page. Now the pte is gone. */
> if (pte_dirty(pteval))
> set_page_dirty(page);
>
> so PageDirty() can be false
On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> The following testing approaches has been taken to find potential issues
> with user pointer untagging:
>
> 1. Static testing (with sparse [3] and separately with a custom static
>analyzer based on Clang) to track casts of __user pointers to intege
1 - 100 of 146 matches
Mail list logo
