lkml.org 
[lkml]   [2015]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v10 02/17] x86_64: add KASan support
On Thu, 29 Jan 2015 18:11:46 +0300 Andrey Ryabinin <a.ryabinin@samsung.com> wrote:

> This patch adds arch specific code for kernel address sanitizer.
>
> 16TB of virtual addressed used for shadow memory.
> It's located in range [ffffec0000000000 - fffffc0000000000]
> between vmemmap and %esp fixup stacks.
>
> At early stage we map whole shadow region with zero page.
> Latter, after pages mapped to direct mapping address range
> we unmap zero pages from corresponding shadow (see kasan_map_shadow())
> and allocate and map a real shadow memory reusing vmemmap_populate()
> function.
>
> Also replace __pa with __pa_nodebug before shadow initialized.
> __pa with CONFIG_DEBUG_VIRTUAL=y make external function call (__phys_addr)
> __phys_addr is instrumented, so __asan_load could be called before
> shadow area initialized.
>
> ...
>
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -5,6 +5,7 @@ if HAVE_ARCH_KASAN
>
> config KASAN
> bool "AddressSanitizer: runtime memory debugger"
> + depends on !MEMORY_HOTPLUG
> help
> Enables address sanitizer - runtime memory debugger,
> designed to find out-of-bounds accesses and use-after-free bugs.

That's a significant restriction. It has obvious runtime implications.
It also means that `make allmodconfig' and `make allyesconfig' don't
enable kasan, so compile coverage will be impacted.

This wasn't changelogged. What's the reasoning and what has to be done
to fix it?


\
 
 \ /
  Last update: 2015-01-30 00:21    [W:0.391 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site