Re: [PATCH 2/2] arm64: add KASan support

2015-04-20 Thread Andrey Ryabinin 
On 04/17/2015 09:39 PM, David Keitel wrote:
> On 04/15/2015 11:04 AM, Andrey Ryabinin wrote:
>> I've pushed the most fresh thing that I have in git:
>>  git://github.com/aryabinin/linux.git kasan/arm64v1
>>
>> It's the same patches with two simple but important fixes on top of it.
> 
> Thanks, the two commits do fix compilation issues that I've had worked around 
> to get to my mapping question.
> 
> I've addressed the mapping problem using __create_page_tables in 
> arch/arm64/head.S as an example.
> 
> The next roadblock I hit was running into kasan_report_error calls in 
> cgroups_early_init. After a short investigation it does seem to be a false 
> positive due the the kasan_zero_page size and tracking bytes being reused for 
> different memory regions.
> 
> I worked around that by enabling kasan error reporting only after the 
> kasan_init is run. This let me get to the shell with some real KAsan reports 
> along the way.

Reporting already disabled before kasan_init() and the last thing that 
kasan_init() is enable error reports.
So, how did you managed to get kasan's report before kasan_init()?

> There were some other fixes and hacks to get there. I'll backtrack to 
> evaluate which ones warrant an RFC.
> 
>  - David
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-20 Thread Andrey Ryabinin 
On 04/17/2015 09:39 PM, David Keitel wrote:
 On 04/15/2015 11:04 AM, Andrey Ryabinin wrote:
 I've pushed the most fresh thing that I have in git:
  git://github.com/aryabinin/linux.git kasan/arm64v1

 It's the same patches with two simple but important fixes on top of it.
 
 Thanks, the two commits do fix compilation issues that I've had worked around 
 to get to my mapping question.
 
 I've addressed the mapping problem using __create_page_tables in 
 arch/arm64/head.S as an example.
 
 The next roadblock I hit was running into kasan_report_error calls in 
 cgroups_early_init. After a short investigation it does seem to be a false 
 positive due the the kasan_zero_page size and tracking bytes being reused for 
 different memory regions.
 
 I worked around that by enabling kasan error reporting only after the 
 kasan_init is run. This let me get to the shell with some real KAsan reports 
 along the way.

Reporting already disabled before kasan_init() and the last thing that 
kasan_init() is enable error reports.
So, how did you managed to get kasan's report before kasan_init()?

 There were some other fixes and hacks to get there. I'll backtrack to 
 evaluate which ones warrant an RFC.
 
  - David
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-17 Thread David Keitel 
On 04/15/2015 11:04 AM, Andrey Ryabinin wrote:
> I've pushed the most fresh thing that I have in git:
>   git://github.com/aryabinin/linux.git kasan/arm64v1
> 
> It's the same patches with two simple but important fixes on top of it.

Thanks, the two commits do fix compilation issues that I've had worked around 
to get to my mapping question.

I've addressed the mapping problem using __create_page_tables in 
arch/arm64/head.S as an example.

The next roadblock I hit was running into kasan_report_error calls in 
cgroups_early_init. After a short investigation it does seem to be a false 
positive due the the kasan_zero_page size and tracking bytes being reused for 
different memory regions.

I worked around that by enabling kasan error reporting only after the 
kasan_init is run. This let me get to the shell with some real KAsan reports 
along the way. There were some other fixes and hacks to get there. I'll 
backtrack to evaluate which ones warrant an RFC.

 - David

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-17 Thread David Keitel 
On 04/15/2015 11:04 AM, Andrey Ryabinin wrote:
 I've pushed the most fresh thing that I have in git:
   git://github.com/aryabinin/linux.git kasan/arm64v1
 
 It's the same patches with two simple but important fixes on top of it.

Thanks, the two commits do fix compilation issues that I've had worked around 
to get to my mapping question.

I've addressed the mapping problem using __create_page_tables in 
arch/arm64/head.S as an example.

The next roadblock I hit was running into kasan_report_error calls in 
cgroups_early_init. After a short investigation it does seem to be a false 
positive due the the kasan_zero_page size and tracking bytes being reused for 
different memory regions.

I worked around that by enabling kasan error reporting only after the 
kasan_init is run. This let me get to the shell with some real KAsan reports 
along the way. There were some other fixes and hacks to get there. I'll 
backtrack to evaluate which ones warrant an RFC.

 - David

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-15 Thread Andrey Ryabinin 
On 04/15/2015 05:37 AM, David Keitel wrote:
 +  pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
 +#else
 +  pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
 +#endif
 +
 +  for (i = pgd_index(start); start < end; i++) {
 +  set_pgd([i], pgd);
 +  start += PGDIR_SIZE;
 +  }
 +}
>>>
>>> Same problem as above with PAGE_KERNEL. You should just use
>>> pgd_populate().
> 
> Any suggestion what the correct flag setting would be here for a 4K mapping?
> 
> I tried fixing this by changing this to pud and setting the PMD_TYPE_TABLE 
> flag for kasan_zero_pmd. However the MMU doesn't like it and I get a first 
> level address translation fault.
> 
> If you have any updated patches to share I'd be glad to try them out.
> 

Sorry, I didn't have much time on work on this yet.

I've pushed the most fresh thing that I have in git:
git://github.com/aryabinin/linux.git kasan/arm64v1

It's the same patches with two simple but important fixes on top of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-15 Thread Andrey Ryabinin 
On 04/15/2015 05:37 AM, David Keitel wrote:
 +  pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
 +#else
 +  pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
 +#endif
 +
 +  for (i = pgd_index(start); start  end; i++) {
 +  set_pgd(pgdp[i], pgd);
 +  start += PGDIR_SIZE;
 +  }
 +}

 Same problem as above with PAGE_KERNEL. You should just use
 pgd_populate().
 
 Any suggestion what the correct flag setting would be here for a 4K mapping?
 
 I tried fixing this by changing this to pud and setting the PMD_TYPE_TABLE 
 flag for kasan_zero_pmd. However the MMU doesn't like it and I get a first 
 level address translation fault.
 
 If you have any updated patches to share I'd be glad to try them out.
 

Sorry, I didn't have much time on work on this yet.

I've pushed the most fresh thing that I have in git:
git://github.com/aryabinin/linux.git kasan/arm64v1

It's the same patches with two simple but important fixes on top of it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-14 Thread David Keitel 
>>> +   pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
>>> +#else
>>> +   pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
>>> +#endif
>>> +
>>> +   for (i = pgd_index(start); start < end; i++) {
>>> +   set_pgd([i], pgd);
>>> +   start += PGDIR_SIZE;
>>> +   }
>>> +}
>>
>> Same problem as above with PAGE_KERNEL. You should just use
>> pgd_populate().

Any suggestion what the correct flag setting would be here for a 4K mapping?

I tried fixing this by changing this to pud and setting the PMD_TYPE_TABLE flag 
for kasan_zero_pmd. However the MMU doesn't like it and I get a first level 
address translation fault.

If you have any updated patches to share I'd be glad to try them out.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-14 Thread David Keitel 
 +   pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
 +#else
 +   pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
 +#endif
 +
 +   for (i = pgd_index(start); start  end; i++) {
 +   set_pgd(pgdp[i], pgd);
 +   start += PGDIR_SIZE;
 +   }
 +}

 Same problem as above with PAGE_KERNEL. You should just use
 pgd_populate().

Any suggestion what the correct flag setting would be here for a 4K mapping?

I tried fixing this by changing this to pud and setting the PMD_TYPE_TABLE flag 
for kasan_zero_pmd. However the MMU doesn't like it and I get a first level 
address translation fault.

If you have any updated patches to share I'd be glad to try them out.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-09 Thread Arnd Bergmann 
On Tuesday 24 March 2015 17:49:04 Andrey Ryabinin wrote:
>  arch/arm64/mm/kasan_init.c   | 211 
> +++
> 

Just one very high-level question: as this code is clearly derived from
the x86 version and nontrivial, could we move most of it out of
arch/{x86,arm64} into mm/kasan/init.c and have the rest in some header
file?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-09 Thread Arnd Bergmann 
On Tuesday 24 March 2015 17:49:04 Andrey Ryabinin wrote:
  arch/arm64/mm/kasan_init.c   | 211 
 +++
 

Just one very high-level question: as this code is clearly derived from
the x86 version and nontrivial, could we move most of it out of
arch/{x86,arm64} into mm/kasan/init.c and have the rest in some header
file?

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: add KASan support

2015-04-03 Thread Andrey Ryabinin 
On 04/01/2015 03:28 PM, Catalin Marinas wrote:
> Hi Andrey,
> 

Hi Catalin,

> On Tue, Mar 24, 2015 at 05:49:04PM +0300, Andrey Ryabinin wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 4085df1..10bbd71 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -41,6 +41,7 @@ config ARM64
>>  select HAVE_ARCH_AUDITSYSCALL
>>  select HAVE_ARCH_BITREVERSE
>>  select HAVE_ARCH_JUMP_LABEL
>> +select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
>>  select HAVE_ARCH_KGDB
>>  select HAVE_ARCH_SECCOMP_FILTER
>>  select HAVE_ARCH_TRACEHOOK
>> @@ -116,6 +117,12 @@ config GENERIC_CSUM
>>  config GENERIC_CALIBRATE_DELAY
>>  def_bool y
>>  
>> +config KASAN_SHADOW_OFFSET
>> +hex
>> +default 0xdfff2000 if ARM64_VA_BITS_48
>> +default 0xdc80 if ARM64_VA_BITS_42
>> +default 0xdf90 if ARM64_VA_BITS_39
> 
> Can we compute these at build time in some C header? Or they need to be
> passed to gcc when compiling the kernel so that it generates the right
> instrumentation?
> 

Correct, this value passed to GCC.

> I'm not familiar with KASan but is the offset address supposed to be
> accessible? The addresses encoded above would always generate a fault
> (level 0 / address size fault).
> 

It's fine. KASAN_SHADOW_OFFSET address is shadow address that corresponds to 0 
address.
So KASAN_SHADOW_OFFSET could be dereferenced only if we have NULL-ptr 
derefernce in kernel.

Shadow for kernel addresses starts from KASAN_SHADOW_START constant,
which is defined in arch/arm64/include/asm/kasan.h. But since I forgot to 'git 
add' that file
it's not present in this patch.

arch/arm64/include/asm/kasan.h:

/*
 * Compiler uses shadow offset assuming that addresses start
 * from 0. Kernel addresses don't start from 0, so shadow
 * for kernel really starts from 'compiler's shadow offset' +
 * ('kernel address space start' >> KASAN_SHADOW_SCALE_SHIFT)
 */
#define KASAN_SHADOW_START  (KASAN_SHADOW_OFFSET + \
((UL(0x) << (VA_BITS)) 
>> 3))

#define KASAN_SHADOW_END(KASAN_SHADOW_START + (1ULL << (VA_BITS - 3)))


>> diff --git a/arch/arm64/include/asm/pgtable.h 
>> b/arch/arm64/include/asm/pgtable.h
>> index bd5db28..f5ce010 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -40,7 +40,7 @@
>>   *  fixed mappings and modules
>>   */
>>  #define VMEMMAP_SIZEALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * 
>> sizeof(struct page), PUD_SIZE)
>> -#define VMALLOC_START   (UL(0x) << VA_BITS)
>> +#define VMALLOC_START   ((UL(0x) << VA_BITS) + 
>> (UL(1) << (VA_BITS - 3)))
> 
> I assume that's where you want to make room for KASan? Some comments and
> macros would be useful for why this is needed and how it is calculated.
> It also needs to be disabled when KASan is not enabled.
> 

Ok.

>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> index 51c9811..1a99e95 100644
>> --- a/arch/arm64/kernel/head.S
>> +++ b/arch/arm64/kernel/head.S
>> @@ -482,6 +482,9 @@ __mmap_switched:
>>  str_l   x21, __fdt_pointer, x5  // Save FDT pointer
>>  str_l   x24, memstart_addr, x6  // Save PHYS_OFFSET
>>  mov x29, #0
>> +#ifdef CONFIG_KASAN
>> +b kasan_early_init
>> +#endif
> 
> Nitpick: tab between b and kasan_early_init.
> 
>> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
>> new file mode 100644
>> index 000..df537da
>> --- /dev/null
>> +++ b/arch/arm64/mm/kasan_init.c
>> @@ -0,0 +1,211 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;
> 
> Can we not use the system's zero_page or it's not initialised yet?
> 

System's zero page allocated in paging_init() and that is too late.
But I could put system's zero page into bss and use it here if you ok with this.


>> +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
>> +
>> +#if CONFIG_PGTABLE_LEVELS > 3
>> +static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
>> +#endif
>> +#if CONFIG_PGTABLE_LEVELS > 2
>> +static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
>> +#endif
>> +static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
>> +
>> +static void __init init_kasan_page_tables(void)
>> +{
>> +int i;
>> +
>> +#if CONFIG_PGTABLE_LEVELS > 3
>> +for (i = 0; i < PTRS_PER_PUD; i++)
>> +set_pud(_zero_pud[i], __pud(__pa(kasan_zero_pmd)
>> +| PAGE_KERNEL));
>> +#endif
>> +#if CONFIG_PGTABLE_LEVELS > 2
>> +for (i = 0; i < PTRS_PER_PMD; i++)
>> +set_pmd(_zero_pmd[i], __pmd(__pa(kasan_zero_pte)
>> +| PAGE_KERNEL));
>> +#endif
> 
> These don't look right. You are setting

Re: [PATCH 2/2] arm64: add KASan support

2015-04-03 Thread Andrey Ryabinin 
On 04/01/2015 03:28 PM, Catalin Marinas wrote:
 Hi Andrey,
 

Hi Catalin,

 On Tue, Mar 24, 2015 at 05:49:04PM +0300, Andrey Ryabinin wrote:
 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index 4085df1..10bbd71 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -41,6 +41,7 @@ config ARM64
  select HAVE_ARCH_AUDITSYSCALL
  select HAVE_ARCH_BITREVERSE
  select HAVE_ARCH_JUMP_LABEL
 +select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
  select HAVE_ARCH_KGDB
  select HAVE_ARCH_SECCOMP_FILTER
  select HAVE_ARCH_TRACEHOOK
 @@ -116,6 +117,12 @@ config GENERIC_CSUM
  config GENERIC_CALIBRATE_DELAY
  def_bool y
  
 +config KASAN_SHADOW_OFFSET
 +hex
 +default 0xdfff2000 if ARM64_VA_BITS_48
 +default 0xdc80 if ARM64_VA_BITS_42
 +default 0xdf90 if ARM64_VA_BITS_39
 
 Can we compute these at build time in some C header? Or they need to be
 passed to gcc when compiling the kernel so that it generates the right
 instrumentation?
 

Correct, this value passed to GCC.

 I'm not familiar with KASan but is the offset address supposed to be
 accessible? The addresses encoded above would always generate a fault
 (level 0 / address size fault).
 

It's fine. KASAN_SHADOW_OFFSET address is shadow address that corresponds to 0 
address.
So KASAN_SHADOW_OFFSET could be dereferenced only if we have NULL-ptr 
derefernce in kernel.

Shadow for kernel addresses starts from KASAN_SHADOW_START constant,
which is defined in arch/arm64/include/asm/kasan.h. But since I forgot to 'git 
add' that file
it's not present in this patch.

arch/arm64/include/asm/kasan.h:

/*
 * Compiler uses shadow offset assuming that addresses start
 * from 0. Kernel addresses don't start from 0, so shadow
 * for kernel really starts from 'compiler's shadow offset' +
 * ('kernel address space start'  KASAN_SHADOW_SCALE_SHIFT)
 */
#define KASAN_SHADOW_START  (KASAN_SHADOW_OFFSET + \
((UL(0x)  (VA_BITS)) 
 3))

#define KASAN_SHADOW_END(KASAN_SHADOW_START + (1ULL  (VA_BITS - 3)))


 diff --git a/arch/arm64/include/asm/pgtable.h 
 b/arch/arm64/include/asm/pgtable.h
 index bd5db28..f5ce010 100644
 --- a/arch/arm64/include/asm/pgtable.h
 +++ b/arch/arm64/include/asm/pgtable.h
 @@ -40,7 +40,7 @@
   *  fixed mappings and modules
   */
  #define VMEMMAP_SIZEALIGN((1UL  (VA_BITS - PAGE_SHIFT)) * 
 sizeof(struct page), PUD_SIZE)
 -#define VMALLOC_START   (UL(0x)  VA_BITS)
 +#define VMALLOC_START   ((UL(0x)  VA_BITS) + 
 (UL(1)  (VA_BITS - 3)))
 
 I assume that's where you want to make room for KASan? Some comments and
 macros would be useful for why this is needed and how it is calculated.
 It also needs to be disabled when KASan is not enabled.
 

Ok.

 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
 index 51c9811..1a99e95 100644
 --- a/arch/arm64/kernel/head.S
 +++ b/arch/arm64/kernel/head.S
 @@ -482,6 +482,9 @@ __mmap_switched:
  str_l   x21, __fdt_pointer, x5  // Save FDT pointer
  str_l   x24, memstart_addr, x6  // Save PHYS_OFFSET
  mov x29, #0
 +#ifdef CONFIG_KASAN
 +b kasan_early_init
 +#endif
 
 Nitpick: tab between b and kasan_early_init.
 
 diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
 new file mode 100644
 index 000..df537da
 --- /dev/null
 +++ b/arch/arm64/mm/kasan_init.c
 @@ -0,0 +1,211 @@
 +#include linux/kasan.h
 +#include linux/kernel.h
 +#include linux/memblock.h
 +#include linux/start_kernel.h
 +
 +#include asm/page.h
 +#include asm/pgtable.h
 +#include asm/tlbflush.h
 +
 +static char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;
 
 Can we not use the system's zero_page or it's not initialised yet?
 

System's zero page allocated in paging_init() and that is too late.
But I could put system's zero page into bss and use it here if you ok with this.


 +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
 +
 +#if CONFIG_PGTABLE_LEVELS  3
 +static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
 +#endif
 +#if CONFIG_PGTABLE_LEVELS  2
 +static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
 +#endif
 +static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
 +
 +static void __init init_kasan_page_tables(void)
 +{
 +int i;
 +
 +#if CONFIG_PGTABLE_LEVELS  3
 +for (i = 0; i  PTRS_PER_PUD; i++)
 +set_pud(kasan_zero_pud[i], __pud(__pa(kasan_zero_pmd)
 +| PAGE_KERNEL));
 +#endif
 +#if CONFIG_PGTABLE_LEVELS  2
 +for (i = 0; i  PTRS_PER_PMD; i++)
 +set_pmd(kasan_zero_pmd[i], __pmd(__pa(kasan_zero_pte)
 +| PAGE_KERNEL));
 +#endif
 
 These don't look right. You are setting page attributes on table
 entries. You should use the standard pmd_populate etc. macros here, see

Re: [PATCH 2/2] arm64: add KASan support

2015-04-01 Thread Catalin Marinas 
Hi Andrey,

On Tue, Mar 24, 2015 at 05:49:04PM +0300, Andrey Ryabinin wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 4085df1..10bbd71 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -41,6 +41,7 @@ config ARM64
>   select HAVE_ARCH_AUDITSYSCALL
>   select HAVE_ARCH_BITREVERSE
>   select HAVE_ARCH_JUMP_LABEL
> + select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
>   select HAVE_ARCH_KGDB
>   select HAVE_ARCH_SECCOMP_FILTER
>   select HAVE_ARCH_TRACEHOOK
> @@ -116,6 +117,12 @@ config GENERIC_CSUM
>  config GENERIC_CALIBRATE_DELAY
>   def_bool y
>  
> +config KASAN_SHADOW_OFFSET
> + hex
> + default 0xdfff2000 if ARM64_VA_BITS_48
> + default 0xdc80 if ARM64_VA_BITS_42
> + default 0xdf90 if ARM64_VA_BITS_39

Can we compute these at build time in some C header? Or they need to be
passed to gcc when compiling the kernel so that it generates the right
instrumentation?

I'm not familiar with KASan but is the offset address supposed to be
accessible? The addresses encoded above would always generate a fault
(level 0 / address size fault).

> diff --git a/arch/arm64/include/asm/pgtable.h 
> b/arch/arm64/include/asm/pgtable.h
> index bd5db28..f5ce010 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -40,7 +40,7 @@
>   *   fixed mappings and modules
>   */
>  #define VMEMMAP_SIZE ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * 
> sizeof(struct page), PUD_SIZE)
> -#define VMALLOC_START(UL(0x) << VA_BITS)
> +#define VMALLOC_START((UL(0x) << VA_BITS) + 
> (UL(1) << (VA_BITS - 3)))

I assume that's where you want to make room for KASan? Some comments and
macros would be useful for why this is needed and how it is calculated.
It also needs to be disabled when KASan is not enabled.

> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 51c9811..1a99e95 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -482,6 +482,9 @@ __mmap_switched:
>   str_l   x21, __fdt_pointer, x5  // Save FDT pointer
>   str_l   x24, memstart_addr, x6  // Save PHYS_OFFSET
>   mov x29, #0
> +#ifdef CONFIG_KASAN
> + b kasan_early_init
> +#endif

Nitpick: tab between b and kasan_early_init.

> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> new file mode 100644
> index 000..df537da
> --- /dev/null
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -0,0 +1,211 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +static char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;

Can we not use the system's zero_page or it's not initialised yet?

> +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
> +
> +#if CONFIG_PGTABLE_LEVELS > 3
> +static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
> +#endif
> +#if CONFIG_PGTABLE_LEVELS > 2
> +static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
> +#endif
> +static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
> +
> +static void __init init_kasan_page_tables(void)
> +{
> + int i;
> +
> +#if CONFIG_PGTABLE_LEVELS > 3
> + for (i = 0; i < PTRS_PER_PUD; i++)
> + set_pud(_zero_pud[i], __pud(__pa(kasan_zero_pmd)
> + | PAGE_KERNEL));
> +#endif
> +#if CONFIG_PGTABLE_LEVELS > 2
> + for (i = 0; i < PTRS_PER_PMD; i++)
> + set_pmd(_zero_pmd[i], __pmd(__pa(kasan_zero_pte)
> + | PAGE_KERNEL));
> +#endif

These don't look right. You are setting page attributes on table
entries. You should use the standard pmd_populate etc. macros here, see
early_fixmap_init() as an example.

> + for (i = 0; i < PTRS_PER_PTE; i++)
> + set_pte(_zero_pte[i], __pte(__pa(kasan_zero_page)
> + | PAGE_KERNEL));

PAGE_KERNEL is pgprot_t, so you mix the types here. Just do something
like:

set_pte(..., pfn_pte(zero_pfn, PAGE_KERNEL_RO));

(shouldn't it be read-only?)

> +void __init kasan_map_early_shadow(pgd_t *pgdp)
> +{
> + int i;
> + unsigned long start = KASAN_SHADOW_START;
> + unsigned long end = KASAN_SHADOW_END;
> + pgd_t pgd;
> +
> +#if CONFIG_PGTABLE_LEVELS > 3
> + pgd = __pgd(__pa(kasan_zero_pud) | PAGE_KERNEL);
> +#elif CONFIG_PGTABLE_LEVELS > 2
> + pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
> +#else
> + pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
> +#endif
> +
> + for (i = pgd_index(start); start < end; i++) {
> + set_pgd([i], pgd);
> + start += PGDIR_SIZE;
> + }
> +}

Same problem as above with PAGE_KERNEL. You should just use
pgd_populate().

> +
> +void __init kasan_early_init(void)
> +{
> + init_kasan_page_tables();
> +

Re: [PATCH 2/2] arm64: add KASan support

2015-04-01 Thread Catalin Marinas 
Hi Andrey,

On Tue, Mar 24, 2015 at 05:49:04PM +0300, Andrey Ryabinin wrote:
 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index 4085df1..10bbd71 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -41,6 +41,7 @@ config ARM64
   select HAVE_ARCH_AUDITSYSCALL
   select HAVE_ARCH_BITREVERSE
   select HAVE_ARCH_JUMP_LABEL
 + select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
   select HAVE_ARCH_KGDB
   select HAVE_ARCH_SECCOMP_FILTER
   select HAVE_ARCH_TRACEHOOK
 @@ -116,6 +117,12 @@ config GENERIC_CSUM
  config GENERIC_CALIBRATE_DELAY
   def_bool y
  
 +config KASAN_SHADOW_OFFSET
 + hex
 + default 0xdfff2000 if ARM64_VA_BITS_48
 + default 0xdc80 if ARM64_VA_BITS_42
 + default 0xdf90 if ARM64_VA_BITS_39

Can we compute these at build time in some C header? Or they need to be
passed to gcc when compiling the kernel so that it generates the right
instrumentation?

I'm not familiar with KASan but is the offset address supposed to be
accessible? The addresses encoded above would always generate a fault
(level 0 / address size fault).

 diff --git a/arch/arm64/include/asm/pgtable.h 
 b/arch/arm64/include/asm/pgtable.h
 index bd5db28..f5ce010 100644
 --- a/arch/arm64/include/asm/pgtable.h
 +++ b/arch/arm64/include/asm/pgtable.h
 @@ -40,7 +40,7 @@
   *   fixed mappings and modules
   */
  #define VMEMMAP_SIZE ALIGN((1UL  (VA_BITS - PAGE_SHIFT)) * 
 sizeof(struct page), PUD_SIZE)
 -#define VMALLOC_START(UL(0x)  VA_BITS)
 +#define VMALLOC_START((UL(0x)  VA_BITS) + 
 (UL(1)  (VA_BITS - 3)))

I assume that's where you want to make room for KASan? Some comments and
macros would be useful for why this is needed and how it is calculated.
It also needs to be disabled when KASan is not enabled.

 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
 index 51c9811..1a99e95 100644
 --- a/arch/arm64/kernel/head.S
 +++ b/arch/arm64/kernel/head.S
 @@ -482,6 +482,9 @@ __mmap_switched:
   str_l   x21, __fdt_pointer, x5  // Save FDT pointer
   str_l   x24, memstart_addr, x6  // Save PHYS_OFFSET
   mov x29, #0
 +#ifdef CONFIG_KASAN
 + b kasan_early_init
 +#endif

Nitpick: tab between b and kasan_early_init.

 diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
 new file mode 100644
 index 000..df537da
 --- /dev/null
 +++ b/arch/arm64/mm/kasan_init.c
 @@ -0,0 +1,211 @@
 +#include linux/kasan.h
 +#include linux/kernel.h
 +#include linux/memblock.h
 +#include linux/start_kernel.h
 +
 +#include asm/page.h
 +#include asm/pgtable.h
 +#include asm/tlbflush.h
 +
 +static char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;

Can we not use the system's zero_page or it's not initialised yet?

 +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
 +
 +#if CONFIG_PGTABLE_LEVELS  3
 +static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
 +#endif
 +#if CONFIG_PGTABLE_LEVELS  2
 +static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
 +#endif
 +static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
 +
 +static void __init init_kasan_page_tables(void)
 +{
 + int i;
 +
 +#if CONFIG_PGTABLE_LEVELS  3
 + for (i = 0; i  PTRS_PER_PUD; i++)
 + set_pud(kasan_zero_pud[i], __pud(__pa(kasan_zero_pmd)
 + | PAGE_KERNEL));
 +#endif
 +#if CONFIG_PGTABLE_LEVELS  2
 + for (i = 0; i  PTRS_PER_PMD; i++)
 + set_pmd(kasan_zero_pmd[i], __pmd(__pa(kasan_zero_pte)
 + | PAGE_KERNEL));
 +#endif

These don't look right. You are setting page attributes on table
entries. You should use the standard pmd_populate etc. macros here, see
early_fixmap_init() as an example.

 + for (i = 0; i  PTRS_PER_PTE; i++)
 + set_pte(kasan_zero_pte[i], __pte(__pa(kasan_zero_page)
 + | PAGE_KERNEL));

PAGE_KERNEL is pgprot_t, so you mix the types here. Just do something
like:

set_pte(..., pfn_pte(zero_pfn, PAGE_KERNEL_RO));

(shouldn't it be read-only?)

 +void __init kasan_map_early_shadow(pgd_t *pgdp)
 +{
 + int i;
 + unsigned long start = KASAN_SHADOW_START;
 + unsigned long end = KASAN_SHADOW_END;
 + pgd_t pgd;
 +
 +#if CONFIG_PGTABLE_LEVELS  3
 + pgd = __pgd(__pa(kasan_zero_pud) | PAGE_KERNEL);
 +#elif CONFIG_PGTABLE_LEVELS  2
 + pgd = __pgd(__pa(kasan_zero_pmd) | PAGE_KERNEL);
 +#else
 + pgd = __pgd(__pa(kasan_zero_pte) | PAGE_KERNEL);
 +#endif
 +
 + for (i = pgd_index(start); start  end; i++) {
 + set_pgd(pgdp[i], pgd);
 + start += PGDIR_SIZE;
 + }
 +}

Same problem as above with PAGE_KERNEL. You should just use
pgd_populate().

 +
 +void __init kasan_early_init(void)
 +{
 + init_kasan_page_tables();
 +

[PATCH 2/2] arm64: add KASan support

2015-03-24 Thread Andrey Ryabinin 
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from vmalloc area.

At early boot stage the whole shadow region populated with just
one physical page (kasan_zero_page). Later, this page reused
as readonly zero shadow for some memory that KASan currently
don't track (vmalloc).
After mapping the physical memory, pages for shadow memory are
allocated and mapped.

KASan's stack instrumentation significantly increases stack's
consumption, so CONFIG_KASAN doubles THREAD_SIZE.

Functions like memset/memmove/memcpy do a lot of memory accesses.
If bad pointer passed to one of these function it is important
to catch this. Compiler's instrumentation cannot do this since
these functions are written in assembly.
KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions
in mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in name, so we could call non-instrumented variant
if needed.
Some files built without kasan instrumentation (e.g. mm/slub.c).
Original mem* function replaced (via #define) with prefixed variants
to disable memory access checks for such files.

Signed-off-by: Andrey Ryabinin 
---
 arch/arm64/Kconfig   |   7 ++
 arch/arm64/include/asm/pgtable.h |   3 +-
 arch/arm64/include/asm/string.h  |  16 +++
 arch/arm64/include/asm/thread_info.h |   8 ++
 arch/arm64/kernel/head.S |   3 +
 arch/arm64/kernel/module.c   |  16 ++-
 arch/arm64/kernel/setup.c|   2 +
 arch/arm64/lib/memcpy.S  |   3 +
 arch/arm64/lib/memmove.S |   7 +-
 arch/arm64/lib/memset.S  |   3 +
 arch/arm64/mm/Makefile   |   3 +
 arch/arm64/mm/kasan_init.c   | 211 +++
 12 files changed, 276 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm64/mm/kasan_init.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4085df1..10bbd71 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -41,6 +41,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_JUMP_LABEL
+   select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
@@ -116,6 +117,12 @@ config GENERIC_CSUM
 config GENERIC_CALIBRATE_DELAY
def_bool y
 
+config KASAN_SHADOW_OFFSET
+   hex
+   default 0xdfff2000 if ARM64_VA_BITS_48
+   default 0xdc80 if ARM64_VA_BITS_42
+   default 0xdf90 if ARM64_VA_BITS_39
+
 config ZONE_DMA
def_bool y
 
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index bd5db28..f5ce010 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -40,7 +40,7 @@
  * fixed mappings and modules
  */
 #define VMEMMAP_SIZE   ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * 
sizeof(struct page), PUD_SIZE)
-#define VMALLOC_START  (UL(0x) << VA_BITS)
+#define VMALLOC_START  ((UL(0x) << VA_BITS) + (UL(1) 
<< (VA_BITS - 3)))
 #define VMALLOC_END(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
 #define vmemmap((struct page *)(VMALLOC_END + SZ_64K))
@@ -73,6 +73,7 @@ extern void __pgd_error(const char *file, int line, unsigned 
long val);
 
 #define PAGE_KERNEL__pgprot(_PAGE_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY | PTE_WRITE)
 #define PAGE_KERNEL_EXEC   __pgprot(_PAGE_DEFAULT | PTE_UXN | PTE_DIRTY | 
PTE_WRITE)
+#define PAGE_KERNEL_RO __pgprot(_PAGE_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY)
 
 #define PAGE_HYP   __pgprot(_PAGE_DEFAULT | PTE_HYP)
 #define PAGE_HYP_DEVICE__pgprot(PROT_DEVICE_nGnRE | PTE_HYP)
diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
index 64d2d48..bff522c 100644
--- a/arch/arm64/include/asm/string.h
+++ b/arch/arm64/include/asm/string.h
@@ -36,17 +36,33 @@ extern __kernel_size_t strnlen(const char *, 
__kernel_size_t);
 
 #define __HAVE_ARCH_MEMCPY
 extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMMOVE
 extern void *memmove(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMCHR
 extern void *memchr(const void *, int, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMSET
 extern void *memset(void *, int, __kernel_size_t);
+extern void *__memset(void *, int, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMCMP
 extern int memcmp(const void *, const void *, size_t);
 
+
+#if defined(CONFIG_KASAN) &&

[PATCH 2/2] arm64: add KASan support

2015-03-24 Thread Andrey Ryabinin 
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from vmalloc area.

At early boot stage the whole shadow region populated with just
one physical page (kasan_zero_page). Later, this page reused
as readonly zero shadow for some memory that KASan currently
don't track (vmalloc).
After mapping the physical memory, pages for shadow memory are
allocated and mapped.

KASan's stack instrumentation significantly increases stack's
consumption, so CONFIG_KASAN doubles THREAD_SIZE.

Functions like memset/memmove/memcpy do a lot of memory accesses.
If bad pointer passed to one of these function it is important
to catch this. Compiler's instrumentation cannot do this since
these functions are written in assembly.
KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions
in mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in name, so we could call non-instrumented variant
if needed.
Some files built without kasan instrumentation (e.g. mm/slub.c).
Original mem* function replaced (via #define) with prefixed variants
to disable memory access checks for such files.

Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com
---
 arch/arm64/Kconfig   |   7 ++
 arch/arm64/include/asm/pgtable.h |   3 +-
 arch/arm64/include/asm/string.h  |  16 +++
 arch/arm64/include/asm/thread_info.h |   8 ++
 arch/arm64/kernel/head.S |   3 +
 arch/arm64/kernel/module.c   |  16 ++-
 arch/arm64/kernel/setup.c|   2 +
 arch/arm64/lib/memcpy.S  |   3 +
 arch/arm64/lib/memmove.S |   7 +-
 arch/arm64/lib/memset.S  |   3 +
 arch/arm64/mm/Makefile   |   3 +
 arch/arm64/mm/kasan_init.c   | 211 +++
 12 files changed, 276 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm64/mm/kasan_init.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4085df1..10bbd71 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -41,6 +41,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_JUMP_LABEL
+   select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
@@ -116,6 +117,12 @@ config GENERIC_CSUM
 config GENERIC_CALIBRATE_DELAY
def_bool y
 
+config KASAN_SHADOW_OFFSET
+   hex
+   default 0xdfff2000 if ARM64_VA_BITS_48
+   default 0xdc80 if ARM64_VA_BITS_42
+   default 0xdf90 if ARM64_VA_BITS_39
+
 config ZONE_DMA
def_bool y
 
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index bd5db28..f5ce010 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -40,7 +40,7 @@
  * fixed mappings and modules
  */
 #define VMEMMAP_SIZE   ALIGN((1UL  (VA_BITS - PAGE_SHIFT)) * 
sizeof(struct page), PUD_SIZE)
-#define VMALLOC_START  (UL(0x)  VA_BITS)
+#define VMALLOC_START  ((UL(0x)  VA_BITS) + (UL(1) 
 (VA_BITS - 3)))
 #define VMALLOC_END(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
 #define vmemmap((struct page *)(VMALLOC_END + SZ_64K))
@@ -73,6 +73,7 @@ extern void __pgd_error(const char *file, int line, unsigned 
long val);
 
 #define PAGE_KERNEL__pgprot(_PAGE_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY | PTE_WRITE)
 #define PAGE_KERNEL_EXEC   __pgprot(_PAGE_DEFAULT | PTE_UXN | PTE_DIRTY | 
PTE_WRITE)
+#define PAGE_KERNEL_RO __pgprot(_PAGE_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_DIRTY)
 
 #define PAGE_HYP   __pgprot(_PAGE_DEFAULT | PTE_HYP)
 #define PAGE_HYP_DEVICE__pgprot(PROT_DEVICE_nGnRE | PTE_HYP)
diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
index 64d2d48..bff522c 100644
--- a/arch/arm64/include/asm/string.h
+++ b/arch/arm64/include/asm/string.h
@@ -36,17 +36,33 @@ extern __kernel_size_t strnlen(const char *, 
__kernel_size_t);
 
 #define __HAVE_ARCH_MEMCPY
 extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMMOVE
 extern void *memmove(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMCHR
 extern void *memchr(const void *, int, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMSET
 extern void *memset(void *, int, __kernel_size_t);
+extern void *__memset(void *, int, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMCMP
 extern int memcmp(const void *, const void *, size_t);
 
+
+#if defined(CONFIG_KASAN)