All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] kasan, module, vmalloc: rework shadow allocation for modules
Date: Fri, 27 Feb 2015 15:20:05 +0300	[thread overview]
Message-ID: <54F060F5.10502@samsung.com> (raw)
In-Reply-To: <87vbiplarm.fsf@rustcorp.com.au>

On 02/26/2015 04:30 AM, Rusty Russell wrote:
> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>> On 02/25/2015 09:25 AM, Rusty Russell wrote:
>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>> On 02/23/2015 11:26 AM, Rusty Russell wrote:
>>>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>>>> On 02/20/2015 03:15 AM, Rusty Russell wrote:
>>>>>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>>>>>> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>>>>>>>>> This is not portable.  Other archs don't use vmalloc, or don't use
>>>>>>>>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>>>>>>>>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
>>>>>>>> I could hide this into arch-specific function: 'kasan_need_to_allocate_shadow(const void *addr)'
>>>>>>>> or make make all those functions weak and allow arch code to redefine them.
>>>>>>>
>>>>>>> That adds another layer of indirection.  And how would the caller of
>>>>>>> plain vmalloc() even know what to return?
>>>>>>>
>>>>>>
>>>>>> I think I don't understand what do you mean here. vmalloc() callers shouldn't know
>>>>>> anything about kasan/shadow.
>>>>>
>>>>> How else would kasan_need_to_allocate_shadow(const void *addr) work for
>>>>> architectures which don't have a reserved vmalloc region for modules?
>>>>>
>>>>
>>>>
>>>> I think I need to clarify what I'm doing.
>>>>
>>>> Address sanitizer algorithm in short:
>>>> -------------------------------------
>>>> Every memory access is transformed by the compiler in the following way:
>>>>
>>>> Before:
>>>> 	*address = ...;
>>>>
>>>> after:
>>>>
>>>> 	if (memory_is_poisoned(address)) {
>>>> 		report_error(address, access_size);
>>>> 	}
>>>> 	*address = ...;
>>>>
>>>> where memory_is_poisoned():
>>>> 	bool memory_is_poisoned(unsigned long addr)
>>>> 	{
>>>>         	s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
>>>> 	        if (unlikely(shadow_value)) {
>>>>         	        s8 last_accessible_byte = addr & KASAN_SHADOW_MASK;
>>>>                 	return unlikely(last_accessible_byte >= shadow_value);
>>>> 	        }
>>>> 	        return false;
>>>> 	}
>>>> --------------------------------------
>>>>
>>>> So shadow memory should be present for every accessible address in kernel
>>>> otherwise it will be unhandled page fault on reading shadow value.
>>>>
>>>> Shadow for vmalloc addresses (on x86_64) is readonly mapping of one zero page.
>>>> Zero byte in shadow means that it's ok to access to that address.
>>>> Currently we don't catch bugs in vmalloc because most of such bugs could be caught
>>>> in more simple way with CONFIG_DEBUG_PAGEALLOC.
>>>> That's why we don't need RW shadow for vmalloc, it just one zero page that readonly
>>>> mapped early on boot for the whole [kasan_mem_to_shadow(VMALLOC_START, kasan_mem_to_shadow(VMALLOC_END)] range
>>>> So every access to vmalloc range assumed to be valid.
>>>>
>>>> To catch out of bounds accesses in global variables we need to fill shadow corresponding
>>>> to variable's redzone with non-zero (negative) values.
>>>> So for kernel image and modules we need a writable shadow.
>>>>
>>>> If some arch don't have separate address range for modules and it uses general vmalloc()
>>>> shadow for vmalloc should be writable, so it means that shadow has to be allocated
>>>> for every vmalloc() call.
>>>>
>>>> In such arch kasan_need_to_allocate_shadow(const void *addr) should return true for every vmalloc address:
>>>> bool kasan_need_to_allocate_shadow(const void *addr)
>>>> {
>>>> 	return addr >= VMALLOC_START && addr < VMALLOC_END;
>>>> }
>>>
>>> Thanks for the explanation.
>>>
>>>> All above means that current code is not very portable.
>>>> And 'kasan_module_alloc(p, size) after module alloc' approach is not portable
>>>> too. This won't work for arches that use [VMALLOC_START, VMALLOC_END] addresses for modules,
>>>> because now we need to handle all vmalloc() calls.
>>>
>>> I'm confused.  That's what you do now, and it hasn't been a problem,
>>> has it?  The problem is on the freeing from interrupt context...
>>>
>>
>> It's not problem now. It's only about portability.
> 
> Your first patch in this conversation says "Current approach in handling
> shadow memory for modules is broken."
> 

Sorry, my last answer was even more confusing.
You are right, the main problem is on the freeing form interrupts.

I meant that this:

> This won't work for arches that use [VMALLOC_START, VMALLOC_END] addresses for modules,
> because now we need to handle all vmalloc() calls.

is not a problem for now.



>>> #define VM_KASAN		0x00000080      /* has shadow kasan map */
>>>
>>> Set that in kasan_module_alloc():
>>>
>>>         if (ret) {
>>>                 struct vm_struct *vma = find_vm_area(addr);
>>>
>>>                 BUG_ON(!vma);
>>>                 /* Set VM_KASAN so vfree() can free up shadow. */
>>>                 vma->flags |= VM_KASAN;
>>>         }
>>>
>>> And check that in __vunmap():
>>>
>>>         if (area->flags & VM_KASAN)
>>>                 kasan_module_free(addr);
>>>
>>> That is portable, and is actually a fairly small patch on what you
>>> have at the moment.
>>>
>>> What am I missing?
>>>
>>
>> That is not portable.
>> Architectures that don't have separate region for modules should allocate shadow
>> for every vmalloc() call, not only for modules.
> 
> OK, I didn't appreciate that.  But couldn't you still use the "R/O
> shared zero page shadow" for vmalloc, and have kasan_module_alloc()
> simply replace the pages with r/w ones (and kasan_module_free()
> would have to remove it again).
> 
>> Actually I'm fine with what you are proposing here. I think that portability issues could be fixed
>> latter when this will become a real problem.
> 
> OK.
> 
> Thanks for your patience!
> Rusty.
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] kasan, module, vmalloc: rework shadow allocation for modules
Date: Fri, 27 Feb 2015 15:20:05 +0300	[thread overview]
Message-ID: <54F060F5.10502@samsung.com> (raw)
In-Reply-To: <87vbiplarm.fsf@rustcorp.com.au>

On 02/26/2015 04:30 AM, Rusty Russell wrote:
> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>> On 02/25/2015 09:25 AM, Rusty Russell wrote:
>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>> On 02/23/2015 11:26 AM, Rusty Russell wrote:
>>>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>>>> On 02/20/2015 03:15 AM, Rusty Russell wrote:
>>>>>>> Andrey Ryabinin <a.ryabinin@samsung.com> writes:
>>>>>>>> On 02/19/2015 02:10 AM, Rusty Russell wrote:
>>>>>>>>> This is not portable.  Other archs don't use vmalloc, or don't use
>>>>>>>>> (or define) MODULES_VADDR.  If you really want to hook here, you'd
>>>>>>>>> need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
>>>>>>>> I could hide this into arch-specific function: 'kasan_need_to_allocate_shadow(const void *addr)'
>>>>>>>> or make make all those functions weak and allow arch code to redefine them.
>>>>>>>
>>>>>>> That adds another layer of indirection.  And how would the caller of
>>>>>>> plain vmalloc() even know what to return?
>>>>>>>
>>>>>>
>>>>>> I think I don't understand what do you mean here. vmalloc() callers shouldn't know
>>>>>> anything about kasan/shadow.
>>>>>
>>>>> How else would kasan_need_to_allocate_shadow(const void *addr) work for
>>>>> architectures which don't have a reserved vmalloc region for modules?
>>>>>
>>>>
>>>>
>>>> I think I need to clarify what I'm doing.
>>>>
>>>> Address sanitizer algorithm in short:
>>>> -------------------------------------
>>>> Every memory access is transformed by the compiler in the following way:
>>>>
>>>> Before:
>>>> 	*address = ...;
>>>>
>>>> after:
>>>>
>>>> 	if (memory_is_poisoned(address)) {
>>>> 		report_error(address, access_size);
>>>> 	}
>>>> 	*address = ...;
>>>>
>>>> where memory_is_poisoned():
>>>> 	bool memory_is_poisoned(unsigned long addr)
>>>> 	{
>>>>         	s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
>>>> 	        if (unlikely(shadow_value)) {
>>>>         	        s8 last_accessible_byte = addr & KASAN_SHADOW_MASK;
>>>>                 	return unlikely(last_accessible_byte >= shadow_value);
>>>> 	        }
>>>> 	        return false;
>>>> 	}
>>>> --------------------------------------
>>>>
>>>> So shadow memory should be present for every accessible address in kernel
>>>> otherwise it will be unhandled page fault on reading shadow value.
>>>>
>>>> Shadow for vmalloc addresses (on x86_64) is readonly mapping of one zero page.
>>>> Zero byte in shadow means that it's ok to access to that address.
>>>> Currently we don't catch bugs in vmalloc because most of such bugs could be caught
>>>> in more simple way with CONFIG_DEBUG_PAGEALLOC.
>>>> That's why we don't need RW shadow for vmalloc, it just one zero page that readonly
>>>> mapped early on boot for the whole [kasan_mem_to_shadow(VMALLOC_START, kasan_mem_to_shadow(VMALLOC_END)] range
>>>> So every access to vmalloc range assumed to be valid.
>>>>
>>>> To catch out of bounds accesses in global variables we need to fill shadow corresponding
>>>> to variable's redzone with non-zero (negative) values.
>>>> So for kernel image and modules we need a writable shadow.
>>>>
>>>> If some arch don't have separate address range for modules and it uses general vmalloc()
>>>> shadow for vmalloc should be writable, so it means that shadow has to be allocated
>>>> for every vmalloc() call.
>>>>
>>>> In such arch kasan_need_to_allocate_shadow(const void *addr) should return true for every vmalloc address:
>>>> bool kasan_need_to_allocate_shadow(const void *addr)
>>>> {
>>>> 	return addr >= VMALLOC_START && addr < VMALLOC_END;
>>>> }
>>>
>>> Thanks for the explanation.
>>>
>>>> All above means that current code is not very portable.
>>>> And 'kasan_module_alloc(p, size) after module alloc' approach is not portable
>>>> too. This won't work for arches that use [VMALLOC_START, VMALLOC_END] addresses for modules,
>>>> because now we need to handle all vmalloc() calls.
>>>
>>> I'm confused.  That's what you do now, and it hasn't been a problem,
>>> has it?  The problem is on the freeing from interrupt context...
>>>
>>
>> It's not problem now. It's only about portability.
> 
> Your first patch in this conversation says "Current approach in handling
> shadow memory for modules is broken."
> 

Sorry, my last answer was even more confusing.
You are right, the main problem is on the freeing form interrupts.

I meant that this:

> This won't work for arches that use [VMALLOC_START, VMALLOC_END] addresses for modules,
> because now we need to handle all vmalloc() calls.

is not a problem for now.



>>> #define VM_KASAN		0x00000080      /* has shadow kasan map */
>>>
>>> Set that in kasan_module_alloc():
>>>
>>>         if (ret) {
>>>                 struct vm_struct *vma = find_vm_area(addr);
>>>
>>>                 BUG_ON(!vma);
>>>                 /* Set VM_KASAN so vfree() can free up shadow. */
>>>                 vma->flags |= VM_KASAN;
>>>         }
>>>
>>> And check that in __vunmap():
>>>
>>>         if (area->flags & VM_KASAN)
>>>                 kasan_module_free(addr);
>>>
>>> That is portable, and is actually a fairly small patch on what you
>>> have at the moment.
>>>
>>> What am I missing?
>>>
>>
>> That is not portable.
>> Architectures that don't have separate region for modules should allocate shadow
>> for every vmalloc() call, not only for modules.
> 
> OK, I didn't appreciate that.  But couldn't you still use the "R/O
> shared zero page shadow" for vmalloc, and have kasan_module_alloc()
> simply replace the pages with r/w ones (and kasan_module_free()
> would have to remove it again).
> 
>> Actually I'm fine with what you are proposing here. I think that portability issues could be fixed
>> latter when this will become a real problem.
> 
> OK.
> 
> Thanks for your patience!
> Rusty.
> 


  reply	other threads:[~2015-02-27 12:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18 17:44 [PATCH] kasan, module, vmalloc: rework shadow allocation for modules Andrey Ryabinin
2015-02-18 17:44 ` Andrey Ryabinin
2015-02-18 23:10 ` Rusty Russell
2015-02-18 23:10   ` Rusty Russell
2015-02-19 13:21   ` Andrey Ryabinin
2015-02-19 13:21     ` Andrey Ryabinin
2015-02-20  0:15     ` Rusty Russell
2015-02-20  0:15       ` Rusty Russell
2015-02-20  7:47       ` Andrey Ryabinin
2015-02-20  7:47         ` Andrey Ryabinin
2015-02-23  8:26         ` Rusty Russell
2015-02-23  8:26           ` Rusty Russell
2015-02-24 12:58           ` Andrey Ryabinin
2015-02-24 12:58             ` Andrey Ryabinin
2015-02-25  6:25             ` Rusty Russell
2015-02-25  6:25               ` Rusty Russell
2015-02-25  7:56               ` Andrey Ryabinin
2015-02-25  7:56                 ` Andrey Ryabinin
2015-02-26  1:30                 ` Rusty Russell
2015-02-26  1:30                   ` Rusty Russell
2015-02-27 12:20                   ` Andrey Ryabinin [this message]
2015-02-27 12:20                     ` Andrey Ryabinin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F060F5.10502@samsung.com \
    --to=a.ryabinin@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.