[PATCH 00/11] KASan for arm

[PATCH 00/11] KASan for arm

[Abbott Liu]

Hi,all:
   These patches add 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 user space.
   
   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. 

  On arm LPAE architecture,  the mapping table of KASan shadow memory(if 
PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is 
0xb6e000000~0xbf000000) can't be filled in do_translation_fault function, 
because kasan instrumentation maybe cause do_translation_fault function 
accessing KASan shadow memory. The accessing of KASan shadow memory in 
do_translation_fault function maybe cause dead circle. So the mapping table 
of KASan shadow memory need be copyed in pgd_alloc function.


Most of the code comes from:
https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.

These patches are tested on vexpress-ca15, vexpress-ca9

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Tested-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>

Abbott Liu (6):
  Define the virtual space of KASan's shadow region
  change memory_is_poisoned_16 for aligned error
  Add support arm LPAE
  Don't need to map the shadow of KASan's shadow memory
  Change mapping of kasan_zero_page int readonly
  Add KASan layout

Andrey Ryabinin (5):
  Initialize the mapping of KASan shadow memory
  replace memory function
  arm: Kconfig: enable KASan
  Disable kasan's instrumentation
  Avoid cleaning the KASan shadow area's mapping table

 arch/arm/Kconfig                   |   1 +
 arch/arm/boot/compressed/Makefile  |   1 +
 arch/arm/include/asm/kasan.h       |  20 +++
 arch/arm/include/asm/kasan_def.h   |  51 +++++++
 arch/arm/include/asm/memory.h      |   5 +
 arch/arm/include/asm/pgalloc.h     |   5 +-
 arch/arm/include/asm/pgtable.h     |   1 +
 arch/arm/include/asm/proc-fns.h    |  33 +++++
 arch/arm/include/asm/string.h      |  18 ++-
 arch/arm/include/asm/thread_info.h |   4 +
 arch/arm/kernel/entry-armv.S       |   7 +-
 arch/arm/kernel/head-common.S      |   4 +
 arch/arm/kernel/setup.c            |   2 +
 arch/arm/kernel/unwind.c           |   3 +-
 arch/arm/lib/memcpy.S              |   3 +
 arch/arm/lib/memmove.S             |   5 +-
 arch/arm/lib/memset.S              |   3 +
 arch/arm/mm/Makefile               |   5 +
 arch/arm/mm/init.c                 |   6 +
 arch/arm/mm/kasan_init.c           | 265 +++++++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c                  |   7 +-
 arch/arm/mm/pgd.c                  |  12 ++
 arch/arm/vdso/Makefile             |   2 +
 mm/kasan/kasan.c                   |  22 ++-
 24 files changed, 478 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/kasan.h
 create mode 100644 arch/arm/include/asm/kasan_def.h
 create mode 100644 arch/arm/mm/kasan_init.c

-- 
2.9.0

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Abbott Liu]

From: Andrey Ryabinin <a.ryabinin@samsung.com>

This patch initializes KASan shadow region's page table and memory.
There are two stage for KASan initializing:
1. At early boot stage the whole shadow region is mapped to just
   one physical page (kasan_zero_page). It's finished by the function
   kasan_early_init which is called by __mmap_switched(arch/arm/kernel/
   head-common.S)

2. After the calling of paging_init, we use kasan_zero_page as zero
   shadow for some memory that KASan don't need to track, and we alloc
   new shadow space for the other memory that KASan need to track. These
   issues are finished by the function kasan_init which is call by setup_arch.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 arch/arm/include/asm/kasan.h       |  20 +++
 arch/arm/include/asm/pgalloc.h     |   5 +-
 arch/arm/include/asm/pgtable.h     |   1 +
 arch/arm/include/asm/proc-fns.h    |  33 +++++
 arch/arm/include/asm/thread_info.h |   4 +
 arch/arm/kernel/head-common.S      |   4 +
 arch/arm/kernel/setup.c            |   2 +
 arch/arm/mm/Makefile               |   5 +
 arch/arm/mm/kasan_init.c           | 257 +++++++++++++++++++++++++++++++++++++
 mm/kasan/kasan.c                   |   2 +-
 10 files changed, 331 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/kasan.h
 create mode 100644 arch/arm/mm/kasan_init.c

diff --git a/arch/arm/include/asm/kasan.h b/arch/arm/include/asm/kasan.h
new file mode 100644
index 0000000..90ee60c
--- /dev/null
+++ b/arch/arm/include/asm/kasan.h
@@ -0,0 +1,20 @@
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifdef CONFIG_KASAN
+
+#include <asm/kasan_def.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)
+ */
+
+extern void kasan_init(void);
+
+#else
+static inline void kasan_init(void) { }
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index b2902a5..10cee6a 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -50,8 +50,11 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
  */
 #define pmd_alloc_one(mm,addr)		({ BUG(); ((pmd_t *)2); })
 #define pmd_free(mm, pmd)		do { } while (0)
+#ifndef CONFIG_KASAN
 #define pud_populate(mm,pmd,pte)	BUG()
-
+#else
+#define pud_populate(mm,pmd,pte)	do { } while (0)
+#endif
 #endif	/* CONFIG_ARM_LPAE */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 1c46238..fdf343f 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -97,6 +97,7 @@ extern pgprot_t		pgprot_s2_device;
 #define PAGE_READONLY		_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY | L_PTE_XN)
 #define PAGE_READONLY_EXEC	_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY)
 #define PAGE_KERNEL		_MOD_PROT(pgprot_kernel, L_PTE_XN)
+#define PAGE_KERNEL_RO		_MOD_PROT(pgprot_kernel, L_PTE_XN | L_PTE_RDONLY)
 #define PAGE_KERNEL_EXEC	pgprot_kernel
 #define PAGE_HYP		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_XN)
 #define PAGE_HYP_EXEC		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_RDONLY)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index f2e1af4..6e26714 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -131,6 +131,15 @@ extern void cpu_resume(void);
 		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
 		(pgd_t *)phys_to_virt(pg);		\
 	})
+
+#define cpu_set_ttbr0(val)					\
+	do {							\
+		u64 ttbr = val;					\
+		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
+			: : "r" (ttbr));	\
+	} while (0)
+
+
 #else
 #define cpu_get_pgd()	\
 	({						\
@@ -140,6 +149,30 @@ extern void cpu_resume(void);
 		pg &= ~0x3fff;				\
 		(pgd_t *)phys_to_virt(pg);		\
 	})
+
+#define cpu_set_ttbr(nr, val)					\
+	do {							\
+		u64 ttbr = val;					\
+		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
+			: : "r" (ttbr));			\
+	} while (0)
+
+#define cpu_get_ttbr(nr)					\
+	({							\
+		unsigned long ttbr;				\
+		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
+			: "=r" (ttbr));				\
+		ttbr;						\
+	})
+
+#define cpu_set_ttbr0(val)					\
+	do {							\
+		u64 ttbr = val;					\
+		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
+			: : "r" (ttbr));			\
+	} while (0)
+
+
 #endif
 
 #else	/*!CONFIG_MMU */
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 1d468b5..52c4858 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -16,7 +16,11 @@
 #include <asm/fpstate.h>
 #include <asm/page.h>
 
+#ifdef CONFIG_KASAN
+#define THREAD_SIZE_ORDER       2
+#else
 #define THREAD_SIZE_ORDER	1
+#endif
 #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
 #define THREAD_START_SP		(THREAD_SIZE - 8)
 
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 8733012..c17f4a2 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -101,7 +101,11 @@ __mmap_switched:
 	str	r2, [r6]			@ Save atags pointer
 	cmp	r7, #0
 	strne	r0, [r7]			@ Save control register values
+#ifdef CONFIG_KASAN
+	b	kasan_early_init
+#else
 	b	start_kernel
+#endif
 ENDPROC(__mmap_switched)
 
 	.align	2
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8e9a3e4..985d9a3 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -62,6 +62,7 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/kasan.h>
 
 #include "atags.h"
 
@@ -1108,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
 	early_ioremap_reset();
 
 	paging_init(mdesc);
+	kasan_init();
 	request_standard_resources(mdesc);
 
 	if (mdesc->restart)
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 950d19b..498c316 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -106,4 +106,9 @@ obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o l2c-l2x0-resume.o
 obj-$(CONFIG_CACHE_L2X0_PMU)	+= cache-l2x0-pmu.o
 obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
 obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
+
+KASAN_SANITIZE_kasan_init.o    := n
+obj-$(CONFIG_KASAN)            += kasan_init.o
+
+
 obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
new file mode 100644
index 0000000..2bf0782
--- /dev/null
+++ b/arch/arm/mm/kasan_init.c
@@ -0,0 +1,257 @@
+#include <linux/bootmem.h>
+#include <linux/kasan.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/start_kernel.h>
+
+#include <asm/cputype.h>
+#include <asm/highmem.h>
+#include <asm/mach/map.h>
+#include <asm/memory.h>
+#include <asm/page.h>
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/procinfo.h>
+#include <asm/proc-fns.h>
+#include <asm/tlbflush.h>
+#include <asm/cp15.h>
+#include <linux/sched/task.h>
+
+#include "mm.h"
+
+static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(1ULL << 14);
+
+pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
+
+static __init void *kasan_alloc_block(size_t size, int node)
+{
+	return memblock_virt_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
+					BOOTMEM_ALLOC_ACCESSIBLE, node);
+}
+
+static void __init kasan_early_pmd_populate(unsigned long start, unsigned long end, pud_t *pud)
+{
+	unsigned long addr;
+	unsigned long next;
+	pmd_t *pmd;
+
+	pmd = pmd_offset(pud, start);
+	for (addr = start; addr < end;) {
+		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
+		next = pmd_addr_end(addr, end);
+		addr = next;
+		flush_pmd_entry(pmd);
+		pmd++;
+	}
+}
+
+static void __init kasan_early_pud_populate(unsigned long start, unsigned long end, pgd_t *pgd)
+{
+	unsigned long addr;
+	unsigned long next;
+	pud_t *pud;
+
+	pud = pud_offset(pgd, start);
+	for (addr = start; addr < end;) {
+		next = pud_addr_end(addr, end);
+		kasan_early_pmd_populate(addr, next, pud);
+		addr = next;
+		pud++;
+	}
+}
+
+void __init kasan_map_early_shadow(pgd_t *pgdp)
+{
+	int i;
+	unsigned long start = KASAN_SHADOW_START;
+	unsigned long end = KASAN_SHADOW_END;
+	unsigned long addr;
+	unsigned long next;
+	pgd_t *pgd;
+
+	for (i = 0; i < PTRS_PER_PTE; i++)
+		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
+			&kasan_zero_pte[i], pfn_pte(
+				virt_to_pfn(kasan_zero_page),
+				__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN)));
+
+	pgd = pgd_offset_k(start);
+	for (addr = start; addr < end;) {
+		next = pgd_addr_end(addr, end);
+		kasan_early_pud_populate(addr, next, pgd);
+		addr = next;
+		pgd++;
+	}
+}
+
+extern struct proc_info_list *lookup_processor_type(unsigned int);
+
+void __init kasan_early_init(void)
+{
+	struct proc_info_list *list;
+
+	/*
+	 * locate processor in the list of supported processor
+	 * types.  The linker builds this table for us from the
+	 * entries in arch/arm/mm/proc-*.S
+	 */
+	list = lookup_processor_type(read_cpuid_id());
+	if (list) {
+#ifdef MULTI_CPU
+		processor = *list->proc;
+#endif
+	}
+
+	BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END - (1UL << 29));
+
+
+	kasan_map_early_shadow(swapper_pg_dir);
+	start_kernel();
+}
+
+static void __init clear_pgds(unsigned long start,
+			unsigned long end)
+{
+	for (; start && start < end; start += PMD_SIZE)
+		pmd_clear(pmd_off_k(start));
+}
+
+pte_t * __meminit kasan_pte_populate(pmd_t *pmd, unsigned long addr, int node)
+{
+	pte_t *pte = pte_offset_kernel(pmd, addr);
+	if (pte_none(*pte)) {
+		pte_t entry;
+		void *p = kasan_alloc_block(PAGE_SIZE, node);
+		if (!p)
+			return NULL;
+		entry = pfn_pte(virt_to_pfn(p), __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
+		set_pte_at(&init_mm, addr, pte, entry);
+	}
+	return pte;
+}
+
+pmd_t * __meminit kasan_pmd_populate(pud_t *pud, unsigned long addr, int node)
+{
+	pmd_t *pmd = pmd_offset(pud, addr);
+	if (pmd_none(*pmd)) {
+		void *p = kasan_alloc_block(PAGE_SIZE, node);
+		if (!p)
+			return NULL;
+		pmd_populate_kernel(&init_mm, pmd, p);
+	}
+	return pmd;
+}
+
+pud_t * __meminit kasan_pud_populate(pgd_t *pgd, unsigned long addr, int node)
+{
+	pud_t *pud = pud_offset(pgd, addr);
+	if (pud_none(*pud)) {
+		void *p = kasan_alloc_block(PAGE_SIZE, node);
+		if (!p)
+			return NULL;
+		pr_err("populating pud addr %lx\n", addr);
+		pud_populate(&init_mm, pud, p);
+	}
+	return pud;
+}
+
+pgd_t * __meminit kasan_pgd_populate(unsigned long addr, int node)
+{
+	pgd_t *pgd = pgd_offset_k(addr);
+	if (pgd_none(*pgd)) {
+		void *p = kasan_alloc_block(PAGE_SIZE, node);
+		if (!p)
+			return NULL;
+		pgd_populate(&init_mm, pgd, p);
+	}
+	return pgd;
+}
+
+static int __init create_mapping(unsigned long start, unsigned long end, int node)
+{
+	unsigned long addr = start;
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+	pte_t *pte;
+	pr_info("populating shadow for %lx, %lx\n", start, end);
+	for (; addr < end; addr += PAGE_SIZE) {
+		pgd = kasan_pgd_populate(addr, node);
+		if (!pgd)
+			return -ENOMEM;
+
+		pud = kasan_pud_populate(pgd, addr, node);
+		if (!pud)
+			return -ENOMEM;
+
+		pmd = kasan_pmd_populate(pud, addr, node);
+		if (!pmd)
+			return -ENOMEM;
+
+		pte = kasan_pte_populate(pmd, addr, node);
+		if (!pte)
+			return -ENOMEM;
+	}
+	return 0;
+}
+
+
+void __init kasan_init(void)
+{
+	struct memblock_region *reg;
+	u64 orig_ttbr0;
+
+	orig_ttbr0 = cpu_get_ttbr(0);
+
+#ifdef CONFIG_ARM_LPAE
+	memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
+	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
+	set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
+	cpu_set_ttbr0(__pa(tmp_page_table));
+#else
+	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
+	cpu_set_ttbr0(__pa(tmp_page_table));
+#endif
+	flush_cache_all();
+	local_flush_bp_all();
+	local_flush_tlb_all();
+
+	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
+
+	kasan_populate_zero_shadow(
+		kasan_mem_to_shadow((void *)KASAN_SHADOW_START),
+		kasan_mem_to_shadow((void *)KASAN_SHADOW_END));
+
+	kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
+				kasan_mem_to_shadow((void *)-1UL) + 1);
+
+	for_each_memblock(memory, reg) {
+		void *start = __va(reg->base);
+		void *end = __va(reg->base + reg->size);
+
+		if (reg->base + reg->size > arm_lowmem_limit)
+			end = __va(arm_lowmem_limit);
+		if (start >= end)
+			break;
+
+		create_mapping((unsigned long)kasan_mem_to_shadow(start),
+			(unsigned long)kasan_mem_to_shadow(end),
+			NUMA_NO_NODE);
+	}
+
+	/*1.the module's global variable is in MODULES_VADDR ~ MODULES_END,so we need mapping.
+	  *2.PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR ~ MODULES_END's shadow
+	  *  is in the same PMD_SIZE, so we cant use kasan_populate_zero_shadow.
+	  *
+	  **/
+	create_mapping((unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR),
+		(unsigned long)kasan_mem_to_shadow((void *)(PKMAP_BASE+PMD_SIZE)),
+		NUMA_NO_NODE);
+	cpu_set_ttbr0(orig_ttbr0);
+	flush_cache_all();
+	local_flush_bp_all();
+	local_flush_tlb_all();
+	memset(kasan_zero_page, 0, PAGE_SIZE);
+	pr_info("Kernel address sanitizer initialized\n");
+	init_task.kasan_depth = 0;
+}
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 6f319fb..12749da 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -358,7 +358,7 @@ void kasan_cache_create(struct kmem_cache *cache, size_t *size,
 	if (redzone_adjust > 0)
 		*size += redzone_adjust;
 
-	*size = min(KMALLOC_MAX_SIZE, max(*size, cache->object_size +
+	*size = min((size_t)KMALLOC_MAX_SIZE, max(*size, cache->object_size +
 					optimal_redzone(cache->object_size)));
 
 	/*
-- 
2.9.0

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Florian Fainelli]

On 10/11/2017 01:22 AM, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
> This patch initializes KASan shadow region's page table and memory.
> There are two stage for KASan initializing:
> 1. At early boot stage the whole shadow region is mapped to just
>    one physical page (kasan_zero_page). It's finished by the function
>    kasan_early_init which is called by __mmap_switched(arch/arm/kernel/
>    head-common.S)
> 
> 2. After the calling of paging_init, we use kasan_zero_page as zero
>    shadow for some memory that KASan don't need to track, and we alloc
>    new shadow space for the other memory that KASan need to track. These
>    issues are finished by the function kasan_init which is call by setup_arch.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
> ---

[snip]

				\
> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>  		pg &= ~0x3fff;				\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr(nr, val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)

nr seems to be unused here?

> +
> +#define cpu_get_ttbr(nr)					\
> +	({							\
> +		unsigned long ttbr;				\
> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
> +			: "=r" (ttbr));				\
> +		ttbr;						\
> +	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +

Why is not cpu_set_ttbr0() not using cpu_set_ttbr()?

> +
>  #endif
>  
>  #else	/*!CONFIG_MMU */
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 1d468b5..52c4858 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -16,7 +16,11 @@
>  #include <asm/fpstate.h>
>  #include <asm/page.h>
>  
> +#ifdef CONFIG_KASAN
> +#define THREAD_SIZE_ORDER       2
> +#else
>  #define THREAD_SIZE_ORDER	1
> +#endif
>  #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
>  #define THREAD_START_SP		(THREAD_SIZE - 8)
>  
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 8733012..c17f4a2 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -101,7 +101,11 @@ __mmap_switched:
>  	str	r2, [r6]			@ Save atags pointer
>  	cmp	r7, #0
>  	strne	r0, [r7]			@ Save control register values
> +#ifdef CONFIG_KASAN
> +	b	kasan_early_init
> +#else
>  	b	start_kernel
> +#endif

Please don't make this "exclusive" just conditionally call
kasan_early_init(), remove the call to start_kernel from
kasan_early_init and keep the call to start_kernel here.

>  ENDPROC(__mmap_switched)
>  
>  	.align	2

[snip]

> +void __init kasan_early_init(void)
> +{
> +	struct proc_info_list *list;
> +
> +	/*
> +	 * locate processor in the list of supported processor
> +	 * types.  The linker builds this table for us from the
> +	 * entries in arch/arm/mm/proc-*.S
> +	 */
> +	list = lookup_processor_type(read_cpuid_id());
> +	if (list) {
> +#ifdef MULTI_CPU
> +		processor = *list->proc;
> +#endif
> +	}

I could not quite spot in your patch series when do you need this
information?
-- 
Florian

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 12:39:39PM -0700, Florian Fainelli wrote:
> On 10/11/2017 01:22 AM, Abbott Liu wrote:
> > diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> > index 8733012..c17f4a2 100644
> > --- a/arch/arm/kernel/head-common.S
> > +++ b/arch/arm/kernel/head-common.S
> > @@ -101,7 +101,11 @@ __mmap_switched:
> >  	str	r2, [r6]			@ Save atags pointer
> >  	cmp	r7, #0
> >  	strne	r0, [r7]			@ Save control register values
> > +#ifdef CONFIG_KASAN
> > +	b	kasan_early_init
> > +#else
> >  	b	start_kernel
> > +#endif
> 
> Please don't make this "exclusive" just conditionally call
> kasan_early_init(), remove the call to start_kernel from
> kasan_early_init and keep the call to start_kernel here.

iow:

#ifdef CONFIG_KASAN
	bl	kasan_early_init
#endif
	b	start_kernel

This has the advantage that we don't leave any stack frame from
kasan_early_init() on the init task stack.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Lamb)]

2017.10.12  05:42 AM  Russell King - ARM Linux [mailto:linux at armlinux.org.uk] wrote:

>> Please don't make this "exclusive" just conditionally call 
>> kasan_early_init(), remove the call to start_kernel from 
>> kasan_early_init and keep the call to start_kernel here.
>iow:
>
>#ifdef CONFIG_KASAN
>	bl	kasan_early_init
>#endif
>	b	start_kernel
>
>This has the advantage that we don't leave any stack frame from
>kasan_early_init() on the init task stack.

Thanks for your review.  I tested your opinion and it work well.
I agree with you that it is better to use follow code
#ifdef CONFIG_KASAN
	bl	kasan_early_init
#endif
	b	start_kernel

than :
#ifdef CONFIG_KASAN
	bl	kasan_early_init
#else
	b	start_kernel
#endif

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Dmitry Osipenko]

On 11.10.2017 11:22, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
> This patch initializes KASan shadow region's page table and memory.
> There are two stage for KASan initializing:
> 1. At early boot stage the whole shadow region is mapped to just
>    one physical page (kasan_zero_page). It's finished by the function
>    kasan_early_init which is called by __mmap_switched(arch/arm/kernel/
>    head-common.S)
> 
> 2. After the calling of paging_init, we use kasan_zero_page as zero
>    shadow for some memory that KASan don't need to track, and we alloc
>    new shadow space for the other memory that KASan need to track. These
>    issues are finished by the function kasan_init which is call by setup_arch.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
> ---
>  arch/arm/include/asm/kasan.h       |  20 +++
>  arch/arm/include/asm/pgalloc.h     |   5 +-
>  arch/arm/include/asm/pgtable.h     |   1 +
>  arch/arm/include/asm/proc-fns.h    |  33 +++++
>  arch/arm/include/asm/thread_info.h |   4 +
>  arch/arm/kernel/head-common.S      |   4 +
>  arch/arm/kernel/setup.c            |   2 +
>  arch/arm/mm/Makefile               |   5 +
>  arch/arm/mm/kasan_init.c           | 257 +++++++++++++++++++++++++++++++++++++
>  mm/kasan/kasan.c                   |   2 +-
>  10 files changed, 331 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/kasan.h
>  create mode 100644 arch/arm/mm/kasan_init.c
> 
> diff --git a/arch/arm/include/asm/kasan.h b/arch/arm/include/asm/kasan.h
> new file mode 100644
> index 0000000..90ee60c
> --- /dev/null
> +++ b/arch/arm/include/asm/kasan.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASM_KASAN_H
> +#define __ASM_KASAN_H
> +
> +#ifdef CONFIG_KASAN
> +
> +#include <asm/kasan_def.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)
> + */
> +
> +extern void kasan_init(void);
> +
> +#else
> +static inline void kasan_init(void) { }
> +#endif
> +
> +#endif
> diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
> index b2902a5..10cee6a 100644
> --- a/arch/arm/include/asm/pgalloc.h
> +++ b/arch/arm/include/asm/pgalloc.h
> @@ -50,8 +50,11 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
>   */
>  #define pmd_alloc_one(mm,addr)		({ BUG(); ((pmd_t *)2); })
>  #define pmd_free(mm, pmd)		do { } while (0)
> +#ifndef CONFIG_KASAN
>  #define pud_populate(mm,pmd,pte)	BUG()
> -
> +#else
> +#define pud_populate(mm,pmd,pte)	do { } while (0)
> +#endif
>  #endif	/* CONFIG_ARM_LPAE */
>  
>  extern pgd_t *pgd_alloc(struct mm_struct *mm);
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index 1c46238..fdf343f 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -97,6 +97,7 @@ extern pgprot_t		pgprot_s2_device;
>  #define PAGE_READONLY		_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY | L_PTE_XN)
>  #define PAGE_READONLY_EXEC	_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY)
>  #define PAGE_KERNEL		_MOD_PROT(pgprot_kernel, L_PTE_XN)
> +#define PAGE_KERNEL_RO		_MOD_PROT(pgprot_kernel, L_PTE_XN | L_PTE_RDONLY)
>  #define PAGE_KERNEL_EXEC	pgprot_kernel
>  #define PAGE_HYP		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_XN)
>  #define PAGE_HYP_EXEC		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_RDONLY)
> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> index f2e1af4..6e26714 100644
> --- a/arch/arm/include/asm/proc-fns.h
> +++ b/arch/arm/include/asm/proc-fns.h
> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>  		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
> +			: : "r" (ttbr));	\
> +	} while (0)
> +
> +
>  #else
>  #define cpu_get_pgd()	\
>  	({						\
> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>  		pg &= ~0x3fff;				\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr(nr, val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +#define cpu_get_ttbr(nr)					\
> +	({							\
> +		unsigned long ttbr;				\
> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
> +			: "=r" (ttbr));				\
> +		ttbr;						\
> +	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +
>  #endif
>  
>  #else	/*!CONFIG_MMU */
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 1d468b5..52c4858 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -16,7 +16,11 @@
>  #include <asm/fpstate.h>
>  #include <asm/page.h>
>  
> +#ifdef CONFIG_KASAN
> +#define THREAD_SIZE_ORDER       2
> +#else
>  #define THREAD_SIZE_ORDER	1
> +#endif
>  #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
>  #define THREAD_START_SP		(THREAD_SIZE - 8)
>  
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 8733012..c17f4a2 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -101,7 +101,11 @@ __mmap_switched:
>  	str	r2, [r6]			@ Save atags pointer
>  	cmp	r7, #0
>  	strne	r0, [r7]			@ Save control register values
> +#ifdef CONFIG_KASAN
> +	b	kasan_early_init
> +#else
>  	b	start_kernel
> +#endif
>  ENDPROC(__mmap_switched)
>  
>  	.align	2
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8e9a3e4..985d9a3 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -62,6 +62,7 @@
>  #include <asm/unwind.h>
>  #include <asm/memblock.h>
>  #include <asm/virt.h>
> +#include <asm/kasan.h>
>  
>  #include "atags.h"
>  
> @@ -1108,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
>  	early_ioremap_reset();
>  
>  	paging_init(mdesc);
> +	kasan_init();
>  	request_standard_resources(mdesc);
>  
>  	if (mdesc->restart)
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index 950d19b..498c316 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -106,4 +106,9 @@ obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o l2c-l2x0-resume.o
>  obj-$(CONFIG_CACHE_L2X0_PMU)	+= cache-l2x0-pmu.o
>  obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
>  obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
> +
> +KASAN_SANITIZE_kasan_init.o    := n
> +obj-$(CONFIG_KASAN)            += kasan_init.o
> +
> +
>  obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> new file mode 100644
> index 0000000..2bf0782
> --- /dev/null
> +++ b/arch/arm/mm/kasan_init.c
> @@ -0,0 +1,257 @@
> +#include <linux/bootmem.h>
> +#include <linux/kasan.h>
> +#include <linux/kernel.h>
> +#include <linux/memblock.h>
> +#include <linux/start_kernel.h>
> +
> +#include <asm/cputype.h>
> +#include <asm/highmem.h>
> +#include <asm/mach/map.h>
> +#include <asm/memory.h>
> +#include <asm/page.h>
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +#include <asm/procinfo.h>
> +#include <asm/proc-fns.h>
> +#include <asm/tlbflush.h>
> +#include <asm/cp15.h>
> +#include <linux/sched/task.h>
> +
> +#include "mm.h"
> +
> +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(1ULL << 14);
> +
> +pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
> +
> +static __init void *kasan_alloc_block(size_t size, int node)
> +{
> +	return memblock_virt_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
> +					BOOTMEM_ALLOC_ACCESSIBLE, node);
> +}
> +
> +static void __init kasan_early_pmd_populate(unsigned long start, unsigned long end, pud_t *pud)
> +{
> +	unsigned long addr;
> +	unsigned long next;
> +	pmd_t *pmd;
> +
> +	pmd = pmd_offset(pud, start);
> +	for (addr = start; addr < end;) {
> +		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
> +		next = pmd_addr_end(addr, end);
> +		addr = next;
> +		flush_pmd_entry(pmd);
> +		pmd++;
> +	}
> +}
> +
> +static void __init kasan_early_pud_populate(unsigned long start, unsigned long end, pgd_t *pgd)
> +{
> +	unsigned long addr;
> +	unsigned long next;
> +	pud_t *pud;
> +
> +	pud = pud_offset(pgd, start);
> +	for (addr = start; addr < end;) {
> +		next = pud_addr_end(addr, end);
> +		kasan_early_pmd_populate(addr, next, pud);
> +		addr = next;
> +		pud++;
> +	}
> +}
> +
> +void __init kasan_map_early_shadow(pgd_t *pgdp)
> +{
> +	int i;
> +	unsigned long start = KASAN_SHADOW_START;
> +	unsigned long end = KASAN_SHADOW_END;
> +	unsigned long addr;
> +	unsigned long next;
> +	pgd_t *pgd;
> +
> +	for (i = 0; i < PTRS_PER_PTE; i++)
> +		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
> +			&kasan_zero_pte[i], pfn_pte(
> +				virt_to_pfn(kasan_zero_page),
> +				__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN)));

Shouldn't all __pgprot's contain L_PTE_MT_WRITETHROUGH ?

[...]

-- 
Dmitry

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Lamb)]

On 2017.10.12 7:43AM  Dmitry Osipenko [mailto:digetx at gmail.com] wrote:
>Shouldn't all __pgprot's contain L_PTE_MT_WRITETHROUGH ?
>
>[...]
>
>--
>Dmitry

Thanks for your review. I'm sorry that my replay is so late.

I don't think L_PTE_MT_WRITETHROUGH is need for all arm soc. So I think kasan's
mapping can use PAGE_KERNEL which can be initialized for different arm soc and 
__pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)).

I don't think the mapping table flags in kasan_early_init need be changed because of the follow reason:
1) PAGE_KERNEL can't be used in early_kasan_init because the pgprot_kernel which is used to define 
  PAGE_KERNEL doesn't be initialized. 

2) all of the kasan shadow's mapping table is going to be created again in kasan_init function.


All what I say is: I think only the mapping table flags in kasan_init function need to be changed into PAGE_KERNEL 
or  __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)). 

Here is the code, I has already tested:
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -124,7 +124,7 @@ pte_t * __meminit kasan_pte_populate(pmd_t *pmd, unsigned long addr, int node)
                void *p = kasan_alloc_block(PAGE_SIZE, node);
                if (!p)
                        return NULL;
-           entry = pfn_pte(virt_to_pfn(p), __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
+         entry = pfn_pte(virt_to_pfn(p), __pgprot(pgprot_val(PAGE_KERNEL)));
                set_pte_at(&init_mm, addr, pte, entry);
        }
        return pte;
@@ -253,7 +254,7 @@ void __init kasan_init(void)
                 set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
                         &kasan_zero_pte[i], pfn_pte(
                                 virt_to_pfn(kasan_zero_page),
-                                __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY)));
+                         __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)));
        memset(kasan_zero_page, 0, PAGE_SIZE);
        cpu_set_ttbr0(orig_ttbr0);
        flush_cache_all();

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Thu, Oct 12, 2017 at 02:42:49AM +0300, Dmitry Osipenko wrote:
> On 11.10.2017 11:22, Abbott Liu wrote:
> > +void __init kasan_map_early_shadow(pgd_t *pgdp)
> > +{
> > +	int i;
> > +	unsigned long start = KASAN_SHADOW_START;
> > +	unsigned long end = KASAN_SHADOW_END;
> > +	unsigned long addr;
> > +	unsigned long next;
> > +	pgd_t *pgd;
> > +
> > +	for (i = 0; i < PTRS_PER_PTE; i++)
> > +		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
> > +			&kasan_zero_pte[i], pfn_pte(
> > +				virt_to_pfn(kasan_zero_page),
> > +				__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN)));
> 
> Shouldn't all __pgprot's contain L_PTE_MT_WRITETHROUGH ?

One of the architecture restrictions is that the cache attributes of
all aliases should match (but there is a specific workaround that
permits this, provided that the dis-similar mappings aren't accessed
without certain intervening instructions.)

Why should it be L_PTE_MT_WRITETHROUGH, and not the same cache
attributes as the lowmem mapping?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Oct 19, 2017 at 19:09, Russell King - ARM Linux [mailto:linux at armlinux.org.uk] wrote:
>On Thu, Oct 12, 2017 at 02:42:49AM +0300, Dmitry Osipenko wrote:
>> On 11.10.2017 11:22, Abbott Liu wrote:
>> > +void __init kasan_map_early_shadow(pgd_t *pgdp)
>> > +{
>> > +	int i;
>> > +	unsigned long start = KASAN_SHADOW_START;
>> > +	unsigned long end = KASAN_SHADOW_END;
>> > +	unsigned long addr;
>> > +	unsigned long next;
>> > +	pgd_t *pgd;
>> > +
>> > +	for (i = 0; i < PTRS_PER_PTE; i++)
>> > +		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
>> > +			&kasan_zero_pte[i], pfn_pte(
>> > +				virt_to_pfn(kasan_zero_page),
>> > +				__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN)));
>> 
>> Shouldn't all __pgprot's contain L_PTE_MT_WRITETHROUGH ?
>
>One of the architecture restrictions is that the cache attributes of
>all aliases should match (but there is a specific workaround that
>permits this, provided that the dis-similar mappings aren't accessed
>without certain intervening instructions.)
>
>Why should it be L_PTE_MT_WRITETHROUGH, and not the same cache
>attributes as the lowmem mapping?
>

Here is mapping the kasan shadow which is used at the early stage of kernel start(from start
of start_kernel to paging_init). At this stage we only read the kasan shadows, never write the
kasan shadows which is initialized to be zero. 

We will map the kasan shadows again with flags PAGE_KERNEL:
pte_t * __meminit kasan_pte_populate(pmd_t *pmd, unsigned long addr, int node)
{
	pte_t *pte = pte_offset_kernel(pmd, addr);
	if (pte_none(*pte)) {
		pte_t entry;
		void *p = kasan_alloc_block(PAGE_SIZE, node);
 		if (!p)
			return NULL;
		entry = pfn_pte(virt_to_pfn(p), __pgprot(pgprot_val(PAGE_KERNEL)));
			set_pte_at(&init_mm, addr, pte, entry);
	}
	return pte;
}

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 11/10/17 09:22, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
> This patch initializes KASan shadow region's page table and memory.
> There are two stage for KASan initializing:
> 1. At early boot stage the whole shadow region is mapped to just
>    one physical page (kasan_zero_page). It's finished by the function
>    kasan_early_init which is called by __mmap_switched(arch/arm/kernel/
>    head-common.S)
> 
> 2. After the calling of paging_init, we use kasan_zero_page as zero
>    shadow for some memory that KASan don't need to track, and we alloc
>    new shadow space for the other memory that KASan need to track. These
>    issues are finished by the function kasan_init which is call by setup_arch.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
> ---
>  arch/arm/include/asm/kasan.h       |  20 +++
>  arch/arm/include/asm/pgalloc.h     |   5 +-
>  arch/arm/include/asm/pgtable.h     |   1 +
>  arch/arm/include/asm/proc-fns.h    |  33 +++++
>  arch/arm/include/asm/thread_info.h |   4 +
>  arch/arm/kernel/head-common.S      |   4 +
>  arch/arm/kernel/setup.c            |   2 +
>  arch/arm/mm/Makefile               |   5 +
>  arch/arm/mm/kasan_init.c           | 257 +++++++++++++++++++++++++++++++++++++
>  mm/kasan/kasan.c                   |   2 +-
>  10 files changed, 331 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/include/asm/kasan.h
>  create mode 100644 arch/arm/mm/kasan_init.c
> 
> diff --git a/arch/arm/include/asm/kasan.h b/arch/arm/include/asm/kasan.h
> new file mode 100644
> index 0000000..90ee60c
> --- /dev/null
> +++ b/arch/arm/include/asm/kasan.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASM_KASAN_H
> +#define __ASM_KASAN_H
> +
> +#ifdef CONFIG_KASAN
> +
> +#include <asm/kasan_def.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)
> + */
> +
> +extern void kasan_init(void);
> +
> +#else
> +static inline void kasan_init(void) { }
> +#endif
> +
> +#endif
> diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
> index b2902a5..10cee6a 100644
> --- a/arch/arm/include/asm/pgalloc.h
> +++ b/arch/arm/include/asm/pgalloc.h
> @@ -50,8 +50,11 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
>   */
>  #define pmd_alloc_one(mm,addr)		({ BUG(); ((pmd_t *)2); })
>  #define pmd_free(mm, pmd)		do { } while (0)
> +#ifndef CONFIG_KASAN
>  #define pud_populate(mm,pmd,pte)	BUG()
> -
> +#else
> +#define pud_populate(mm,pmd,pte)	do { } while (0)
> +#endif
>  #endif	/* CONFIG_ARM_LPAE */
>  
>  extern pgd_t *pgd_alloc(struct mm_struct *mm);
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index 1c46238..fdf343f 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -97,6 +97,7 @@ extern pgprot_t		pgprot_s2_device;
>  #define PAGE_READONLY		_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY | L_PTE_XN)
>  #define PAGE_READONLY_EXEC	_MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY)
>  #define PAGE_KERNEL		_MOD_PROT(pgprot_kernel, L_PTE_XN)
> +#define PAGE_KERNEL_RO		_MOD_PROT(pgprot_kernel, L_PTE_XN | L_PTE_RDONLY)
>  #define PAGE_KERNEL_EXEC	pgprot_kernel
>  #define PAGE_HYP		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_XN)
>  #define PAGE_HYP_EXEC		_MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_RDONLY)
> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> index f2e1af4..6e26714 100644
> --- a/arch/arm/include/asm/proc-fns.h
> +++ b/arch/arm/include/asm/proc-fns.h
> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>  		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
> +			: : "r" (ttbr));	\
> +	} while (0)
> +
> +
>  #else
>  #define cpu_get_pgd()	\
>  	({						\
> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>  		pg &= ~0x3fff;				\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr(nr, val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +#define cpu_get_ttbr(nr)					\
> +	({							\
> +		unsigned long ttbr;				\
> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
> +			: "=r" (ttbr));				\
> +		ttbr;						\
> +	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +

You could instead lift and extend the definitions provided in kvm_hyp.h,
and use the read_sysreg/write_sysreg helpers defined in cp15.h.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 12/10/17 15:59, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
> On 11/10/17 09:22, Abbott Liu wrote:
>> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
>> index f2e1af4..6e26714 100644
>> --- a/arch/arm/include/asm/proc-fns.h
>> +++ b/arch/arm/include/asm/proc-fns.h
>> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>>  		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
>>  		(pgd_t *)phys_to_virt(pg);		\
>>  	})
>> +
>> +#define cpu_set_ttbr0(val)					\
>> +	do {							\
>> +		u64 ttbr = val;					\
>> +		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
>> +			: : "r" (ttbr));	\
>> +	} while (0)
>> +
>> +
>>  #else
>>  #define cpu_get_pgd()	\
>>  	({						\
>> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>>  		pg &= ~0x3fff;				\
>>  		(pgd_t *)phys_to_virt(pg);		\
>>  	})
>> +
>> +#define cpu_set_ttbr(nr, val)					\
>> +	do {							\
>> +		u64 ttbr = val;					\
>> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
>> +			: : "r" (ttbr));			\
>> +	} while (0)
>> +
>> +#define cpu_get_ttbr(nr)					\
>> +	({							\
>> +		unsigned long ttbr;				\
>> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
>> +			: "=r" (ttbr));				\
>> +		ttbr;						\
>> +	})
>> +
>> +#define cpu_set_ttbr0(val)					\
>> +	do {							\
>> +		u64 ttbr = val;					\
>> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
>> +			: : "r" (ttbr));			\
>> +	} while (0)
>> +
>> +
>
>You could instead lift and extend the definitions provided in kvm_hyp.h,
>and use the read_sysreg/write_sysreg helpers defined in cp15.h.

Thanks for your review. 
I extend definitions of TTBR0/TTBR1/PAR in kvm_hyp.h when the CONFIG_ARM_LPAE is 
not defined. 
Because cortex A9 don't support virtualization, so use CONFIG_ARM_LPAE to exclude
some functions and macros which are only used in virtualization.

Here is the code which I tested on vexpress_a15 and vexpress_a9:

diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 14b5903..2592608 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -19,12 +19,14 @@
 #define __ARM_KVM_HYP_H__

 #include <linux/compiler.h>
-#include <linux/kvm_host.h>
 #include <asm/cp15.h>
+
+#ifdef CONFIG_ARM_LPAE
+#include <linux/kvm_host.h>
 #include <asm/kvm_mmu.h>
 #include <asm/vfp.h>
-
 #define __hyp_text __section(.hyp.text) notrace
+#endif

 #define __ACCESS_VFP(CRn)                      \
        "mrc", "mcr", __stringify(p10, 7, %0, CRn, cr0, 0), u32
@@ -37,12 +39,18 @@
        __val;                                                  \
 })

+#ifdef CONFIG_ARM_LPAE
 #define TTBR0          __ACCESS_CP15_64(0, c2)
 #define TTBR1          __ACCESS_CP15_64(1, c2)
 #define VTTBR          __ACCESS_CP15_64(6, c2)
 #define PAR            __ACCESS_CP15_64(0, c7)
 #define CNTV_CVAL      __ACCESS_CP15_64(3, c14)
 #define CNTVOFF                __ACCESS_CP15_64(4, c14)
+#else
+#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR          __ACCESS_CP15(c7, 0, c4, 0)
+#endif

 #define MIDR           __ACCESS_CP15(c0, 0, c0, 0)
 #define CSSELR         __ACCESS_CP15(c0, 2, c0, 0)
@@ -98,6 +106,7 @@
 #define cntvoff_el2                    CNTVOFF
 #define cnthctl_el2                    CNTHCTL

+#ifdef CONFIG_ARM_LPAE
 void __timer_save_state(struct kvm_vcpu *vcpu);
 void __timer_restore_state(struct kvm_vcpu *vcpu);

@@ -123,5 +132,6 @@ void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
 asmlinkage int __guest_enter(struct kvm_vcpu *vcpu,
                             struct kvm_cpu_context *host);
 asmlinkage int __hyp_do_panic(const char *, int, u32);
+#endif

 #endif /* __ARM_KVM_HYP_H__ */
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 049ee0a..359a782 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -15,6 +15,7 @@
 #include <asm/proc-fns.h>
 #include <asm/tlbflush.h>
 #include <asm/cp15.h>
+#include <asm/kvm_hyp.h>
 #include <linux/sched/task.h>

 #include "mm.h"
@@ -203,16 +204,16 @@ void __init kasan_init(void)
        u64 orig_ttbr0;
        int i;

-   orig_ttbr0 = cpu_get_ttbr(0);
+ orig_ttbr0 = read_sysreg(TTBR0);

 #ifdef CONFIG_ARM_LPAE
        memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
        set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ write_sysreg(__pa(tmp_page_table), TTBR0);
 #else
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ write_sysreg(__pa(tmp_page_table),TTBR0);
 #endif
        flush_cache_all();
        local_flush_bp_all();
@@ -257,7 +258,7 @@ void __init kasan_init(void)
                                 /*__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY))*/
                                __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)));
        memset(kasan_zero_page, 0, PAGE_SIZE);
-   cpu_set_ttbr0(orig_ttbr0);
+ write_sysreg(orig_ttbr0 ,TTBR0);
        flush_cache_all();
        local_flush_bp_all();
        local_flush_tlb_all();

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
> On 12/10/17 15:59, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>> On 11/10/17 09:22, Abbott Liu wrote:
>>> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
>>> index f2e1af4..6e26714 100644
>>> --- a/arch/arm/include/asm/proc-fns.h
>>> +++ b/arch/arm/include/asm/proc-fns.h
>>> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>>>  		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
>>>  		(pgd_t *)phys_to_virt(pg);		\
>>>  	})
>>> +
>>> +#define cpu_set_ttbr0(val)					\
>>> +	do {							\
>>> +		u64 ttbr = val;					\
>>> +		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
>>> +			: : "r" (ttbr));	\
>>> +	} while (0)
>>> +
>>> +
>>>  #else
>>>  #define cpu_get_pgd()	\
>>>  	({						\
>>> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>>>  		pg &= ~0x3fff;				\
>>>  		(pgd_t *)phys_to_virt(pg);		\
>>>  	})
>>> +
>>> +#define cpu_set_ttbr(nr, val)					\
>>> +	do {							\
>>> +		u64 ttbr = val;					\
>>> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
>>> +			: : "r" (ttbr));			\
>>> +	} while (0)
>>> +
>>> +#define cpu_get_ttbr(nr)					\
>>> +	({							\
>>> +		unsigned long ttbr;				\
>>> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
>>> +			: "=r" (ttbr));				\
>>> +		ttbr;						\
>>> +	})
>>> +
>>> +#define cpu_set_ttbr0(val)					\
>>> +	do {							\
>>> +		u64 ttbr = val;					\
>>> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
>>> +			: : "r" (ttbr));			\
>>> +	} while (0)
>>> +
>>> +
>>
>> You could instead lift and extend the definitions provided in kvm_hyp.h,
>> and use the read_sysreg/write_sysreg helpers defined in cp15.h.
> 
> Thanks for your review. 
> I extend definitions of TTBR0/TTBR1/PAR in kvm_hyp.h when the CONFIG_ARM_LPAE is 
> not defined. 
> Because cortex A9 don't support virtualization, so use CONFIG_ARM_LPAE to exclude
> some functions and macros which are only used in virtualization.
> 
> Here is the code which I tested on vexpress_a15 and vexpress_a9:
> 
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 14b5903..2592608 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -19,12 +19,14 @@
>  #define __ARM_KVM_HYP_H__
> 
>  #include <linux/compiler.h>
> -#include <linux/kvm_host.h>
>  #include <asm/cp15.h>
> +
> +#ifdef CONFIG_ARM_LPAE
> +#include <linux/kvm_host.h>
>  #include <asm/kvm_mmu.h>
>  #include <asm/vfp.h>
> -
>  #define __hyp_text __section(.hyp.text) notrace
> +#endif
> 
>  #define __ACCESS_VFP(CRn)                      \
>         "mrc", "mcr", __stringify(p10, 7, %0, CRn, cr0, 0), u32
> @@ -37,12 +39,18 @@
>         __val;                                                  \
>  })
> 
> +#ifdef CONFIG_ARM_LPAE
>  #define TTBR0          __ACCESS_CP15_64(0, c2)
>  #define TTBR1          __ACCESS_CP15_64(1, c2)
>  #define VTTBR          __ACCESS_CP15_64(6, c2)
>  #define PAR            __ACCESS_CP15_64(0, c7)
>  #define CNTV_CVAL      __ACCESS_CP15_64(3, c14)
>  #define CNTVOFF                __ACCESS_CP15_64(4, c14)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR          __ACCESS_CP15(c7, 0, c4, 0)
> +#endif

There is no reason for this LPAE vs non LPAE dichotomy. Both registers
do exist if your system supports LPAE. So you can either suffix the
64bit version with an _64 (and change the KVM code), or suffix the bit
version with _32.

> 
>  #define MIDR           __ACCESS_CP15(c0, 0, c0, 0)
>  #define CSSELR         __ACCESS_CP15(c0, 2, c0, 0)
> @@ -98,6 +106,7 @@
>  #define cntvoff_el2                    CNTVOFF
>  #define cnthctl_el2                    CNTHCTL
> 
> +#ifdef CONFIG_ARM_LPAE
>  void __timer_save_state(struct kvm_vcpu *vcpu);
>  void __timer_restore_state(struct kvm_vcpu *vcpu);
> 
> @@ -123,5 +132,6 @@ void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
>  asmlinkage int __guest_enter(struct kvm_vcpu *vcpu,
>                              struct kvm_cpu_context *host);
>  asmlinkage int __hyp_do_panic(const char *, int, u32);
> +#endif
> 
>  #endif /* __ARM_KVM_HYP_H__ */
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> index 049ee0a..359a782 100644
> --- a/arch/arm/mm/kasan_init.c
> +++ b/arch/arm/mm/kasan_init.c
> @@ -15,6 +15,7 @@
>  #include <asm/proc-fns.h>
>  #include <asm/tlbflush.h>
>  #include <asm/cp15.h>
> +#include <asm/kvm_hyp.h>

No, please don't do that. You shouldn't have to include KVM stuff in
unrelated code. Instead of adding stuff to kvm_hyp.h, move all the
__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this
is where new definition should be added.

>  #include <linux/sched/task.h>
> 
>  #include "mm.h"
> @@ -203,16 +204,16 @@ void __init kasan_init(void)
>         u64 orig_ttbr0;
>         int i;
> 
> -   orig_ttbr0 = cpu_get_ttbr(0);
> + orig_ttbr0 = read_sysreg(TTBR0);
> 
>  #ifdef CONFIG_ARM_LPAE
>         memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
>         memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
>         set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
> -   cpu_set_ttbr0(__pa(tmp_page_table));
> + write_sysreg(__pa(tmp_page_table), TTBR0);
>  #else
>         memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
> -   cpu_set_ttbr0(__pa(tmp_page_table));
> + write_sysreg(__pa(tmp_page_table),TTBR0);
>  #endif
>         flush_cache_all();
>         local_flush_bp_all();
> @@ -257,7 +258,7 @@ void __init kasan_init(void)
>                                  /*__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY))*/
>                                 __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)));
>         memset(kasan_zero_page, 0, PAGE_SIZE);
> -   cpu_set_ttbr0(orig_ttbr0);
> + write_sysreg(orig_ttbr0 ,TTBR0);
>         flush_cache_all();
>         local_flush_bp_all();
>         local_flush_tlb_all();
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
>> index 049ee0a..359a782 100644
>> --- a/arch/arm/mm/kasan_init.c
>> +++ b/arch/arm/mm/kasan_init.c
>> @@ -15,6 +15,7 @@
>>  #include <asm/proc-fns.h>
>>  #include <asm/tlbflush.h>
>>  #include <asm/cp15.h>
>> +#include <asm/kvm_hyp.h>
>
>No, please don't do that. You shouldn't have to include KVM stuff in
>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the
>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this
>is where new definition should be added.

Thanks for your review.
You are right. It is better to move __ACCESS_CP15* to cp15.h than to include
kvm_hyp.h. But I don't think it is a good idea to move registers definition which
is used in virtualization to cp15.h, Because there is no virtualization stuff in
cp15.h.

Here is the code which I tested on vexpress_a15 and vexpress_a9:
diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
index dbdbce1..6db1f51 100644
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -64,6 +64,43 @@
 #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
 #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)

+#ifdef CONFIG_ARM_LPAE
+#define TTBR0           __ACCESS_CP15_64(0, c2)
+#define TTBR1           __ACCESS_CP15_64(1, c2)
+#define PAR             __ACCESS_CP15_64(0, c7)
+#else
+#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
+#endif
+#define MIDR            __ACCESS_CP15(c0, 0, c0, 0)
+#define CSSELR          __ACCESS_CP15(c0, 2, c0, 0)
+#define SCTLR           __ACCESS_CP15(c1, 0, c0, 0)
+#define CPACR           __ACCESS_CP15(c1, 0, c0, 2)
+#define TTBCR           __ACCESS_CP15(c2, 0, c0, 2)
+#define DACR            __ACCESS_CP15(c3, 0, c0, 0)
+#define DFSR            __ACCESS_CP15(c5, 0, c0, 0)
+#define IFSR            __ACCESS_CP15(c5, 0, c0, 1)
+#define ADFSR           __ACCESS_CP15(c5, 0, c1, 0)
+#define AIFSR           __ACCESS_CP15(c5, 0, c1, 1)
+#define DFAR            __ACCESS_CP15(c6, 0, c0, 0)
+#define IFAR            __ACCESS_CP15(c6, 0, c0, 2)
+#define ICIALLUIS       __ACCESS_CP15(c7, 0, c1, 0)
+#define ATS1CPR         __ACCESS_CP15(c7, 0, c8, 0)
+#define TLBIALLIS       __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL         __ACCESS_CP15(c8, 0, c7, 0)
+#define TLBIALLNSNHIS   __ACCESS_CP15(c8, 4, c3, 4)
+#define PRRR            __ACCESS_CP15(c10, 0, c2, 0)
+#define NMRR            __ACCESS_CP15(c10, 0, c2, 1)
+#define AMAIR0          __ACCESS_CP15(c10, 0, c3, 0)
+#define AMAIR1          __ACCESS_CP15(c10, 0, c3, 1)
+#define CID             __ACCESS_CP15(c13, 0, c0, 1)
+#define TID_URW         __ACCESS_CP15(c13, 0, c0, 2)
+#define TID_URO         __ACCESS_CP15(c13, 0, c0, 3)
+#define TID_PRIV        __ACCESS_CP15(c13, 0, c0, 4)
+#define CNTKCTL         __ACCESS_CP15(c14, 0, c1, 0)
+#define CNTHCTL         __ACCESS_CP15(c14, 4, c1, 0)
+
 extern unsigned long cr_alignment;     /* defined in entry-armv.S */

 static inline unsigned long get_cr(void)
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 14b5903..db8d8db 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -37,55 +37,25 @@
        __val;                                                  \
 })

-#define TTBR0              __ACCESS_CP15_64(0, c2)
-#define TTBR1              __ACCESS_CP15_64(1, c2)
 #define VTTBR          __ACCESS_CP15_64(6, c2)
-#define PAR                __ACCESS_CP15_64(0, c7)
 #define CNTV_CVAL      __ACCESS_CP15_64(3, c14)
 #define CNTVOFF                __ACCESS_CP15_64(4, c14)

-#define MIDR               __ACCESS_CP15(c0, 0, c0, 0)
-#define CSSELR             __ACCESS_CP15(c0, 2, c0, 0)
 #define VPIDR          __ACCESS_CP15(c0, 4, c0, 0)
 #define VMPIDR         __ACCESS_CP15(c0, 4, c0, 5)
-#define SCTLR              __ACCESS_CP15(c1, 0, c0, 0)
-#define CPACR              __ACCESS_CP15(c1, 0, c0, 2)
 #define HCR            __ACCESS_CP15(c1, 4, c1, 0)
 #define HDCR           __ACCESS_CP15(c1, 4, c1, 1)
 #define HCPTR          __ACCESS_CP15(c1, 4, c1, 2)
 #define HSTR           __ACCESS_CP15(c1, 4, c1, 3)
-#define TTBCR              __ACCESS_CP15(c2, 0, c0, 2)
 #define HTCR           __ACCESS_CP15(c2, 4, c0, 2)
 #define VTCR           __ACCESS_CP15(c2, 4, c1, 2)
-#define DACR               __ACCESS_CP15(c3, 0, c0, 0)
-#define DFSR               __ACCESS_CP15(c5, 0, c0, 0)
-#define IFSR               __ACCESS_CP15(c5, 0, c0, 1)
-#define ADFSR              __ACCESS_CP15(c5, 0, c1, 0)
-#define AIFSR              __ACCESS_CP15(c5, 0, c1, 1)
 #define HSR            __ACCESS_CP15(c5, 4, c2, 0)
-#define DFAR               __ACCESS_CP15(c6, 0, c0, 0)
-#define IFAR               __ACCESS_CP15(c6, 0, c0, 2)
 #define HDFAR          __ACCESS_CP15(c6, 4, c0, 0)
 #define HIFAR          __ACCESS_CP15(c6, 4, c0, 2)
 #define HPFAR          __ACCESS_CP15(c6, 4, c0, 4)
-#define ICIALLUIS  __ACCESS_CP15(c7, 0, c1, 0)
-#define ATS1CPR            __ACCESS_CP15(c7, 0, c8, 0)
-#define TLBIALLIS  __ACCESS_CP15(c8, 0, c3, 0)
-#define TLBIALL            __ACCESS_CP15(c8, 0, c7, 0)
-#define TLBIALLNSNHIS      __ACCESS_CP15(c8, 4, c3, 4)
-#define PRRR               __ACCESS_CP15(c10, 0, c2, 0)
-#define NMRR               __ACCESS_CP15(c10, 0, c2, 1)
-#define AMAIR0             __ACCESS_CP15(c10, 0, c3, 0)
-#define AMAIR1             __ACCESS_CP15(c10, 0, c3, 1)
 #define VBAR           __ACCESS_CP15(c12, 0, c0, 0)
-#define CID                __ACCESS_CP15(c13, 0, c0, 1)
-#define TID_URW            __ACCESS_CP15(c13, 0, c0, 2)
-#define TID_URO            __ACCESS_CP15(c13, 0, c0, 3)
-#define TID_PRIV   __ACCESS_CP15(c13, 0, c0, 4)
 #define HTPIDR         __ACCESS_CP15(c13, 4, c0, 2)
-#define CNTKCTL            __ACCESS_CP15(c14, 0, c1, 0)
 #define CNTV_CTL       __ACCESS_CP15(c14, 0, c3, 1)
-#define CNTHCTL            __ACCESS_CP15(c14, 4, c1, 0)

 #define VFP_FPEXC      __ACCESS_VFP(FPEXC)

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
>>> index 049ee0a..359a782 100644
>>> --- a/arch/arm/mm/kasan_init.c
>>> +++ b/arch/arm/mm/kasan_init.c
>>> @@ -15,6 +15,7 @@
>>>  #include <asm/proc-fns.h>
>>>  #include <asm/tlbflush.h>
>>>  #include <asm/cp15.h>
>>> +#include <asm/kvm_hyp.h>
>>
>>No, please don't do that. You shouldn't have to include KVM stuff in
>>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the
>>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this
>>is where new definition should be added.
>
> Thanks for your review.  You are right. It is better to move
> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think
> it is a good idea to move registers definition which is used in
> virtualization to cp15.h, Because there is no virtualization stuff in
> cp15.h.

It is not about virtualization at all.

It is about what is a CP15 register and what is not. This file is called
"cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But
at the end of the day, that's for Russell to decide.

>
> Here is the code which I tested on vexpress_a15 and vexpress_a9:
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index dbdbce1..6db1f51 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -64,6 +64,43 @@
>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>
> +#ifdef CONFIG_ARM_LPAE
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> +#endif

Again: there is no point in not having these register encodings
cohabiting. They are both perfectly defined in the architecture. Just
suffix one (or even both) with their respective size, making it obvious
which one you're talking about.

Thanks,

	M.
-- 
Jazz is not dead, it just smell funny.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
>>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
>>>> index 049ee0a..359a782 100644
>>>> --- a/arch/arm/mm/kasan_init.c
>>>> +++ b/arch/arm/mm/kasan_init.c
>>>> @@ -15,6 +15,7 @@
>>>>  #include <asm/proc-fns.h>
>>>>  #include <asm/tlbflush.h>
>>>>  #include <asm/cp15.h>
>>>> +#include <asm/kvm_hyp.h>
>>>
>>>No, please don't do that. You shouldn't have to include KVM stuff in
>>>unrelated code. Instead of adding stuff to kvm_hyp.h, move all the
>>>__ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this
>>>is where new definition should be added.
>>
>> Thanks for your review.  You are right. It is better to move
>> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think
>> it is a good idea to move registers definition which is used in
>> virtualization to cp15.h, Because there is no virtualization stuff in
>> cp15.h.
>
>It is not about virtualization at all.
>
>It is about what is a CP15 register and what is not. This file is called
>"cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But
>at the end of the day, that's for Russell to decide.

Thanks for your review.
You are right, all __ACCESS_CP15* are cp15 registers. I splited normal cp15 register
(such as TTBR0/TTBR1/SCTLR and so on) and virtualizaton cp15 registers(such as VTTBR/
CNTV_CVAL/HCR) because I didn't think we need use those virtualization cp15 registers
in non virtualization system.

But now I think all __ACCESS_CP15* move to cp15.h may be a better choise. 

>>
>> Here is the code which I tested on vexpress_a15 and vexpress_a9:
>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
>> index dbdbce1..6db1f51 100644
>> --- a/arch/arm/include/asm/cp15.h
>> +++ b/arch/arm/include/asm/cp15.h
>> @@ -64,6 +64,43 @@
>>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>
>> +#ifdef CONFIG_ARM_LPAE
>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>> +#define PAR             __ACCESS_CP15_64(0, c7)
>> +#else
>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>> +#endif
>
>Again: there is no point in not having these register encodings
>cohabiting. They are both perfectly defined in the architecture. Just
>suffix one (or even both) with their respective size, making it obvious
>which one you're talking about.

I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way
between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
The following description is the reason:
Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf:

B4.1.155 TTBR0, Translation Table Base Register 0, VMSA
...
The Multiprocessing Extensions change the TTBR0 32-bit register format.
The Large Physical Address Extension extends TTBR0 to a 64-bit register. In an
implementation that includes the Large Physical Address Extension, TTBCR.EAE
determines which TTBR0 format is used:
EAE==0 32-bit format is used. TTBR0[63:32] are ignored.
EAE==1 64-bit format is used.

B4.1.156 TTBR1, Translation Table Base Register 1, VMSA
...
The Multiprocessing Extensions change the TTBR0 32-bit register format.
The Large Physical Address Extension extends TTBR1 to a 64-bit register. In an
implementation that includes the Large Physical Address Extension, TTBCR.EAE
determines which TTBR1 format is used:
EAE==0 32-bit format is used. TTBR1[63:32] are ignored.
EAE==1 64-bit format is used.

B4.1.154 TTBCR, Translation Table Base Control Register, VMSA
...
EAE, bit[31], if implementation includes the Large Physical Address Extension
Extended Address Enable. The meanings of the possible values of this bit are:
0   Use the 32-bit translation system, with the Short-descriptor translation table format. In
this case, the format of the TTBCR is as described in this section.
1   Use the 40-bit translation system, with the Long-descriptor translation table format. In
this case, the format of the TTBCR is as described in TTBCR format when using the
Long-descriptor translation table format on page B4-1692.

B4.1.112 PAR, Physical Address Register, VMSA
If the implementation includes the Large Physical Address Extension, the PAR is extended
to be a 64-bit register and:
* The 64-bit PAR is used:
- when using the Long-descriptor translation table format
- in an implementation that includes the Virtualization Extensions, for the result
of an ATS1Cxx operation performed from Hyp mode.
* The 32-bit PAR is used when using the Short-descriptor translation table format. In
this case, PAR[63:32] is UNK/SBZP.
Otherwise, the PAR is a 32-bit register.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
> On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>> On 09/11/17 18:11, Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>> On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
>>>>> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
>>>>> index 049ee0a..359a782 100644
>>>>> --- a/arch/arm/mm/kasan_init.c
>>>>> +++ b/arch/arm/mm/kasan_init.c
>>>>> @@ -15,6 +15,7 @@
>>>>>  #include <asm/proc-fns.h>
>>>>>  #include <asm/tlbflush.h>
>>>>>  #include <asm/cp15.h>
>>>>> +#include <asm/kvm_hyp.h>
>>>>
>>>> No, please don't do that. You shouldn't have to include KVM stuff in
>>>> unrelated code. Instead of adding stuff to kvm_hyp.h, move all the
>>>> __ACCESS_CP15* to cp15.h, and it will be obvious to everyone that this
>>>> is where new definition should be added.
>>>
>>> Thanks for your review.  You are right. It is better to move
>>> __ACCESS_CP15* to cp15.h than to include kvm_hyp.h. But I don't think
>>> it is a good idea to move registers definition which is used in
>>> virtualization to cp15.h, Because there is no virtualization stuff in
>>> cp15.h.
>>
>> It is not about virtualization at all.
>>
>> It is about what is a CP15 register and what is not. This file is called
>> "cp15.h", not "cp15-except-virtualization-and-maybe-some-others.h". But
>> at the end of the day, that's for Russell to decide.
> 
> Thanks for your review.
> You are right, all __ACCESS_CP15* are cp15 registers. I splited normal cp15 register
> (such as TTBR0/TTBR1/SCTLR and so on) and virtualizaton cp15 registers(such as VTTBR/
> CNTV_CVAL/HCR) because I didn't think we need use those virtualization cp15 registers
> in non virtualization system.
> 
> But now I think all __ACCESS_CP15* move to cp15.h may be a better choise. 
> 
>>>
>>> Here is the code which I tested on vexpress_a15 and vexpress_a9:
>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
>>> index dbdbce1..6db1f51 100644
>>> --- a/arch/arm/include/asm/cp15.h
>>> +++ b/arch/arm/include/asm/cp15.h
>>> @@ -64,6 +64,43 @@
>>>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>>
>>> +#ifdef CONFIG_ARM_LPAE
>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>> +#else
>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>> +#endif
>>
>> Again: there is no point in not having these register encodings
>> cohabiting. They are both perfectly defined in the architecture. Just
>> suffix one (or even both) with their respective size, making it obvious
>> which one you're talking about.
> 
> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way
> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
> The following description is the reason:
> Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf:
[...]

You're missing the point. TTBR0 existence as a 64bit CP15 register has
nothing to do the kernel being compiled with LPAE or not. It has
everything to do with the HW supporting LPAE, and it is the kernel's job
to use the right accessor depending on how it is compiled. On a CPU
supporting LPAE, both TTBR0 accessors are valid. It is the kernel that
chooses to use one rather than the other.

Also, if I follow your reasoning, why are you bothering defining PAR in
the non-LPAE case? It is not used by anything, as far as I can see...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
>> On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
>>>> index dbdbce1..6db1f51 100644
>>>> --- a/arch/arm/include/asm/cp15.h
>>>> +++ b/arch/arm/include/asm/cp15.h
>>>> @@ -64,6 +64,43 @@
>>>>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>>>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>>>
>>>> +#ifdef CONFIG_ARM_LPAE
>>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>>> +#else
>>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>>> +#endif
>>> Again: there is no point in not having these register encodings
>>> cohabiting. They are both perfectly defined in the architecture. Just
>>> suffix one (or even both) with their respective size, making it obvious
>>> which one you're talking about.
>> 
>> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR in to different way
>> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
>> The following description is the reason:
>> Here is the description come from DDI0406C2c_arm_architecture_reference_manual.pdf:
>[...]
>
>You're missing the point. TTBR0 existence as a 64bit CP15 register has
>nothing to do the kernel being compiled with LPAE or not. It has
>everything to do with the HW supporting LPAE, and it is the kernel's job
>to use the right accessor depending on how it is compiled. On a CPU
>supporting LPAE, both TTBR0 accessors are valid. It is the kernel that
>chooses to use one rather than the other.

Thanks for your review.
I don't think both TTBR0 accessors(64bit accessor and 32bit accessor) are valid on a CPU supporting
LPAE which the LPAE is enabled. Here is the description come form DDI0406C2c_arm_architecture_reference_manual.pdf
(=ARM? Architecture Reference Manual ARMv7-A and ARMv7-R edition) which you can get the document
by google "ARM? Architecture Reference Manual ARMv7-A and ARMv7-R edition". 

64-bit TTBR0 and TTBR1 format
The bit assignments for the 64-bit implementations of TTBR0 and TTBR1 are identical, and are:
Bits[63:56] UNK/SBZP.
ASID, bits[55:48]:
  An ASID for the translation table base address. The TTBCR.A1 field selects either TTBR0.ASID
or TTBR1.ASID.
Bits[47:40] UNK/SBZP.
BADDR, bits[39:x]:
   Translation table base address, bits[39:x]. Defining the translation table base address width on
page B4-1698 describes how x is defined.
The value of x determines the required alignment of the translation table, which must be aligned to
2x bytes.

Bits[x-1:0] UNK/SBZP.
...
To access a 64-bit TTBR0, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c2 and
<opc1> set to 0. For example:
MRRC p15,0,<Rt>,<Rt2>, c2 ; Read 64-bit TTBR0 into Rt (low word) and Rt2 (high word)
MCRR p15,0,<Rt>,<Rt2>, c2 ; Write Rt (low word) and Rt2 (high word) to 64-bit TTBR0

So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must use "mcrr/mrrc" instruction
(__ACCESS_CP15_64). If you access TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction 
which is 32bit version (__ACCESS_CP15), even if the CPU doesn't report error, you also lose the high
or low 32bit of the TTBR0/TTBR1.

>Also, if I follow your reasoning, why are you bothering defining PAR in
>the non-LPAE case? It is not used by anything, as far as I can see...

I don't use the PAR, I change the defining PAR just because I think it will be wrong in
a non LPAE CPU.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On Thu, Nov 16 2017 at  3:07:54 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
>>> On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)"
>>>> <liuwenliang@huawei.com> wrote:
>>>>> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
>>>>> index dbdbce1..6db1f51 100644
>>>>> --- a/arch/arm/include/asm/cp15.h
>>>>> +++ b/arch/arm/include/asm/cp15.h
>>>>> @@ -64,6 +64,43 @@
>>>>>  #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : :
>>>>> "r" ((t)(v)))
>>>>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>>>>
>>>>> +#ifdef CONFIG_ARM_LPAE
>>>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>>>> +#else
>>>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>>>> +#endif
>>>> Again: there is no point in not having these register encodings
>>>> cohabiting. They are both perfectly defined in the architecture. Just
>>>> suffix one (or even both) with their respective size, making it obvious
>>>> which one you're talking about.
>>> 
>>> I am sorry that I didn't point why I need to define TTBR0/
>>> TTBR1/PAR in to different way
>>> between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
>>> The following description is the reason:
>>> Here is the description come from
>>> DDI0406C2c_arm_architecture_reference_manual.pdf:
>>[...]
>>
>>You're missing the point. TTBR0 existence as a 64bit CP15 register has
>>nothing to do the kernel being compiled with LPAE or not. It has
>>everything to do with the HW supporting LPAE, and it is the kernel's job
>>to use the right accessor depending on how it is compiled. On a CPU
>>supporting LPAE, both TTBR0 accessors are valid. It is the kernel that
>>chooses to use one rather than the other.
>
> Thanks for your review.  I don't think both TTBR0 accessors(64bit
> accessor and 32bit accessor) are valid on a CPU supporting LPAE which
> the LPAE is enabled. Here is the description come form
> DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM? Architecture
> Reference Manual ARMv7-A and ARMv7-R edition) which you can get the
> document by google "ARM? Architecture Reference Manual ARMv7-A and
> ARMv7-R edition".

Trust me, from where I seat, I have a much better source than Google for
that document. Who would have thought?

Nothing in what you randomly quote invalids what I've been saying. And
to show you what's wrong with your reasoning, let me describe a
scenario,

I have a non-LPAE kernel that runs on my system. It uses the 32bit
version of the TTBRs. It turns out that this kernel runs under a
hypervisor (KVM, Xen, or your toy of the day). The hypervisor
context-switches vcpus without even looking at whether the configuration
of that guest. It doesn't have to care. It just blindly uses the 64bit
version of the TTBRs.

The architecture *guarantees* that it works (it even works with a 32bit
guest under a 64bit hypervisor). In your world, this doesn't work. I
guess the architecture wins.

> So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must
> use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access
> TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is
> 32bit version (__ACCESS_CP15), even if the CPU doesn't report error,
> you also lose the high or low 32bit of the TTBR0/TTBR1.

It is not about "supporting LPAE". It is about using the accessor that
makes sense in a particular context. Yes, the architecture allows you to
do something stupid. Don't do it. It doesn't mean the accessors cannot
be used, and I hope that my example above demonstrates it.

Conclusion: I still stand by my request that both versions of TTBRs/PAR
are described without depending on the kernel configuration, because
this has nothing to do with the kernel configuration.

Thanks,

	M.
-- 
Jazz is not dead, it just smell funny.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 16/11/17  17:54 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>On Thu, Nov 16 2017 at  3:07:54 am GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
>>>> On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)"
>>>>> <liuwenliang@huawei.com> wrote:
>>>>>> diff --git a/arch/arm/include/asm/cp15.h
>>>>>> b/arch/arm/include/asm/cp15.h index dbdbce1..6db1f51 100644
>>>>>> --- a/arch/arm/include/asm/cp15.h
>>>>>> +++ b/arch/arm/include/asm/cp15.h
>>>>>> @@ -64,6 +64,43 @@
>>>>>>  #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : :
>>>>>> "r" ((t)(v)))
>>>>>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>>>>>
>>>>>> +#ifdef CONFIG_ARM_LPAE
>>>>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>>>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>>>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>>>>> +#else
>>>>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>>>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>>>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>>>>> +#endif
>>>>> Again: there is no point in not having these register encodings
>>>>> cohabiting. They are both perfectly defined in the architecture.
>>>>> Just suffix one (or even both) with their respective size, making
>>>>> it obvious which one you're talking about.
>>>>
>>>> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR
>>>> in to different way between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
>>>> The following description is the reason:
>>>> Here is the description come from
>>>> DDI0406C2c_arm_architecture_reference_manual.pdf:
>>>[...]
>>>
>>>You're missing the point. TTBR0 existence as a 64bit CP15 register has
>>>nothing to do the kernel being compiled with LPAE or not. It has
>>>everything to do with the HW supporting LPAE, and it is the kernel's job
>>>to use the right accessor depending on how it is compiled. On a CPU
>>>supporting LPAE, both TTBR0 accessors are valid. It is the kernel that
>>>chooses to use one rather than the other.
>>
>> Thanks for your review.  I don't think both TTBR0 accessors(64bit
>> accessor and 32bit accessor) are valid on a CPU supporting LPAE which
>> the LPAE is enabled. Here is the description come form
>> DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM? Architecture
>> Reference Manual ARMv7-A and ARMv7-R edition) which you can get the
>> document by google "ARM? Architecture Reference Manual ARMv7-A and
>> ARMv7-R edition".

>Trust me, from where I seat, I have a much better source than Google for
>that document. Who would have thought?

>Nothing in what you randomly quote invalids what I've been saying. And
>to show you what's wrong with your reasoning, let me describe a
>scenario,

>I have a non-LPAE kernel that runs on my system. It uses the 32bit
>version of the TTBRs. It turns out that this kernel runs under a
>hypervisor (KVM, Xen, or your toy of the day). The hypervisor
>context-switches vcpus without even looking at whether the configuration
>of that guest. It doesn't have to care. It just blindly uses the 64bit
>version of the TTBRs.

>The architecture *guarantees* that it works (it even works with a 32bit
>guest under a 64bit hypervisor). In your world, this doesn't work. I
>guess the architecture wins.

>> So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must
>> use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access
>> TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is
>> 32bit version (__ACCESS_CP15), even if the CPU doesn't report error,
>> you also lose the high or low 32bit of the TTBR0/TTBR1.

>It is not about "supporting LPAE". It is about using the accessor that
>makes sense in a particular context. Yes, the architecture allows you to
>do something stupid. Don't do it. It doesn't mean the accessors cannot
>be used, and I hope that my example above demonstrates it.

>Conclusion: I still stand by my request that both versions of TTBRs/PAR
>are described without depending on the kernel configuration, because
>this has nothing to do with the kernel configuration.

Thanks for your reviews.
Yes, you are right. I have tested that "mcrr/mrrc" instruction (__ACCESS_CP15_64)
can work on non LPAE on vexpress_a9.

Here is the code I tested on vexpress_a9 and vexpress_a15:
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -64,6 +64,56 @@
 #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
 #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)

+#define TTBR0           __ACCESS_CP15_64(0, c2)
+#define TTBR1           __ACCESS_CP15_64(1, c2)
+#define PAR             __ACCESS_CP15_64(0, c7)
+#define VTTBR           __ACCESS_CP15_64(6, c2)
+#define CNTV_CVAL       __ACCESS_CP15_64(3, c14)
+#define CNTVOFF         __ACCESS_CP15_64(4, c14)
+
+#define MIDR            __ACCESS_CP15(c0, 0, c0, 0)
+#define CSSELR          __ACCESS_CP15(c0, 2, c0, 0)
+#define VPIDR           __ACCESS_CP15(c0, 4, c0, 0)
+#define VMPIDR          __ACCESS_CP15(c0, 4, c0, 5)
+#define SCTLR           __ACCESS_CP15(c1, 0, c0, 0)
+#define CPACR           __ACCESS_CP15(c1, 0, c0, 2)
+#define HCR             __ACCESS_CP15(c1, 4, c1, 0)
+#define HDCR            __ACCESS_CP15(c1, 4, c1, 1)
+#define HCPTR           __ACCESS_CP15(c1, 4, c1, 2)
+#define HSTR            __ACCESS_CP15(c1, 4, c1, 3)
+#define TTBCR           __ACCESS_CP15(c2, 0, c0, 2)
+#define HTCR            __ACCESS_CP15(c2, 4, c0, 2)
+#define VTCR            __ACCESS_CP15(c2, 4, c1, 2)
+#define DACR            __ACCESS_CP15(c3, 0, c0, 0)
+#define DFSR            __ACCESS_CP15(c5, 0, c0, 0)
+#define IFSR            __ACCESS_CP15(c5, 0, c0, 1)
+#define ADFSR           __ACCESS_CP15(c5, 0, c1, 0)
+#define AIFSR           __ACCESS_CP15(c5, 0, c1, 1)
+#define HSR             __ACCESS_CP15(c5, 4, c2, 0)
+#define DFAR            __ACCESS_CP15(c6, 0, c0, 0)
+#define IFAR            __ACCESS_CP15(c6, 0, c0, 2)
+#define HDFAR           __ACCESS_CP15(c6, 4, c0, 0)
+#define HIFAR           __ACCESS_CP15(c6, 4, c0, 2)
+#define HPFAR           __ACCESS_CP15(c6, 4, c0, 4)
+#define ICIALLUIS       __ACCESS_CP15(c7, 0, c1, 0)
+#define ATS1CPR         __ACCESS_CP15(c7, 0, c8, 0)
+#define TLBIALLIS       __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL         __ACCESS_CP15(c8, 0, c7, 0)
+#define TLBIALLNSNHIS   __ACCESS_CP15(c8, 4, c3, 4)
+#define PRRR            __ACCESS_CP15(c10, 0, c2, 0)
+#define NMRR            __ACCESS_CP15(c10, 0, c2, 1)
+#define AMAIR0          __ACCESS_CP15(c10, 0, c3, 0)
+#define AMAIR1          __ACCESS_CP15(c10, 0, c3, 1)
+#define VBAR            __ACCESS_CP15(c12, 0, c0, 0)
+#define CID             __ACCESS_CP15(c13, 0, c0, 1)
+#define TID_URW         __ACCESS_CP15(c13, 0, c0, 2)
+#define TID_URO         __ACCESS_CP15(c13, 0, c0, 3)
+#define TID_PRIV        __ACCESS_CP15(c13, 0, c0, 4)
+#define HTPIDR          __ACCESS_CP15(c13, 4, c0, 2)
+#define CNTKCTL         __ACCESS_CP15(c14, 0, c1, 0)
+#define CNTV_CTL        __ACCESS_CP15(c14, 0, c3, 1)
+#define CNTHCTL         __ACCESS_CP15(c14, 4, c1, 0)
+
extern unsigned long cr_alignment;     /* defined in entry-armv.S */

 static inline unsigned long get_cr(void)
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 14b5903..8db8a8c 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -37,56 +37,6 @@
        __val;                                                  \
 })

-#define TTBR0              __ACCESS_CP15_64(0, c2)
-#define TTBR1              __ACCESS_CP15_64(1, c2)
-#define VTTBR              __ACCESS_CP15_64(6, c2)
-#define PAR                __ACCESS_CP15_64(0, c7)
-#define CNTV_CVAL  __ACCESS_CP15_64(3, c14)
-#define CNTVOFF            __ACCESS_CP15_64(4, c14)
-
-#define MIDR               __ACCESS_CP15(c0, 0, c0, 0)
-#define CSSELR             __ACCESS_CP15(c0, 2, c0, 0)
-#define VPIDR              __ACCESS_CP15(c0, 4, c0, 0)
-#define VMPIDR             __ACCESS_CP15(c0, 4, c0, 5)
-#define SCTLR              __ACCESS_CP15(c1, 0, c0, 0)
-#define CPACR              __ACCESS_CP15(c1, 0, c0, 2)
-#define HCR                __ACCESS_CP15(c1, 4, c1, 0)
-#define HDCR               __ACCESS_CP15(c1, 4, c1, 1)
-#define HCPTR              __ACCESS_CP15(c1, 4, c1, 2)
-#define HSTR               __ACCESS_CP15(c1, 4, c1, 3)
-#define TTBCR              __ACCESS_CP15(c2, 0, c0, 2)
-#define HTCR               __ACCESS_CP15(c2, 4, c0, 2)
-#define VTCR               __ACCESS_CP15(c2, 4, c1, 2)
-#define DACR               __ACCESS_CP15(c3, 0, c0, 0)
-#define DFSR               __ACCESS_CP15(c5, 0, c0, 0)
-#define IFSR               __ACCESS_CP15(c5, 0, c0, 1)
-#define ADFSR              __ACCESS_CP15(c5, 0, c1, 0)
-#define AIFSR              __ACCESS_CP15(c5, 0, c1, 1)
-#define HSR                __ACCESS_CP15(c5, 4, c2, 0)
-#define DFAR               __ACCESS_CP15(c6, 0, c0, 0)
-#define IFAR               __ACCESS_CP15(c6, 0, c0, 2)
-#define HDFAR              __ACCESS_CP15(c6, 4, c0, 0)
-#define HIFAR              __ACCESS_CP15(c6, 4, c0, 2)
-#define HPFAR              __ACCESS_CP15(c6, 4, c0, 4)
-#define ICIALLUIS  __ACCESS_CP15(c7, 0, c1, 0)
-#define ATS1CPR            __ACCESS_CP15(c7, 0, c8, 0)
-#define TLBIALLIS  __ACCESS_CP15(c8, 0, c3, 0)
-#define TLBIALL            __ACCESS_CP15(c8, 0, c7, 0)
-#define TLBIALLNSNHIS      __ACCESS_CP15(c8, 4, c3, 4)
-#define PRRR               __ACCESS_CP15(c10, 0, c2, 0)
-#define NMRR               __ACCESS_CP15(c10, 0, c2, 1)
-#define AMAIR0             __ACCESS_CP15(c10, 0, c3, 0)
-#define AMAIR1             __ACCESS_CP15(c10, 0, c3, 1)
-#define VBAR               __ACCESS_CP15(c12, 0, c0, 0)
-#define CID                __ACCESS_CP15(c13, 0, c0, 1)
-#define TID_URW            __ACCESS_CP15(c13, 0, c0, 2)
-#define TID_URO            __ACCESS_CP15(c13, 0, c0, 3)
-#define TID_PRIV   __ACCESS_CP15(c13, 0, c0, 4)
-#define HTPIDR             __ACCESS_CP15(c13, 4, c0, 2)
-#define CNTKCTL            __ACCESS_CP15(c14, 0, c1, 0)
-#define CNTV_CTL   __ACCESS_CP15(c14, 0, c3, 1)
-#define CNTHCTL            __ACCESS_CP15(c14, 4, c1, 0)
-

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On Thu, Nov 16 2017 at  2:24:31 pm GMT, "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> On 16/11/17  17:54 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>On Thu, Nov 16 2017 at 3:07:54 am GMT, "Liuwenliang (Abbott Liu)"
>> <liuwenliang@huawei.com> wrote:
>>>>On 15/11/17 13:16, Liuwenliang (Abbott Liu) wrote:
>>>>> On 09/11/17  18:36 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>>>>>> On Wed, Nov 15 2017 at 10:20:02 am GMT, "Liuwenliang (Abbott Liu)"
>>>>>> <liuwenliang@huawei.com> wrote:
>>>>>>> diff --git a/arch/arm/include/asm/cp15.h
>>>>>>> b/arch/arm/include/asm/cp15.h index dbdbce1..6db1f51 100644
>>>>>>> --- a/arch/arm/include/asm/cp15.h
>>>>>>> +++ b/arch/arm/include/asm/cp15.h
>>>>>>> @@ -64,6 +64,43 @@
>>>>>>>  #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : :
>>>>>>> "r" ((t)(v)))
>>>>>>>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>>>>>>>
>>>>>>> +#ifdef CONFIG_ARM_LPAE
>>>>>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>>>>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>>>>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>>>>>> +#else
>>>>>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>>>>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>>>>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>>>>>> +#endif
>>>>>> Again: there is no point in not having these register encodings
>>>>>> cohabiting. They are both perfectly defined in the architecture.
>>>>>> Just suffix one (or even both) with their respective size, making
>>>>>> it obvious which one you're talking about.
>>>>>
>>>>> I am sorry that I didn't point why I need to define TTBR0/ TTBR1/PAR
>>>>> in to different way between CONFIG_ARM_LPAE and non CONFIG_ARM_LPAE.
>>>>> The following description is the reason:
>>>>> Here is the description come from
>>>>> DDI0406C2c_arm_architecture_reference_manual.pdf:
>>>>[...]
>>>>
>>>>You're missing the point. TTBR0 existence as a 64bit CP15 register has
>>>>nothing to do the kernel being compiled with LPAE or not. It has
>>>>everything to do with the HW supporting LPAE, and it is the kernel's job
>>>>to use the right accessor depending on how it is compiled. On a CPU
>>>>supporting LPAE, both TTBR0 accessors are valid. It is the kernel that
>>>>chooses to use one rather than the other.
>>>
>>> Thanks for your review.  I don't think both TTBR0 accessors(64bit
>>> accessor and 32bit accessor) are valid on a CPU supporting LPAE which
>>> the LPAE is enabled. Here is the description come form
>>> DDI0406C2c_arm_architecture_reference_manual.pdf (=ARM? Architecture
>>> Reference Manual ARMv7-A and ARMv7-R edition) which you can get the
>>> document by google "ARM? Architecture Reference Manual ARMv7-A and
>>> ARMv7-R edition".
>
>>Trust me, from where I seat, I have a much better source than Google for
>>that document. Who would have thought?
>
>>Nothing in what you randomly quote invalids what I've been saying. And
>>to show you what's wrong with your reasoning, let me describe a
>>scenario,
>
>>I have a non-LPAE kernel that runs on my system. It uses the 32bit
>>version of the TTBRs. It turns out that this kernel runs under a
>>hypervisor (KVM, Xen, or your toy of the day). The hypervisor
>>context-switches vcpus without even looking at whether the configuration
>>of that guest. It doesn't have to care. It just blindly uses the 64bit
>>version of the TTBRs.
>
>>The architecture *guarantees* that it works (it even works with a 32bit
>>guest under a 64bit hypervisor). In your world, this doesn't work. I
>>guess the architecture wins.
>
>>> So, I think if you access TTBR0/TTBR1 on CPU supporting LPAE, you must
>>> use "mcrr/mrrc" instruction (__ACCESS_CP15_64). If you access
>>> TTBR0/TTBR1 on CPU supporting LPAE by "mcr/mrc" instruction which is
>>> 32bit version (__ACCESS_CP15), even if the CPU doesn't report error,
>>> you also lose the high or low 32bit of the TTBR0/TTBR1.
>
>>It is not about "supporting LPAE". It is about using the accessor that
>>makes sense in a particular context. Yes, the architecture allows you to
>>do something stupid. Don't do it. It doesn't mean the accessors cannot
>>be used, and I hope that my example above demonstrates it.
>
>>Conclusion: I still stand by my request that both versions of TTBRs/PAR
>>are described without depending on the kernel configuration, because
>>this has nothing to do with the kernel configuration.
>
> Thanks for your reviews.
> Yes, you are right. I have tested that "mcrr/mrrc" instruction
> (__ACCESS_CP15_64) can work on non LPAE on vexpress_a9.

No, it doesn't. It cannot work, because Cortex-A9 predates the invention
of the 64bit accessor. I suspect that you are testing stuff in QEMU,
which is giving you a SW model that always supports LPAE. I suggest you
test this code on *real* HW, and not only on QEMU.

What I have said is:

- If the CPU supports LPAE, then both 32 and 64bit accessors work
- If the CPU doesn't support LPAE, then only the 32bit accssor work
- In both cases, that's a function of the CPU, and not of the kernel
  configuration.
- Both accessors can be safely defined as long as we ensure that they
  are used in the right context.

> Here is the code I tested on vexpress_a9 and vexpress_a15:
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -64,6 +64,56 @@
>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
>
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)

You still need to add the 32bit accessors.

	M.
-- 
Jazz is not dead, it just smell funny.

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 16/11/17  22:41 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>- If the CPU supports LPAE, then both 32 and 64bit accessors work


I don't how 32bit accessor can work on CPU supporting LPAE, give me your solution.

Thanks.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On 16/11/17  22:41 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
>No, it doesn't. It cannot work, because Cortex-A9 predates the invention
>of the 64bit accessor. I suspect that you are testing stuff in QEMU,
>which is giving you a SW model that always supports LPAE. I suggest you
>test this code on *real* HW, and not only on QEMU.

I am sorry. My test is fault. I only defined TTBR0 as __ACCESS_CP15_64,
but I don't use the definition TTBR0 as __ACCESS_CP15_64. 

Now I use the definition TTBR0 as __ACCESS_CP15_64 on CPU supporting
LPAE(vexpress_a9), I find it doesn't work and report undefined instruction error
when execute "mrrc" instruction.

So, you are right that 64bit accessor of TTBR0 cannot work on LPAE.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Christoffer Dall]

On Fri, Nov 17, 2017 at 07:18:45AM +0000, Liuwenliang (Abbott Liu) wrote:
> On 16/11/17  22:41 Marc Zyngier [mailto:marc.zyngier at arm.com] wrote:
> >No, it doesn't. It cannot work, because Cortex-A9 predates the invention
> >of the 64bit accessor. I suspect that you are testing stuff in QEMU,
> >which is giving you a SW model that always supports LPAE. I suggest you
> >test this code on *real* HW, and not only on QEMU.
> 
> I am sorry. My test is fault. I only defined TTBR0 as __ACCESS_CP15_64,
> but I don't use the definition TTBR0 as __ACCESS_CP15_64. 
> 
> Now I use the definition TTBR0 as __ACCESS_CP15_64 on CPU supporting
> LPAE(vexpress_a9)

What does a "CPU supporting LPAE(vexpress_a9) mean?  As Marc pointed
out, a Cortex-A9 doesn't support LPAE.  If you configure your kernel
with LPAE it's not going to work on a Cortex-A9.

> I find it doesn't work and report undefined instruction error
> when execute "mrrc" instruction.
> 
> So, you are right that 64bit accessor of TTBR0 cannot work on LPAE.
> 

It's the other way around.  It doesn't work WITHOUT LPAE, it only works
WITH LPAE.

The ARM ARM explains this quite clearly:

"Accessing TTBR0

To access TTBR0 in an implementation that does not include the Large
Physical Address Extension, or bits[31:0] of TTBR0 in an implementation
that includes the Large Physical Address Extension, software reads or
writes the CP15 registers with <opc1> set to 0, <CRn> set to c2, <CRm>
set to c0, and <opc2> set to 0. For example:

MRC p15, 0, <Rt>, c2, c0, 0
  ; Read 32-bit TTBR0 into Rt
MCR p15, 0, <Rt>, c2, c0, 0
  ; Write Rt to 32-bit TTBR0

In an implementation that includes the Large Physical Address Extension,
to access all 64 bits of TTBR0, software performs a 64-bit read or write
of the CP15 registers with <CRm> set to c2 and <opc1> set to 0. For
example:

MRRC p15, 0, <Rt>, <Rt2>, c2
  ; Read 64-bit TTBR0 into Rt (low word) and Rt2 (high word)
MCRR p15, 0, <Rt>, <Rt2>, c2
  ; Write Rt (low word) and Rt2 (high word) to 64-bit TTBR0

In these MRRC and MCRR instructions, Rt holds the least-significant word
of TTBR0, and Rt2 holds the most-significant word."

That is, if your processor (like the Cortex-A9) does NOT support LPAE,
all you have is the 32-bit accessors (MRC and MCR).

If your processor does support LPAE (like a Cortex-A15 for example),
then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
the lower 32-bits of the 64-bit register.

Hope this helps,
-Christoffer

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
>If your processor does support LPAE (like a Cortex-A15 for example),
>then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
>accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
>the lower 32-bits of the 64-bit register.
>
>Hope this helps,
>-Christoffer

If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.

TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
The following description which comes from ARM(r) Architecture Reference
Manual ARMv7-A and ARMv7-R edition tell us the reason:

64-bit TTBR0 and TTBR1 format:
...
BADDR, bits[39:x] : 
Translation table base address, bits[39:x]. Defining the translation table base address width on
page B4-1698 describes how x is defined.
The value of x determines the required alignment of the translation table, which must be aligned to
2x bytes.

Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may 
be valid value which is useful for the system.

64-bit PAR format
...
PA[39:12]
Physical Address. The physical address corresponding to the supplied virtual address. This field
returns address bits[39:12].

Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit, 
so bits[39:32] may be valid value which is useful for the system.

Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
if you do that, your system may run error.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On Sat, 18 Nov 2017 10:40:08 +0000
"Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:

> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
> >If your processor does support LPAE (like a Cortex-A15 for example),
> >then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
> >accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
> >the lower 32-bits of the 64-bit register.
> >
> >Hope this helps,
> >-Christoffer  
> 
> If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
> then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
> But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
> then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.
> 
> TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
> The following description which comes from ARM(r) Architecture Reference
> Manual ARMv7-A and ARMv7-R edition tell us the reason:
> 
> 64-bit TTBR0 and TTBR1 format:
> ...
> BADDR, bits[39:x] : 
> Translation table base address, bits[39:x]. Defining the translation table base address width on
> page B4-1698 describes how x is defined.
> The value of x determines the required alignment of the translation table, which must be aligned to
> 2x bytes.
> 
> Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may 
> be valid value which is useful for the system.
> 
> 64-bit PAR format
> ...
> PA[39:12]
> Physical Address. The physical address corresponding to the supplied virtual address. This field
> returns address bits[39:12].
> 
> Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit, 
> so bits[39:32] may be valid value which is useful for the system.
> 
> Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
> if you do that, your system may run error.

That's not really true. You can run an non-LPAE kernel that uses the
32bit accessors an a Cortex-A15 that supports LPAE. You're just limited
to 4GB of physical space. And you're pretty much guaranteed to have
some memory below 4GB (one way or another), or you'd have a slight
problem setting up your page tables.

	M.
-- 
Without deviation from the norm, progress is not possible.

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>On Sat, 18 Nov 2017 10:40:08 +0000
>"Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:

>> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
>> >If your processor does support LPAE (like a Cortex-A15 for example),
>> >then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
>> >accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
>> >the lower 32-bits of the 64-bit register.
>> >
>> >Hope this helps,
>> >-Christoffer
>>
>> If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
>> then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
>> But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
>> then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.
>>
>> TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
>> The following description which comes from ARM(r) Architecture Reference
>> Manual ARMv7-A and ARMv7-R edition tell us the reason:
>>
>> 64-bit TTBR0 and TTBR1 format:
>> ...
>> BADDR, bits[39:x] :
>> Translation table base address, bits[39:x]. Defining the translation table base address width on
>> page B4-1698 describes how x is defined.
>> The value of x determines the required alignment of the translation table, which must be aligned to
>> 2x bytes.
>>
>> Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may
>> be valid value which is useful for the system.
>>
>> 64-bit PAR format
>> ...
>> PA[39:12]
>> Physical Address. The physical address corresponding to the supplied virtual address. This field
>> returns address bits[39:12].
>>
>> Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit,
>> so bits[39:32] may be valid value which is useful for the system.
>>
>> Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
>> if you do that, your system may run error.

>That's not really true. You can run an non-LPAE kernel that uses the
>32bit accessors an a Cortex-A15 that supports LPAE. You're just limited
>to 4GB of physical space. And you're pretty much guaranteed to have
>some memory below 4GB (one way or another), or you'd have a slight
>problem setting up your page tables.

>       M.
>--
>Without deviation from the norm, progress is not possible.

Thanks for your review.
Please don't ask people to limit to 4GB of physical space on CPU
supporting LPAE, please don't ask people to guaranteed to have some
memory below 4GB on CPU supporting LPAE.
Why people select CPU supporting LPAE(just like cortex A15)? 
Because some of people think 4GB physical space is not enough for their 
system, maybe they want to use 8GB/16GB DDR space.
Then you tell them that they must guaranteed to have some memory below 4GB,
just only because you think the code as follow:
+#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR             __ACCESS_CP15(c7, 0, c4, 0)

is better than the code like this:

+#ifdef CONFIG_ARM_LPAE
+#define TTBR0           __ACCESS_CP15_64(0, c2)
+#define TTBR1           __ACCESS_CP15_64(1, c2)
+#define PAR             __ACCESS_CP15_64(0, c7)
+#else
+#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
+#endif


So,I think the following code: 
+#ifdef CONFIG_ARM_LPAE
+#define TTBR0           __ACCESS_CP15_64(0, c2)
+#define TTBR1           __ACCESS_CP15_64(1, c2)
+#define PAR             __ACCESS_CP15_64(0, c7)
+#else
+#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
+#endif

is better because it's not necessary to ask people to guaranteed to
have some memory below 4GB on CPU supporting LPAE. 
If we want to ask people to guaranteed to have some memory below 4GB 
on CPU supporting LPAE, there need to modify some other code.
I think it makes the simple problem more complex to modify some other code for this.

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
> >On Sat, 18 Nov 2017 10:40:08 +0000
> >"Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> 
> >> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
> >> >If your processor does support LPAE (like a Cortex-A15 for example),
> >> >then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
> >> >accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
> >> >the lower 32-bits of the 64-bit register.
> >> >
> >> >Hope this helps,
> >> >-Christoffer
> >>
> >> If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
> >> then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
> >> But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
> >> then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.
> >>
> >> TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
> >> The following description which comes from ARM(r) Architecture Reference
> >> Manual ARMv7-A and ARMv7-R edition tell us the reason:
> >>
> >> 64-bit TTBR0 and TTBR1 format:
> >> ...
> >> BADDR, bits[39:x] :
> >> Translation table base address, bits[39:x]. Defining the translation table base address width on
> >> page B4-1698 describes how x is defined.
> >> The value of x determines the required alignment of the translation table, which must be aligned to
> >> 2x bytes.
> >>
> >> Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may
> >> be valid value which is useful for the system.
> >>
> >> 64-bit PAR format
> >> ...
> >> PA[39:12]
> >> Physical Address. The physical address corresponding to the supplied virtual address. This field
> >> returns address bits[39:12].
> >>
> >> Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit,
> >> so bits[39:32] may be valid value which is useful for the system.
> >>
> >> Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
> >> if you do that, your system may run error.
> 
> >That's not really true. You can run an non-LPAE kernel that uses the
> >32bit accessors an a Cortex-A15 that supports LPAE. You're just limited
> >to 4GB of physical space. And you're pretty much guaranteed to have
> >some memory below 4GB (one way or another), or you'd have a slight
> >problem setting up your page tables.
> 
> >       M.
> >--
> >Without deviation from the norm, progress is not possible.
> 
> Thanks for your review.
> Please don't ask people to limit to 4GB of physical space on CPU
> supporting LPAE, please don't ask people to guaranteed to have some
> memory below 4GB on CPU supporting LPAE.

A LPAE-capable CPU must always have memory below 4GB physical, no ifs
no buts.

If there's no memory below 4GB physical, then the CPU has no accessible
memory before the MMU is enabled.  That means operating systems such as
Linux are completely unbootable.

There must _always_ be accessible memory below 4GB physical.  This is
not negotiable, it's a fundamental requirement.

The location of physical memory has nothing to do with the accessors.
This point I'm making also has nothing to do with the accessors.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 21/11/17 07:59, Liuwenliang (Abbott Liu) wrote:
> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>> On Sat, 18 Nov 2017 10:40:08 +0000
>> "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> 
>>> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
>>>> If your processor does support LPAE (like a Cortex-A15 for example),
>>>> then you have both the 32-bit accessors (MRC and MCR) and the 64-bit
>>>> accessors (MRRC, MCRR), and using the 32-bit accessor will simply access
>>>> the lower 32-bits of the 64-bit register.
>>>>
>>>> Hope this helps,
>>>> -Christoffer
>>>
>>> If you know the higher 32-bits of the 64-bits cp15's register is not useful for your system,
>>> then you can use the 32-bit accessor to get or set the 64-bit cp15's register.
>>> But if the higher 32-bits of the 64-bits cp15's register is useful for your system,
>>> then you can't use the 32-bit accessor to get or set the 64-bit cp15's register.
>>>
>>> TTBR0/TTBR1/PAR's higher 32-bits is useful for CPU supporting LPAE.
>>> The following description which comes from ARM(r) Architecture Reference
>>> Manual ARMv7-A and ARMv7-R edition tell us the reason:
>>>
>>> 64-bit TTBR0 and TTBR1 format:
>>> ...
>>> BADDR, bits[39:x] :
>>> Translation table base address, bits[39:x]. Defining the translation table base address width on
>>> page B4-1698 describes how x is defined.
>>> The value of x determines the required alignment of the translation table, which must be aligned to
>>> 2x bytes.
>>>
>>> Abbott Liu: Because BADDR on CPU supporting LPAE may be bigger than max value of 32-bit, so bits[39:32] may
>>> be valid value which is useful for the system.
>>>
>>> 64-bit PAR format
>>> ...
>>> PA[39:12]
>>> Physical Address. The physical address corresponding to the supplied virtual address. This field
>>> returns address bits[39:12].
>>>
>>> Abbott Liu: Because Physical Address on CPU supporting LPAE may be bigger than max value of 32-bit,
>>> so bits[39:32] may be valid value which is useful for the system.
>>>
>>> Conclusion: Don't use 32-bit accessor to get or set TTBR0/TTBR1/PAR on CPU supporting LPAE,
>>> if you do that, your system may run error.
> 
>> That's not really true. You can run an non-LPAE kernel that uses the
>> 32bit accessors an a Cortex-A15 that supports LPAE. You're just limited
>> to 4GB of physical space. And you're pretty much guaranteed to have
>> some memory below 4GB (one way or another), or you'd have a slight
>> problem setting up your page tables.
> 
>>       M.
>> --
>> Without deviation from the norm, progress is not possible.
> 

> Thanks for your review.
> Please don't ask people to limit to 4GB of physical space on CPU
> supporting LPAE, please don't ask people to guaranteed to have some
> memory below 4GB on CPU supporting LPAE.

Please tell me how you enable LPAE if you don't. I've truly curious.
Because otherwise, you should really take a step back and seriously
reconsider what you're writing. Hint: where do you think the page tables
required to enable LPAE will be? How do you even *boot*?

> Why people select CPU supporting LPAE(just like cortex A15)? 
> Because some of people think 4GB physical space is not enough for their 
> system, maybe they want to use 8GB/16GB DDR space.
> Then you tell them that they must guaranteed to have some memory below 4GB,
> just only because you think the code as follow:
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> 
> is better than the code like this:
> 
> +#ifdef CONFIG_ARM_LPAE
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> +#endif
> 
> 
> So,I think the following code: 
> +#ifdef CONFIG_ARM_LPAE
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> +#endif
> 
> is better because it's not necessary to ask people to guaranteed to
> have some memory below 4GB on CPU supporting LPAE. 

NAK.

> If we want to ask people to guaranteed to have some memory below 4GB 
> on CPU supporting LPAE, there need to modify some other code.
> I think it makes the simple problem more complex to modify some other code for this.

At this stage, you've proven that you don't understand the problem at hand.

	M.
-- 
Jazz is not dead. It just smells funny...

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Mark Rutland]

On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
> >On Sat, 18 Nov 2017 10:40:08 +0000
> >"Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
> >> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:

> Please don't ask people to limit to 4GB of physical space on CPU
> supporting LPAE, please don't ask people to guaranteed to have some
> memory below 4GB on CPU supporting LPAE.

I don't think that Marc is suggesting that you'd always use the 32-bit
accessors on an LPAE system, just that all the definitions should exist
regardless of configuration.

So rather than this:

> +#ifdef CONFIG_ARM_LPAE
> +#define TTBR0           __ACCESS_CP15_64(0, c2)
> +#define TTBR1           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)
> +#else
> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
> +#endif

... you'd have the following in cp15.h:

#define TTBR0_64	__ACCESS_CP15_64(0, c2)
#define TTBR1_64	__ACCESS_CP15_64(1, c2)
#define PAR_64		__ACCESS_CP15_64(0, c7)

#define TTBR0_32	__ACCESS_CP15(c2, 0, c0, 0)
#define TTBR1_32	__ACCESS_CP15(c2, 0, c0, 1)
#define PAR_32		__ACCESS_CP15(c7, 0, c4, 0)

... and elsewhere, where it matters, we choose which to use depending on
the kernel configuration, e.g.

void set_ttbr0(u64 val)
{
	if (IS_ENABLED(CONFIG_ARM_LPAE))
		write_sysreg(val, TTBR0_64);
	else
		write_sysreg(val, TTBR0_32);
}

Thanks,
Mark.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 22, 2017  20:30  Mark Rutland [mailto:mark.rutland at arm.com] wrote:
>On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
>> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>> >On Sat, 18 Nov 2017 10:40:08 +0000
>> >"Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>> >> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:

>> Please don't ask people to limit to 4GB of physical space on CPU
>> supporting LPAE, please don't ask people to guaranteed to have some
>> memory below 4GB on CPU supporting LPAE.

>I don't think that Marc is suggesting that you'd always use the 32-bit
>accessors on an LPAE system, just that all the definitions should exist
>regardless of configuration.

>So rather than this:

>> +#ifdef CONFIG_ARM_LPAE
>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>> +#define PAR             __ACCESS_CP15_64(0, c7)
>> +#else
>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>> +#endif

>... you'd have the following in cp15.h:

>#define TTBR0_64       __ACCESS_CP15_64(0, c2)
>#define TTBR1_64       __ACCESS_CP15_64(1, c2)
>#define PAR_64         __ACCESS_CP15_64(0, c7)

>#define TTBR0_32       __ACCESS_CP15(c2, 0, c0, 0)
>#define TTBR1_32       __ACCESS_CP15(c2, 0, c0, 1)
>#define PAR_32         __ACCESS_CP15(c7, 0, c4, 0)

>... and elsewhere, where it matters, we choose which to use depending on
>the kernel configuration, e.g.

>void set_ttbr0(u64 val)
>{
>       if (IS_ENABLED(CONFIG_ARM_LPAE))
>               write_sysreg(val, TTBR0_64);
>       else
>               write_sysreg(val, TTBR0_32);
>}

>Thanks,
>Mark.

Thanks for your solution.
I didn't know there was a IS_ENABLED macro that I can use, so I can't write a function 
like:
void set_ttbr0(u64 val)
{
       if (IS_ENABLED(CONFIG_ARM_LPAE))
               write_sysreg(val, TTBR0_64);
       else
               write_sysreg(val, TTBR0_32);
}


Here is the code I tested on vexpress_a9 and vexpress_a15:
diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
index dbdbce1..5eb0185 100644
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_CP15_H

 #include <asm/barrier.h>
+#include <linux/stringify.h>

 /*
  * CR1 bits (CP#15 CR1)
@@ -64,8 +65,93 @@
 #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
 #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)

+#define TTBR0_32           __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1_32           __ACCESS_CP15(c2, 0, c0, 1)
+#define TTBR0_64           __ACCESS_CP15_64(0, c2)
+#define TTBR1_64           __ACCESS_CP15_64(1, c2)
+#define PAR             __ACCESS_CP15_64(0, c7)
+#define VTTBR           __ACCESS_CP15_64(6, c2)
+#define CNTV_CVAL       __ACCESS_CP15_64(3, c14)
+#define CNTVOFF         __ACCESS_CP15_64(4, c14)
+
+#define MIDR            __ACCESS_CP15(c0, 0, c0, 0)
+#define CSSELR          __ACCESS_CP15(c0, 2, c0, 0)
+#define VPIDR           __ACCESS_CP15(c0, 4, c0, 0)
+#define VMPIDR          __ACCESS_CP15(c0, 4, c0, 5)
+#define SCTLR           __ACCESS_CP15(c1, 0, c0, 0)
+#define CPACR           __ACCESS_CP15(c1, 0, c0, 2)
+#define HCR             __ACCESS_CP15(c1, 4, c1, 0)
+#define HDCR            __ACCESS_CP15(c1, 4, c1, 1)
+#define HCPTR           __ACCESS_CP15(c1, 4, c1, 2)
+#define HSTR            __ACCESS_CP15(c1, 4, c1, 3)
+#define TTBCR           __ACCESS_CP15(c2, 0, c0, 2)
+#define HTCR            __ACCESS_CP15(c2, 4, c0, 2)
+#define VTCR            __ACCESS_CP15(c2, 4, c1, 2)
+#define DACR            __ACCESS_CP15(c3, 0, c0, 0)
+#define DFSR            __ACCESS_CP15(c5, 0, c0, 0)
+#define IFSR            __ACCESS_CP15(c5, 0, c0, 1)
+#define ADFSR           __ACCESS_CP15(c5, 0, c1, 0)
+#define AIFSR           __ACCESS_CP15(c5, 0, c1, 1)
+#define HSR             __ACCESS_CP15(c5, 4, c2, 0)
+#define DFAR            __ACCESS_CP15(c6, 0, c0, 0)
+#define IFAR            __ACCESS_CP15(c6, 0, c0, 2)
+#define HDFAR           __ACCESS_CP15(c6, 4, c0, 0)
+#define HIFAR           __ACCESS_CP15(c6, 4, c0, 2)
+#define HPFAR           __ACCESS_CP15(c6, 4, c0, 4)
+#define ICIALLUIS       __ACCESS_CP15(c7, 0, c1, 0)
+#define ATS1CPR         __ACCESS_CP15(c7, 0, c8, 0)
+#define TLBIALLIS       __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL         __ACCESS_CP15(c8, 0, c7, 0)
+#define TLBIALLNSNHIS   __ACCESS_CP15(c8, 4, c3, 4)
+#define PRRR            __ACCESS_CP15(c10, 0, c2, 0)
+#define NMRR            __ACCESS_CP15(c10, 0, c2, 1)
+#define AMAIR0          __ACCESS_CP15(c10, 0, c3, 0)
+#define AMAIR1          __ACCESS_CP15(c10, 0, c3, 1)
+#define VBAR            __ACCESS_CP15(c12, 0, c0, 0)
+#define CID             __ACCESS_CP15(c13, 0, c0, 1)
+#define TID_URW         __ACCESS_CP15(c13, 0, c0, 2)
+#define TID_URO         __ACCESS_CP15(c13, 0, c0, 3)
+#define TID_PRIV        __ACCESS_CP15(c13, 0, c0, 4)
+#define HTPIDR          __ACCESS_CP15(c13, 4, c0, 2)
+#define CNTKCTL         __ACCESS_CP15(c14, 0, c1, 0)
+#define CNTV_CTL        __ACCESS_CP15(c14, 0, c3, 1)
+#define CNTHCTL         __ACCESS_CP15(c14, 4, c1, 0)
+
 extern unsigned long cr_alignment;     /* defined in entry-armv.S */

+
+static inline void set_ttbr0(u64 val)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         write_sysreg(val, TTBR0_64);
+ else
+         write_sysreg(val, TTBR0_32);
+}
+
+static inline u64 get_ttbr0(void)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         return read_sysreg(TTBR0_64);
+ else
+         return (u64)read_sysreg(TTBR0_32);
+}
+
+static inline void set_ttbr1(u64 val)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         write_sysreg(val, TTBR1_64);
+ else
+         write_sysreg(val, TTBR1_32);
+}
+
+static inline u64 get_ttbr1(void)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         return read_sysreg(TTBR1_64);
+ else
+         return (u64)read_sysreg(TTBR1_32);
+}
+
 static inline unsigned long get_cr(void)
 {
        unsigned long val;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 14b5903..8db8a8c 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -37,56 +37,6 @@
        __val;                                                  \
 })

-#define TTBR0              __ACCESS_CP15_64(0, c2)
-#define TTBR1              __ACCESS_CP15_64(1, c2)
-#define VTTBR              __ACCESS_CP15_64(6, c2)
-#define PAR                __ACCESS_CP15_64(0, c7)
-#define CNTV_CVAL  __ACCESS_CP15_64(3, c14)
-#define CNTVOFF            __ACCESS_CP15_64(4, c14)
-
-#define MIDR               __ACCESS_CP15(c0, 0, c0, 0)
-#define CSSELR             __ACCESS_CP15(c0, 2, c0, 0)
-#define VPIDR              __ACCESS_CP15(c0, 4, c0, 0)
-#define VMPIDR             __ACCESS_CP15(c0, 4, c0, 5)
-#define SCTLR              __ACCESS_CP15(c1, 0, c0, 0)
-#define CPACR              __ACCESS_CP15(c1, 0, c0, 2)
-#define HCR                __ACCESS_CP15(c1, 4, c1, 0)
-#define HDCR               __ACCESS_CP15(c1, 4, c1, 1)
-#define HCPTR              __ACCESS_CP15(c1, 4, c1, 2)
-#define HSTR               __ACCESS_CP15(c1, 4, c1, 3)
-#define TTBCR              __ACCESS_CP15(c2, 0, c0, 2)
-#define HTCR               __ACCESS_CP15(c2, 4, c0, 2)
-#define VTCR               __ACCESS_CP15(c2, 4, c1, 2)
-#define DACR               __ACCESS_CP15(c3, 0, c0, 0)
-#define DFSR               __ACCESS_CP15(c5, 0, c0, 0)
-#define IFSR               __ACCESS_CP15(c5, 0, c0, 1)
-#define ADFSR              __ACCESS_CP15(c5, 0, c1, 0)
-#define AIFSR              __ACCESS_CP15(c5, 0, c1, 1)
-#define HSR                __ACCESS_CP15(c5, 4, c2, 0)
-#define DFAR               __ACCESS_CP15(c6, 0, c0, 0)
-#define IFAR               __ACCESS_CP15(c6, 0, c0, 2)
-#define HDFAR              __ACCESS_CP15(c6, 4, c0, 0)
-#define HIFAR              __ACCESS_CP15(c6, 4, c0, 2)
-#define HPFAR              __ACCESS_CP15(c6, 4, c0, 4)
-#define ICIALLUIS  __ACCESS_CP15(c7, 0, c1, 0)
-#define ATS1CPR            __ACCESS_CP15(c7, 0, c8, 0)
-#define TLBIALLIS  __ACCESS_CP15(c8, 0, c3, 0)
-#define TLBIALL            __ACCESS_CP15(c8, 0, c7, 0)
-#define TLBIALLNSNHIS      __ACCESS_CP15(c8, 4, c3, 4)
-#define PRRR               __ACCESS_CP15(c10, 0, c2, 0)
-#define NMRR               __ACCESS_CP15(c10, 0, c2, 1)
-#define AMAIR0             __ACCESS_CP15(c10, 0, c3, 0)
-#define AMAIR1             __ACCESS_CP15(c10, 0, c3, 1)
-#define VBAR               __ACCESS_CP15(c12, 0, c0, 0)
-#define CID                __ACCESS_CP15(c13, 0, c0, 1)
-#define TID_URW            __ACCESS_CP15(c13, 0, c0, 2)
-#define TID_URO            __ACCESS_CP15(c13, 0, c0, 3)
-#define TID_PRIV   __ACCESS_CP15(c13, 0, c0, 4)
-#define HTPIDR             __ACCESS_CP15(c13, 4, c0, 2)
-#define CNTKCTL            __ACCESS_CP15(c14, 0, c1, 0)
-#define CNTV_CTL   __ACCESS_CP15(c14, 0, c3, 1)
-#define CNTHCTL            __ACCESS_CP15(c14, 4, c1, 0)
-
 #define VFP_FPEXC      __ACCESS_VFP(FPEXC)

 /* AArch64 compatibility macros, only for the timer so far */
diff --git a/arch/arm/kvm/hyp/cp15-sr.c b/arch/arm/kvm/hyp/cp15-sr.c
index c478281..d1302ae 100644
--- a/arch/arm/kvm/hyp/cp15-sr.c
+++ b/arch/arm/kvm/hyp/cp15-sr.c
@@ -31,8 +31,8 @@ void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
        ctxt->cp15[c0_CSSELR]           = read_sysreg(CSSELR);
        ctxt->cp15[c1_SCTLR]            = read_sysreg(SCTLR);
        ctxt->cp15[c1_CPACR]            = read_sysreg(CPACR);
-   *cp15_64(ctxt, c2_TTBR0)        = read_sysreg(TTBR0);
-   *cp15_64(ctxt, c2_TTBR1)        = read_sysreg(TTBR1);
+ *cp15_64(ctxt, c2_TTBR0)    = read_sysreg(TTBR0_64);
+ *cp15_64(ctxt, c2_TTBR1)    = read_sysreg(TTBR1_64);
        ctxt->cp15[c2_TTBCR]            = read_sysreg(TTBCR);
        ctxt->cp15[c3_DACR]             = read_sysreg(DACR);
        ctxt->cp15[c5_DFSR]             = read_sysreg(DFSR);
@@ -60,8 +60,8 @@ void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
        write_sysreg(ctxt->cp15[c0_CSSELR],     CSSELR);
        write_sysreg(ctxt->cp15[c1_SCTLR],      SCTLR);
        write_sysreg(ctxt->cp15[c1_CPACR],      CPACR);
-   write_sysreg(*cp15_64(ctxt, c2_TTBR0),  TTBR0);
-   write_sysreg(*cp15_64(ctxt, c2_TTBR1),  TTBR1);
+ write_sysreg(*cp15_64(ctxt, c2_TTBR0),      TTBR0_64);
+ write_sysreg(*cp15_64(ctxt, c2_TTBR1),      TTBR1_64);
        write_sysreg(ctxt->cp15[c2_TTBCR],      TTBCR);
        write_sysreg(ctxt->cp15[c3_DACR],       DACR);
        write_sysreg(ctxt->cp15[c5_DFSR],       DFSR);
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 049ee0a..87c86c7 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -203,16 +203,16 @@ void __init kasan_init(void)
        u64 orig_ttbr0;
        int i;

-   orig_ttbr0 = cpu_get_ttbr(0);
+ orig_ttbr0 = get_ttbr0();

 #ifdef CONFIG_ARM_LPAE
        memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
        set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ set_ttbr0(__pa(tmp_page_table));
 #else
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ set_ttbr0((u64)__pa(tmp_page_table));
 #endif
        flush_cache_all();
        local_flush_bp_all();
@@ -257,7 +257,7 @@ void __init kasan_init(void)
                                 /*__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY))*/
                                __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)));
        memset(kasan_zero_page, 0, PAGE_SIZE);
-   cpu_set_ttbr0(orig_ttbr0);
+ set_ttbr0(orig_ttbr0);
        flush_cache_all();
        local_flush_bp_all();
        local_flush_tlb_all();

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 22/11/17 12:56, Liuwenliang (Abbott Liu) wrote:
> On Nov 22, 2017  20:30  Mark Rutland [mailto:mark.rutland at arm.com] wrote:
>> On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
>>> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>>>> On Sat, 18 Nov 2017 10:40:08 +0000
>>>> "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>>>> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
> 
>>> Please don't ask people to limit to 4GB of physical space on CPU
>>> supporting LPAE, please don't ask people to guaranteed to have some
>>> memory below 4GB on CPU supporting LPAE.
> 
>> I don't think that Marc is suggesting that you'd always use the 32-bit
>> accessors on an LPAE system, just that all the definitions should exist
>> regardless of configuration.
> 
>> So rather than this:
> 
>>> +#ifdef CONFIG_ARM_LPAE
>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>> +#else
>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>> +#endif
> 
>> ... you'd have the following in cp15.h:
> 
>> #define TTBR0_64       __ACCESS_CP15_64(0, c2)
>> #define TTBR1_64       __ACCESS_CP15_64(1, c2)
>> #define PAR_64         __ACCESS_CP15_64(0, c7)
> 
>> #define TTBR0_32       __ACCESS_CP15(c2, 0, c0, 0)
>> #define TTBR1_32       __ACCESS_CP15(c2, 0, c0, 1)
>> #define PAR_32         __ACCESS_CP15(c7, 0, c4, 0)
> 
>> ... and elsewhere, where it matters, we choose which to use depending on
>> the kernel configuration, e.g.
> 
>> void set_ttbr0(u64 val)
>> {
>>       if (IS_ENABLED(CONFIG_ARM_LPAE))
>>               write_sysreg(val, TTBR0_64);
>>       else
>>               write_sysreg(val, TTBR0_32);
>> }
> 
>> Thanks,
>> Mark.
> 
> Thanks for your solution.
> I didn't know there was a IS_ENABLED macro that I can use, so I can't write a function 
> like:
> void set_ttbr0(u64 val)
> {
>        if (IS_ENABLED(CONFIG_ARM_LPAE))
>                write_sysreg(val, TTBR0_64);
>        else
>                write_sysreg(val, TTBR0_32);
> }
> 
> 
> Here is the code I tested on vexpress_a9 and vexpress_a15:
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index dbdbce1..5eb0185 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -2,6 +2,7 @@
>  #define __ASM_ARM_CP15_H
> 
>  #include <asm/barrier.h>
> +#include <linux/stringify.h>
> 
>  /*
>   * CR1 bits (CP#15 CR1)
> @@ -64,8 +65,93 @@
>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
> 
> +#define TTBR0_32           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1_32           __ACCESS_CP15(c2, 0, c0, 1)
> +#define TTBR0_64           __ACCESS_CP15_64(0, c2)
> +#define TTBR1_64           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)

Please define both PAR accessors. Yes, I know the 32bit version is not
used yet, but it doesn't hurt to make it visible.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 23, 2017  20:30  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>Please define both PAR accessors. Yes, I know the 32bit version is not
>used yet, but it doesn't hurt to make it visible.

Thanks for your review.
I'm going to change it in the new version.
Here is the code I tested on vexpress_a9 and vexpress_a15:
diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
index dbdbce1..b8353b1 100644
--- a/arch/arm/include/asm/cp15.h
+++ b/arch/arm/include/asm/cp15.h
@@ -2,6 +2,7 @@
 #define __ASM_ARM_CP15_H

 #include <asm/barrier.h>
+#include <linux/stringify.h>

 /*
  * CR1 bits (CP#15 CR1)
@@ -64,8 +65,109 @@
 #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
 #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)

+#define TTBR0_32     __ACCESS_CP15(c2, 0, c0, 0)
+#define TTBR1_32     __ACCESS_CP15(c2, 0, c0, 1)
+#define PAR_32               __ACCESS_CP15(c7, 0, c4, 0)
+#define TTBR0_64     __ACCESS_CP15_64(0, c2)
+#define TTBR1_64     __ACCESS_CP15_64(1, c2)
+#define PAR_64               __ACCESS_CP15_64(0, c7)
+#define VTTBR           __ACCESS_CP15_64(6, c2)
+#define CNTV_CVAL       __ACCESS_CP15_64(3, c14)
+#define CNTVOFF         __ACCESS_CP15_64(4, c14)
+
+#define MIDR            __ACCESS_CP15(c0, 0, c0, 0)
+#define CSSELR          __ACCESS_CP15(c0, 2, c0, 0)
+#define VPIDR           __ACCESS_CP15(c0, 4, c0, 0)
+#define VMPIDR          __ACCESS_CP15(c0, 4, c0, 5)
+#define SCTLR           __ACCESS_CP15(c1, 0, c0, 0)
+#define CPACR           __ACCESS_CP15(c1, 0, c0, 2)
+#define HCR             __ACCESS_CP15(c1, 4, c1, 0)
+#define HDCR            __ACCESS_CP15(c1, 4, c1, 1)
+#define HCPTR           __ACCESS_CP15(c1, 4, c1, 2)
+#define HSTR            __ACCESS_CP15(c1, 4, c1, 3)
+#define TTBCR           __ACCESS_CP15(c2, 0, c0, 2)
+#define HTCR            __ACCESS_CP15(c2, 4, c0, 2)
+#define VTCR            __ACCESS_CP15(c2, 4, c1, 2)
+#define DACR            __ACCESS_CP15(c3, 0, c0, 0)
+#define DFSR            __ACCESS_CP15(c5, 0, c0, 0)
+#define IFSR            __ACCESS_CP15(c5, 0, c0, 1)
+#define ADFSR           __ACCESS_CP15(c5, 0, c1, 0)
+#define AIFSR           __ACCESS_CP15(c5, 0, c1, 1)
+#define HSR             __ACCESS_CP15(c5, 4, c2, 0)
+#define DFAR            __ACCESS_CP15(c6, 0, c0, 0)
+#define IFAR            __ACCESS_CP15(c6, 0, c0, 2)
+#define HDFAR           __ACCESS_CP15(c6, 4, c0, 0)
+#define HIFAR           __ACCESS_CP15(c6, 4, c0, 2)
+#define HPFAR           __ACCESS_CP15(c6, 4, c0, 4)
+#define ICIALLUIS       __ACCESS_CP15(c7, 0, c1, 0)
+#define ATS1CPR         __ACCESS_CP15(c7, 0, c8, 0)
+#define TLBIALLIS       __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL         __ACCESS_CP15(c8, 0, c7, 0)
+#define TLBIALLNSNHIS   __ACCESS_CP15(c8, 4, c3, 4)
+#define PRRR            __ACCESS_CP15(c10, 0, c2, 0)
+#define NMRR            __ACCESS_CP15(c10, 0, c2, 1)
+#define AMAIR0          __ACCESS_CP15(c10, 0, c3, 0)
+#define AMAIR1          __ACCESS_CP15(c10, 0, c3, 1)
+#define VBAR            __ACCESS_CP15(c12, 0, c0, 0)
+#define CID             __ACCESS_CP15(c13, 0, c0, 1)
+#define TID_URW         __ACCESS_CP15(c13, 0, c0, 2)
+#define TID_URO         __ACCESS_CP15(c13, 0, c0, 3)
+#define TID_PRIV        __ACCESS_CP15(c13, 0, c0, 4)
+#define HTPIDR          __ACCESS_CP15(c13, 4, c0, 2)
+#define CNTKCTL         __ACCESS_CP15(c14, 0, c1, 0)
+#define CNTV_CTL        __ACCESS_CP15(c14, 0, c3, 1)
+#define CNTHCTL         __ACCESS_CP15(c14, 4, c1, 0)
+
 extern unsigned long cr_alignment;     /* defined in entry-armv.S */

+static inline void set_par(u64 val)
+{
+        if (IS_ENABLED(CONFIG_ARM_LPAE))
+                write_sysreg(val, PAR_64);
+        else
+                write_sysreg(val, PAR_32);
+}
+
+static inline u64 get_par(void)
+{
+        if (IS_ENABLED(CONFIG_ARM_LPAE))
+                return read_sysreg(PAR_64);
+        else
+                return (u64)read_sysreg(PAR_32);
+}
+
+static inline void set_ttbr0(u64 val)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         write_sysreg(val, TTBR0_64);
+ else
+         write_sysreg(val, TTBR0_32);
+}
+
+static inline u64 get_ttbr0(void)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         return read_sysreg(TTBR0_64);
+ else
+         return (u64)read_sysreg(TTBR0_32);
+}
+
+static inline void set_ttbr1(u64 val)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         write_sysreg(val, TTBR1_64);
+ else
+         write_sysreg(val, TTBR1_32);
+}
+
+static inline u64 get_ttbr1(void)
+{
+ if (IS_ENABLED(CONFIG_ARM_LPAE))
+         return read_sysreg(TTBR1_64);
+ else
+         return (u64)read_sysreg(TTBR1_32);
+}
+
 static inline unsigned long get_cr(void)
 {
        unsigned long val;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 14b5903..8db8a8c 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -37,56 +37,6 @@
        __val;                                                  \
 })

-#define TTBR0              __ACCESS_CP15_64(0, c2)
-#define TTBR1              __ACCESS_CP15_64(1, c2)
-#define VTTBR              __ACCESS_CP15_64(6, c2)
-#define PAR                __ACCESS_CP15_64(0, c7)
-#define CNTV_CVAL  __ACCESS_CP15_64(3, c14)
-#define CNTVOFF            __ACCESS_CP15_64(4, c14)
-
-#define MIDR               __ACCESS_CP15(c0, 0, c0, 0)
-#define CSSELR             __ACCESS_CP15(c0, 2, c0, 0)
-#define VPIDR              __ACCESS_CP15(c0, 4, c0, 0)
-#define VMPIDR             __ACCESS_CP15(c0, 4, c0, 5)
-#define SCTLR              __ACCESS_CP15(c1, 0, c0, 0)
-#define CPACR              __ACCESS_CP15(c1, 0, c0, 2)
-#define HCR                __ACCESS_CP15(c1, 4, c1, 0)
-#define HDCR               __ACCESS_CP15(c1, 4, c1, 1)
-#define HCPTR              __ACCESS_CP15(c1, 4, c1, 2)
-#define HSTR               __ACCESS_CP15(c1, 4, c1, 3)
-#define TTBCR              __ACCESS_CP15(c2, 0, c0, 2)
-#define HTCR               __ACCESS_CP15(c2, 4, c0, 2)
-#define VTCR               __ACCESS_CP15(c2, 4, c1, 2)
-#define DACR               __ACCESS_CP15(c3, 0, c0, 0)
-#define DFSR               __ACCESS_CP15(c5, 0, c0, 0)
-#define IFSR               __ACCESS_CP15(c5, 0, c0, 1)
-#define ADFSR              __ACCESS_CP15(c5, 0, c1, 0)
-#define AIFSR              __ACCESS_CP15(c5, 0, c1, 1)
-#define HSR                __ACCESS_CP15(c5, 4, c2, 0)
-#define DFAR               __ACCESS_CP15(c6, 0, c0, 0)
-#define IFAR               __ACCESS_CP15(c6, 0, c0, 2)
-#define HDFAR              __ACCESS_CP15(c6, 4, c0, 0)
-#define HIFAR              __ACCESS_CP15(c6, 4, c0, 2)
-#define HPFAR              __ACCESS_CP15(c6, 4, c0, 4)
-#define ICIALLUIS  __ACCESS_CP15(c7, 0, c1, 0)
-#define ATS1CPR            __ACCESS_CP15(c7, 0, c8, 0)
-#define TLBIALLIS  __ACCESS_CP15(c8, 0, c3, 0)
-#define TLBIALL            __ACCESS_CP15(c8, 0, c7, 0)
-#define TLBIALLNSNHIS      __ACCESS_CP15(c8, 4, c3, 4)
-#define PRRR               __ACCESS_CP15(c10, 0, c2, 0)
-#define NMRR               __ACCESS_CP15(c10, 0, c2, 1)
-#define AMAIR0             __ACCESS_CP15(c10, 0, c3, 0)
-#define AMAIR1             __ACCESS_CP15(c10, 0, c3, 1)
-#define VBAR               __ACCESS_CP15(c12, 0, c0, 0)
-#define CID                __ACCESS_CP15(c13, 0, c0, 1)
-#define TID_URW            __ACCESS_CP15(c13, 0, c0, 2)
-#define TID_URO            __ACCESS_CP15(c13, 0, c0, 3)
-#define TID_PRIV   __ACCESS_CP15(c13, 0, c0, 4)
-#define HTPIDR             __ACCESS_CP15(c13, 4, c0, 2)
-#define CNTKCTL            __ACCESS_CP15(c14, 0, c1, 0)
-#define CNTV_CTL   __ACCESS_CP15(c14, 0, c3, 1)
-#define CNTHCTL            __ACCESS_CP15(c14, 4, c1, 0)
-
 #define VFP_FPEXC      __ACCESS_VFP(FPEXC)

 /* AArch64 compatibility macros, only for the timer so far */
diff --git a/arch/arm/kvm/hyp/cp15-sr.c b/arch/arm/kvm/hyp/cp15-sr.c
index c478281..d365e3c 100644
--- a/arch/arm/kvm/hyp/cp15-sr.c
+++ b/arch/arm/kvm/hyp/cp15-sr.c
@@ -31,8 +31,8 @@ void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
        ctxt->cp15[c0_CSSELR]           = read_sysreg(CSSELR);
        ctxt->cp15[c1_SCTLR]            = read_sysreg(SCTLR);
        ctxt->cp15[c1_CPACR]            = read_sysreg(CPACR);
-   *cp15_64(ctxt, c2_TTBR0)        = read_sysreg(TTBR0);
-   *cp15_64(ctxt, c2_TTBR1)        = read_sysreg(TTBR1);
+ *cp15_64(ctxt, c2_TTBR0)    = read_sysreg(TTBR0_64);
+ *cp15_64(ctxt, c2_TTBR1)    = read_sysreg(TTBR1_64);
        ctxt->cp15[c2_TTBCR]            = read_sysreg(TTBCR);
        ctxt->cp15[c3_DACR]             = read_sysreg(DACR);
        ctxt->cp15[c5_DFSR]             = read_sysreg(DFSR);
@@ -41,7 +41,7 @@ void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
        ctxt->cp15[c5_AIFSR]            = read_sysreg(AIFSR);
        ctxt->cp15[c6_DFAR]             = read_sysreg(DFAR);
        ctxt->cp15[c6_IFAR]             = read_sysreg(IFAR);
-   *cp15_64(ctxt, c7_PAR)          = read_sysreg(PAR);
+ *cp15_64(ctxt, c7_PAR)              = read_sysreg(PAR_64);
        ctxt->cp15[c10_PRRR]            = read_sysreg(PRRR);
        ctxt->cp15[c10_NMRR]            = read_sysreg(NMRR);
        ctxt->cp15[c10_AMAIR0]          = read_sysreg(AMAIR0);
@@ -60,8 +60,8 @@ void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
        write_sysreg(ctxt->cp15[c0_CSSELR],     CSSELR);
        write_sysreg(ctxt->cp15[c1_SCTLR],      SCTLR);
        write_sysreg(ctxt->cp15[c1_CPACR],      CPACR);
-   write_sysreg(*cp15_64(ctxt, c2_TTBR0),  TTBR0);
-   write_sysreg(*cp15_64(ctxt, c2_TTBR1),  TTBR1);
+ write_sysreg(*cp15_64(ctxt, c2_TTBR0),      TTBR0_64);
+ write_sysreg(*cp15_64(ctxt, c2_TTBR1),      TTBR1_64);
        write_sysreg(ctxt->cp15[c2_TTBCR],      TTBCR);
        write_sysreg(ctxt->cp15[c3_DACR],       DACR);
        write_sysreg(ctxt->cp15[c5_DFSR],       DFSR);
@@ -70,7 +70,7 @@ void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
        write_sysreg(ctxt->cp15[c5_AIFSR],      AIFSR);
        write_sysreg(ctxt->cp15[c6_DFAR],       DFAR);
        write_sysreg(ctxt->cp15[c6_IFAR],       IFAR);
-   write_sysreg(*cp15_64(ctxt, c7_PAR),    PAR);
+ write_sysreg(*cp15_64(ctxt, c7_PAR),        PAR_64);
        write_sysreg(ctxt->cp15[c10_PRRR],      PRRR);
        write_sysreg(ctxt->cp15[c10_NMRR],      NMRR);
        write_sysreg(ctxt->cp15[c10_AMAIR0],    AMAIR0);
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index ebd2dd4..4879588 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -133,12 +133,12 @@ static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
        if (!(hsr & HSR_DABT_S1PTW) && (hsr & HSR_FSC_TYPE) == FSC_PERM) {
                u64 par, tmp;

-           par = read_sysreg(PAR);
+         par = read_sysreg(PAR_64);
                write_sysreg(far, ATS1CPR);
                isb();

-           tmp = read_sysreg(PAR);
-           write_sysreg(par, PAR);
+         tmp = read_sysreg(PAR_64);
+         write_sysreg(par, PAR_64);

                if (unlikely(tmp & 1))
                        return false; /* Translation failed, back to guest */
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 049ee0a..87c86c7 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -203,16 +203,16 @@ void __init kasan_init(void)
        u64 orig_ttbr0;
        int i;

-   orig_ttbr0 = cpu_get_ttbr(0);
+ orig_ttbr0 = get_ttbr0();

 #ifdef CONFIG_ARM_LPAE
        memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
        set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ set_ttbr0(__pa(tmp_page_table));
 #else
        memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
-   cpu_set_ttbr0(__pa(tmp_page_table));
+ set_ttbr0((u64)__pa(tmp_page_table));
 #endif
        flush_cache_all();
        local_flush_bp_all();
@@ -257,7 +257,7 @@ void __init kasan_init(void)
                                 /*__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY))*/
                                __pgprot(pgprot_val(PAGE_KERNEL) | L_PTE_RDONLY)));
        memset(kasan_zero_page, 0, PAGE_SIZE);
-   cpu_set_ttbr0(orig_ttbr0);
+ set_ttbr0(orig_ttbr0);
        flush_cache_all();
        local_flush_bp_all();
        local_flush_tlb_all();



-----????-----
???: Marc Zyngier [mailto:marc.zyngier at arm.com] 
????: 2017?11?22? 21:06
???: Liuwenliang (Abbott Liu); Mark Rutland
??: tixy at linaro.org; mhocko at suse.com; grygorii.strashko at linaro.org; catalin.marinas at arm.com; linux-mm at kvack.org; glider at google.com; afzal.mohd.ma at gmail.com; mingo at kernel.org; Christoffer Dall; f.fainelli at gmail.com; mawilcox at microsoft.com; linux at armlinux.org.uk; kasan-dev at googlegroups.com; Dailei; linux-arm-kernel at lists.infradead.org; aryabinin at virtuozzo.com; labbott at redhat.com; vladimir.murzin at arm.com; keescook at chromium.org; arnd at arndb.de; Zengweilin; opendmb at gmail.com; Heshaoliang; tglx at linutronix.de; dvyukov at google.com; ard.biesheuvel at linaro.org; linux-kernel at vger.kernel.org; Jiazhenghua; akpm at linux-foundation.org; robin.murphy at arm.com; thgarnie at google.com; kirill.shutemov at linux.intel.com
??: Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On 22/11/17 12:56, Liuwenliang (Abbott Liu) wrote:
> On Nov 22, 2017  20:30  Mark Rutland [mailto:mark.rutland at arm.com] wrote:
>> On Tue, Nov 21, 2017 at 07:59:01AM +0000, Liuwenliang (Abbott Liu) wrote:
>>> On Nov 17, 2017  21:49  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
>>>> On Sat, 18 Nov 2017 10:40:08 +0000
>>>> "Liuwenliang (Abbott Liu)" <liuwenliang@huawei.com> wrote:
>>>>> On Nov 17, 2017  15:36 Christoffer Dall [mailto:cdall at linaro.org]  wrote:
> 
>>> Please don't ask people to limit to 4GB of physical space on CPU
>>> supporting LPAE, please don't ask people to guaranteed to have some
>>> memory below 4GB on CPU supporting LPAE.
> 
>> I don't think that Marc is suggesting that you'd always use the 32-bit
>> accessors on an LPAE system, just that all the definitions should exist
>> regardless of configuration.
> 
>> So rather than this:
> 
>>> +#ifdef CONFIG_ARM_LPAE
>>> +#define TTBR0           __ACCESS_CP15_64(0, c2)
>>> +#define TTBR1           __ACCESS_CP15_64(1, c2)
>>> +#define PAR             __ACCESS_CP15_64(0, c7)
>>> +#else
>>> +#define TTBR0           __ACCESS_CP15(c2, 0, c0, 0)
>>> +#define TTBR1           __ACCESS_CP15(c2, 0, c0, 1)
>>> +#define PAR             __ACCESS_CP15(c7, 0, c4, 0)
>>> +#endif
> 
>> ... you'd have the following in cp15.h:
> 
>> #define TTBR0_64       __ACCESS_CP15_64(0, c2)
>> #define TTBR1_64       __ACCESS_CP15_64(1, c2)
>> #define PAR_64         __ACCESS_CP15_64(0, c7)
> 
>> #define TTBR0_32       __ACCESS_CP15(c2, 0, c0, 0)
>> #define TTBR1_32       __ACCESS_CP15(c2, 0, c0, 1)
>> #define PAR_32         __ACCESS_CP15(c7, 0, c4, 0)
> 
>> ... and elsewhere, where it matters, we choose which to use depending on
>> the kernel configuration, e.g.
> 
>> void set_ttbr0(u64 val)
>> {
>>       if (IS_ENABLED(CONFIG_ARM_LPAE))
>>               write_sysreg(val, TTBR0_64);
>>       else
>>               write_sysreg(val, TTBR0_32);
>> }
> 
>> Thanks,
>> Mark.
> 
> Thanks for your solution.
> I didn't know there was a IS_ENABLED macro that I can use, so I can't write a function 
> like:
> void set_ttbr0(u64 val)
> {
>        if (IS_ENABLED(CONFIG_ARM_LPAE))
>                write_sysreg(val, TTBR0_64);
>        else
>                write_sysreg(val, TTBR0_32);
> }
> 
> 
> Here is the code I tested on vexpress_a9 and vexpress_a15:
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index dbdbce1..5eb0185 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -2,6 +2,7 @@
>  #define __ASM_ARM_CP15_H
> 
>  #include <asm/barrier.h>
> +#include <linux/stringify.h>
> 
>  /*
>   * CR1 bits (CP#15 CR1)
> @@ -64,8 +65,93 @@
>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
> 
> +#define TTBR0_32           __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1_32           __ACCESS_CP15(c2, 0, c0, 1)
> +#define TTBR0_64           __ACCESS_CP15_64(0, c2)
> +#define TTBR1_64           __ACCESS_CP15_64(1, c2)
> +#define PAR             __ACCESS_CP15_64(0, c7)

Please define both PAR accessors. Yes, I know the 32bit version is not
used yet, but it doesn't hurt to make it visible.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Thu, Nov 23, 2017 at 01:54:59AM +0000, Liuwenliang (Abbott Liu) wrote:
> On Nov 23, 2017  20:30  Marc Zyngier [mailto:marc.zyngier at arm.com]  wrote:
> >Please define both PAR accessors. Yes, I know the 32bit version is not
> >used yet, but it doesn't hurt to make it visible.
> 
> Thanks for your review.
> I'm going to change it in the new version.
> Here is the code I tested on vexpress_a9 and vexpress_a15:
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index dbdbce1..b8353b1 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -2,6 +2,7 @@
>  #define __ASM_ARM_CP15_H
> 
>  #include <asm/barrier.h>
> +#include <linux/stringify.h>
> 
>  /*
>   * CR1 bits (CP#15 CR1)
> @@ -64,8 +65,109 @@
>  #define __write_sysreg(v, r, w, c, t)  asm volatile(w " " c : : "r" ((t)(v)))
>  #define write_sysreg(v, ...)           __write_sysreg(v, __VA_ARGS__)
> 
> +#define TTBR0_32     __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1_32     __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR_32               __ACCESS_CP15(c7, 0, c4, 0)
> +#define TTBR0_64     __ACCESS_CP15_64(0, c2)
> +#define TTBR1_64     __ACCESS_CP15_64(1, c2)
> +#define PAR_64               __ACCESS_CP15_64(0, c7)
> +#define VTTBR           __ACCESS_CP15_64(6, c2)
> +#define CNTV_CVAL       __ACCESS_CP15_64(3, c14)
> +#define CNTVOFF         __ACCESS_CP15_64(4, c14)
> +
> +#define MIDR            __ACCESS_CP15(c0, 0, c0, 0)
> +#define CSSELR          __ACCESS_CP15(c0, 2, c0, 0)
> +#define VPIDR           __ACCESS_CP15(c0, 4, c0, 0)
> +#define VMPIDR          __ACCESS_CP15(c0, 4, c0, 5)
> +#define SCTLR           __ACCESS_CP15(c1, 0, c0, 0)
> +#define CPACR           __ACCESS_CP15(c1, 0, c0, 2)
> +#define HCR             __ACCESS_CP15(c1, 4, c1, 0)
> +#define HDCR            __ACCESS_CP15(c1, 4, c1, 1)
> +#define HCPTR           __ACCESS_CP15(c1, 4, c1, 2)
> +#define HSTR            __ACCESS_CP15(c1, 4, c1, 3)
> +#define TTBCR           __ACCESS_CP15(c2, 0, c0, 2)
> +#define HTCR            __ACCESS_CP15(c2, 4, c0, 2)
> +#define VTCR            __ACCESS_CP15(c2, 4, c1, 2)
> +#define DACR            __ACCESS_CP15(c3, 0, c0, 0)
> +#define DFSR            __ACCESS_CP15(c5, 0, c0, 0)
> +#define IFSR            __ACCESS_CP15(c5, 0, c0, 1)
> +#define ADFSR           __ACCESS_CP15(c5, 0, c1, 0)
> +#define AIFSR           __ACCESS_CP15(c5, 0, c1, 1)
> +#define HSR             __ACCESS_CP15(c5, 4, c2, 0)
> +#define DFAR            __ACCESS_CP15(c6, 0, c0, 0)
> +#define IFAR            __ACCESS_CP15(c6, 0, c0, 2)
> +#define HDFAR           __ACCESS_CP15(c6, 4, c0, 0)
> +#define HIFAR           __ACCESS_CP15(c6, 4, c0, 2)
> +#define HPFAR           __ACCESS_CP15(c6, 4, c0, 4)
> +#define ICIALLUIS       __ACCESS_CP15(c7, 0, c1, 0)
> +#define ATS1CPR         __ACCESS_CP15(c7, 0, c8, 0)
> +#define TLBIALLIS       __ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL         __ACCESS_CP15(c8, 0, c7, 0)
> +#define TLBIALLNSNHIS   __ACCESS_CP15(c8, 4, c3, 4)
> +#define PRRR            __ACCESS_CP15(c10, 0, c2, 0)
> +#define NMRR            __ACCESS_CP15(c10, 0, c2, 1)
> +#define AMAIR0          __ACCESS_CP15(c10, 0, c3, 0)
> +#define AMAIR1          __ACCESS_CP15(c10, 0, c3, 1)
> +#define VBAR            __ACCESS_CP15(c12, 0, c0, 0)
> +#define CID             __ACCESS_CP15(c13, 0, c0, 1)
> +#define TID_URW         __ACCESS_CP15(c13, 0, c0, 2)
> +#define TID_URO         __ACCESS_CP15(c13, 0, c0, 3)
> +#define TID_PRIV        __ACCESS_CP15(c13, 0, c0, 4)
> +#define HTPIDR          __ACCESS_CP15(c13, 4, c0, 2)
> +#define CNTKCTL         __ACCESS_CP15(c14, 0, c1, 0)
> +#define CNTV_CTL        __ACCESS_CP15(c14, 0, c3, 1)
> +#define CNTHCTL         __ACCESS_CP15(c14, 4, c1, 0)
> +
>  extern unsigned long cr_alignment;     /* defined in entry-armv.S */
> 
> +static inline void set_par(u64 val)
> +{
> +        if (IS_ENABLED(CONFIG_ARM_LPAE))
> +                write_sysreg(val, PAR_64);
> +        else
> +                write_sysreg(val, PAR_32);
> +}
> +
> +static inline u64 get_par(void)
> +{
> +        if (IS_ENABLED(CONFIG_ARM_LPAE))
> +                return read_sysreg(PAR_64);
> +        else
> +                return (u64)read_sysreg(PAR_32);
> +}
> +
> +static inline void set_ttbr0(u64 val)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         write_sysreg(val, TTBR0_64);
> + else
> +         write_sysreg(val, TTBR0_32);
> +}
> +
> +static inline u64 get_ttbr0(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR0_64);
> + else
> +         return (u64)read_sysreg(TTBR0_32);
> +}
> +
> +static inline void set_ttbr1(u64 val)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         write_sysreg(val, TTBR1_64);
> + else
> +         write_sysreg(val, TTBR1_32);
> +}
> +
> +static inline u64 get_ttbr1(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR1_64);
> + else
> +         return (u64)read_sysreg(TTBR1_32);
> +}
> +

Please pay attention to the project coding style whenever creating code
for a program.  It doesn't matter what the project coding style is, as
long as you write your code to match the style that is already there.

For the kernel, that is: tabs not spaces for indentation of code.
You seem to be using a variable number of spaces for all the new code
above.

Some of it seems to be your email client thinking it knows better about
white space - and such behaviours basically makes patches unapplyable.
See Documentation/process/email-clients.rst for hints about email
clients.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 23, 2017  23:22  Russell King - ARM Linux [mailto:linux at armlinux.org.uk]  wrote:
>Please pay attention to the project coding style whenever creating code
>for a program.  It doesn't matter what the project coding style is, as
>long as you write your code to match the style that is already there.
>
>For the kernel, that is: tabs not spaces for indentation of code.
>You seem to be using a variable number of spaces for all the new code
>above.
>
>Some of it seems to be your email client thinking it knows better about
>white space - and such behaviours basically makes patches unapplyable.
>See Documentation/process/email-clients.rst for hints about email
>clients.
Thanks for your review.
I'm going to change it in the new version.  

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Mark Rutland]

On Wed, Nov 22, 2017 at 12:56:44PM +0000, Liuwenliang (Abbott Liu) wrote:
> +static inline u64 get_ttbr0(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR0_64);
> + else
> +         return (u64)read_sysreg(TTBR0_32);
> +}

> +static inline u64 get_ttbr1(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR1_64);
> + else
> +         return (u64)read_sysreg(TTBR1_32);
> +}

In addition to the whitespace damage that need to be fixed, there's no
need for the u64 casts here. The compiler will implicitly cast to the
return type, and as u32 and u64 are both arithmetic types, we don't need
an explicit cast here.

Thanks,
Mark.

答复: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Nov 23, 2017  23:32  Mark Rutland [mailto:mark.rutland at arm.com] wrote:
>On Wed, Nov 22, 2017 at 12:56:44PM +0000, Liuwenliang (Abbott Liu) wrote:
>> +static inline u64 get_ttbr0(void)
>> +{
>> + if (IS_ENABLED(CONFIG_ARM_LPAE))
>> +         return read_sysreg(TTBR0_64);
>> + else
>> +         return (u64)read_sysreg(TTBR0_32);
>> +}
>
>> +static inline u64 get_ttbr1(void)
>> +{
>> + if (IS_ENABLED(CONFIG_ARM_LPAE))
>> +         return read_sysreg(TTBR1_64);
>> + else
>> +         return (u64)read_sysreg(TTBR1_32);
>> +}
>
>In addition to the whitespace damage that need to be fixed, there's no
>need for the u64 casts here. The compiler will implicitly cast to the
>return type, and as u32 and u64 are both arithmetic types, we don't need
>an explicit cast here.

Thanks for your review.
I'm going to change it in the new version.  


-----????-----
???: Mark Rutland [mailto:mark.rutland at arm.com] 
????: 2017?11?23? 23:32
???: Liuwenliang (Abbott Liu)
??: Marc Zyngier; tixy at linaro.org; mhocko at suse.com; grygorii.strashko at linaro.org; catalin.marinas at arm.com; linux-mm at kvack.org; glider at google.com; afzal.mohd.ma at gmail.com; mingo at kernel.org; Christoffer Dall; f.fainelli at gmail.com; mawilcox at microsoft.com; linux at armlinux.org.uk; kasan-dev at googlegroups.com; Dailei; linux-arm-kernel at lists.infradead.org; aryabinin at virtuozzo.com; labbott at redhat.com; vladimir.murzin at arm.com; keescook at chromium.org; arnd at arndb.de; Zengweilin; opendmb at gmail.com; Heshaoliang; tglx at linutronix.de; dvyukov at google.com; ard.biesheuvel at linaro.org; linux-kernel at vger.kernel.org; Jiazhenghua; akpm at linux-foundation.org; robin.murphy at arm.com; thgarnie at google.com; kirill.shutemov at linux.intel.com
??: Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

On Wed, Nov 22, 2017 at 12:56:44PM +0000, Liuwenliang (Abbott Liu) wrote:
> +static inline u64 get_ttbr0(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR0_64);
> + else
> +         return (u64)read_sysreg(TTBR0_32);
> +}

> +static inline u64 get_ttbr1(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM_LPAE))
> +         return read_sysreg(TTBR1_64);
> + else
> +         return (u64)read_sysreg(TTBR1_32);
> +}

In addition to the whitespace damage that need to be fixed, there's no
need for the u64 casts here. The compiler will implicitly cast to the
return type, and as u32 and u64 are both arithmetic types, we don't need
an explicit cast here.

Thanks,
Mark.

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 04:22:17PM +0800, Abbott Liu wrote:
> diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
> index b2902a5..10cee6a 100644
> --- a/arch/arm/include/asm/pgalloc.h
> +++ b/arch/arm/include/asm/pgalloc.h
> @@ -50,8 +50,11 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
>   */
>  #define pmd_alloc_one(mm,addr)		({ BUG(); ((pmd_t *)2); })
>  #define pmd_free(mm, pmd)		do { } while (0)
> +#ifndef CONFIG_KASAN
>  #define pud_populate(mm,pmd,pte)	BUG()
> -
> +#else
> +#define pud_populate(mm,pmd,pte)	do { } while (0)
> +#endif

Please explain this change - we don't have a "pud" as far as the rest of
the Linux MM layer is concerned, so why do we need it for kasan?

I suspect it comes from the way we wrap up the page tables - where ARM
does it one way (because it has to) vs the subsequently merged method
which is completely upside down to what ARMs doing, and therefore is
totally incompatible and impossible to fit in with our way.

> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> index f2e1af4..6e26714 100644
> --- a/arch/arm/include/asm/proc-fns.h
> +++ b/arch/arm/include/asm/proc-fns.h
> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>  		pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);	\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcrr	p15, 0, %Q0, %R0, c2"		\
> +			: : "r" (ttbr));	\
> +	} while (0)
> +
> +
>  #else
>  #define cpu_get_pgd()	\
>  	({						\
> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>  		pg &= ~0x3fff;				\
>  		(pgd_t *)phys_to_virt(pg);		\
>  	})
> +
> +#define cpu_set_ttbr(nr, val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +#define cpu_get_ttbr(nr)					\
> +	({							\
> +		unsigned long ttbr;				\
> +		__asm__("mrc	p15, 0, %0, c2, c0, 0"		\
> +			: "=r" (ttbr));				\
> +		ttbr;						\
> +	})
> +
> +#define cpu_set_ttbr0(val)					\
> +	do {							\
> +		u64 ttbr = val;					\
> +		__asm__("mcr	p15, 0, %0, c2, c0, 0"		\
> +			: : "r" (ttbr));			\
> +	} while (0)
> +
> +
>  #endif
>  
>  #else	/*!CONFIG_MMU */
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 1d468b5..52c4858 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -16,7 +16,11 @@
>  #include <asm/fpstate.h>
>  #include <asm/page.h>
>  
> +#ifdef CONFIG_KASAN
> +#define THREAD_SIZE_ORDER       2
> +#else
>  #define THREAD_SIZE_ORDER	1
> +#endif
>  #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
>  #define THREAD_START_SP		(THREAD_SIZE - 8)
>  
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 8733012..c17f4a2 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -101,7 +101,11 @@ __mmap_switched:
>  	str	r2, [r6]			@ Save atags pointer
>  	cmp	r7, #0
>  	strne	r0, [r7]			@ Save control register values
> +#ifdef CONFIG_KASAN
> +	b	kasan_early_init
> +#else
>  	b	start_kernel
> +#endif
>  ENDPROC(__mmap_switched)
>  
>  	.align	2
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8e9a3e4..985d9a3 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -62,6 +62,7 @@
>  #include <asm/unwind.h>
>  #include <asm/memblock.h>
>  #include <asm/virt.h>
> +#include <asm/kasan.h>
>  
>  #include "atags.h"
>  
> @@ -1108,6 +1109,7 @@ void __init setup_arch(char **cmdline_p)
>  	early_ioremap_reset();
>  
>  	paging_init(mdesc);
> +	kasan_init();
>  	request_standard_resources(mdesc);
>  
>  	if (mdesc->restart)
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index 950d19b..498c316 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -106,4 +106,9 @@ obj-$(CONFIG_CACHE_L2X0)	+= cache-l2x0.o l2c-l2x0-resume.o
>  obj-$(CONFIG_CACHE_L2X0_PMU)	+= cache-l2x0-pmu.o
>  obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
>  obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
> +
> +KASAN_SANITIZE_kasan_init.o    := n
> +obj-$(CONFIG_KASAN)            += kasan_init.o

Why is this placed in the middle of the cache object listing?

> +
> +
>  obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> new file mode 100644
> index 0000000..2bf0782
> --- /dev/null
> +++ b/arch/arm/mm/kasan_init.c
> @@ -0,0 +1,257 @@
> +#include <linux/bootmem.h>
> +#include <linux/kasan.h>
> +#include <linux/kernel.h>
> +#include <linux/memblock.h>
> +#include <linux/start_kernel.h>
> +
> +#include <asm/cputype.h>
> +#include <asm/highmem.h>
> +#include <asm/mach/map.h>
> +#include <asm/memory.h>
> +#include <asm/page.h>
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +#include <asm/procinfo.h>
> +#include <asm/proc-fns.h>
> +#include <asm/tlbflush.h>
> +#include <asm/cp15.h>
> +#include <linux/sched/task.h>
> +
> +#include "mm.h"
> +
> +static pgd_t tmp_page_table[PTRS_PER_PGD] __initdata __aligned(1ULL << 14);
> +
> +pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
> +
> +static __init void *kasan_alloc_block(size_t size, int node)
> +{
> +	return memblock_virt_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
> +					BOOTMEM_ALLOC_ACCESSIBLE, node);
> +}
> +
> +static void __init kasan_early_pmd_populate(unsigned long start, unsigned long end, pud_t *pud)
> +{
> +	unsigned long addr;
> +	unsigned long next;
> +	pmd_t *pmd;
> +
> +	pmd = pmd_offset(pud, start);
> +	for (addr = start; addr < end;) {
> +		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
> +		next = pmd_addr_end(addr, end);
> +		addr = next;
> +		flush_pmd_entry(pmd);
> +		pmd++;
> +	}
> +}
> +
> +static void __init kasan_early_pud_populate(unsigned long start, unsigned long end, pgd_t *pgd)
> +{
> +	unsigned long addr;
> +	unsigned long next;
> +	pud_t *pud;
> +
> +	pud = pud_offset(pgd, start);
> +	for (addr = start; addr < end;) {
> +		next = pud_addr_end(addr, end);
> +		kasan_early_pmd_populate(addr, next, pud);
> +		addr = next;
> +		pud++;
> +	}
> +}
> +
> +void __init kasan_map_early_shadow(pgd_t *pgdp)
> +{
> +	int i;
> +	unsigned long start = KASAN_SHADOW_START;
> +	unsigned long end = KASAN_SHADOW_END;
> +	unsigned long addr;
> +	unsigned long next;
> +	pgd_t *pgd;
> +
> +	for (i = 0; i < PTRS_PER_PTE; i++)
> +		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
> +			&kasan_zero_pte[i], pfn_pte(
> +				virt_to_pfn(kasan_zero_page),
> +				__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN)));
> +
> +	pgd = pgd_offset_k(start);
> +	for (addr = start; addr < end;) {
> +		next = pgd_addr_end(addr, end);
> +		kasan_early_pud_populate(addr, next, pgd);
> +		addr = next;
> +		pgd++;
> +	}
> +}
> +
> +extern struct proc_info_list *lookup_processor_type(unsigned int);
> +
> +void __init kasan_early_init(void)
> +{
> +	struct proc_info_list *list;
> +
> +	/*
> +	 * locate processor in the list of supported processor
> +	 * types.  The linker builds this table for us from the
> +	 * entries in arch/arm/mm/proc-*.S
> +	 */
> +	list = lookup_processor_type(read_cpuid_id());
> +	if (list) {
> +#ifdef MULTI_CPU
> +		processor = *list->proc;
> +#endif
> +	}
> +
> +	BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END - (1UL << 29));
> +
> +
> +	kasan_map_early_shadow(swapper_pg_dir);
> +	start_kernel();
> +}
> +
> +static void __init clear_pgds(unsigned long start,
> +			unsigned long end)
> +{
> +	for (; start && start < end; start += PMD_SIZE)
> +		pmd_clear(pmd_off_k(start));
> +}
> +
> +pte_t * __meminit kasan_pte_populate(pmd_t *pmd, unsigned long addr, int node)
> +{
> +	pte_t *pte = pte_offset_kernel(pmd, addr);
> +	if (pte_none(*pte)) {
> +		pte_t entry;
> +		void *p = kasan_alloc_block(PAGE_SIZE, node);
> +		if (!p)
> +			return NULL;
> +		entry = pfn_pte(virt_to_pfn(p), __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
> +		set_pte_at(&init_mm, addr, pte, entry);
> +	}
> +	return pte;
> +}
> +
> +pmd_t * __meminit kasan_pmd_populate(pud_t *pud, unsigned long addr, int node)
> +{
> +	pmd_t *pmd = pmd_offset(pud, addr);
> +	if (pmd_none(*pmd)) {
> +		void *p = kasan_alloc_block(PAGE_SIZE, node);
> +		if (!p)
> +			return NULL;
> +		pmd_populate_kernel(&init_mm, pmd, p);
> +	}
> +	return pmd;
> +}
> +
> +pud_t * __meminit kasan_pud_populate(pgd_t *pgd, unsigned long addr, int node)
> +{
> +	pud_t *pud = pud_offset(pgd, addr);
> +	if (pud_none(*pud)) {
> +		void *p = kasan_alloc_block(PAGE_SIZE, node);
> +		if (!p)
> +			return NULL;
> +		pr_err("populating pud addr %lx\n", addr);
> +		pud_populate(&init_mm, pud, p);
> +	}
> +	return pud;
> +}
> +
> +pgd_t * __meminit kasan_pgd_populate(unsigned long addr, int node)
> +{
> +	pgd_t *pgd = pgd_offset_k(addr);
> +	if (pgd_none(*pgd)) {
> +		void *p = kasan_alloc_block(PAGE_SIZE, node);
> +		if (!p)
> +			return NULL;
> +		pgd_populate(&init_mm, pgd, p);
> +	}
> +	return pgd;
> +}

This all looks wrong - you are aware that on non-LPAE platforms, there
is only a _two_ level page table - the top level page table is 16K in
size, and each _individual_ lower level page table is actually 1024
bytes, but we do some special handling in the kernel to combine two
together.  It looks to me that you allocate memory for each Linux-
abstracted page table level whether the hardware needs it or not.

Is there any reason why the pre-existing "create_mapping()" function
can't be used, and you've had to rewrite that code here?

> +
> +static int __init create_mapping(unsigned long start, unsigned long end, int node)
> +{
> +	unsigned long addr = start;
> +	pgd_t *pgd;
> +	pud_t *pud;
> +	pmd_t *pmd;
> +	pte_t *pte;

A blank line would help between the auto variables and the code of the
function.

> +	pr_info("populating shadow for %lx, %lx\n", start, end);

Blank line here too please.

> +	for (; addr < end; addr += PAGE_SIZE) {
> +		pgd = kasan_pgd_populate(addr, node);
> +		if (!pgd)
> +			return -ENOMEM;
> +
> +		pud = kasan_pud_populate(pgd, addr, node);
> +		if (!pud)
> +			return -ENOMEM;
> +
> +		pmd = kasan_pmd_populate(pud, addr, node);
> +		if (!pmd)
> +			return -ENOMEM;
> +
> +		pte = kasan_pte_populate(pmd, addr, node);
> +		if (!pte)
> +			return -ENOMEM;
> +	}
> +	return 0;
> +}
> +
> +
> +void __init kasan_init(void)
> +{
> +	struct memblock_region *reg;
> +	u64 orig_ttbr0;
> +
> +	orig_ttbr0 = cpu_get_ttbr(0);
> +
> +#ifdef CONFIG_ARM_LPAE
> +	memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
> +	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
> +	set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
> +	cpu_set_ttbr0(__pa(tmp_page_table));
> +#else
> +	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
> +	cpu_set_ttbr0(__pa(tmp_page_table));
> +#endif
> +	flush_cache_all();
> +	local_flush_bp_all();
> +	local_flush_tlb_all();

What are you trying to achieve with all this complexity?  Some comments
might be useful, especially for those of us who don't know the internals
of kasan.

> +
> +	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
> +
> +	kasan_populate_zero_shadow(
> +		kasan_mem_to_shadow((void *)KASAN_SHADOW_START),
> +		kasan_mem_to_shadow((void *)KASAN_SHADOW_END));
> +
> +	kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
> +				kasan_mem_to_shadow((void *)-1UL) + 1);
> +
> +	for_each_memblock(memory, reg) {
> +		void *start = __va(reg->base);
> +		void *end = __va(reg->base + reg->size);

Isn't this going to complain if the translation macro debugging is enabled?

> +
> +		if (reg->base + reg->size > arm_lowmem_limit)
> +			end = __va(arm_lowmem_limit);
> +		if (start >= end)
> +			break;
> +
> +		create_mapping((unsigned long)kasan_mem_to_shadow(start),
> +			(unsigned long)kasan_mem_to_shadow(end),
> +			NUMA_NO_NODE);
> +	}
> +
> +	/*1.the module's global variable is in MODULES_VADDR ~ MODULES_END,so we need mapping.
> +	  *2.PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR ~ MODULES_END's shadow
> +	  *  is in the same PMD_SIZE, so we cant use kasan_populate_zero_shadow.
> +	  *
> +	  **/
> +	create_mapping((unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR),
> +		(unsigned long)kasan_mem_to_shadow((void *)(PKMAP_BASE+PMD_SIZE)),
> +		NUMA_NO_NODE);
> +	cpu_set_ttbr0(orig_ttbr0);
> +	flush_cache_all();
> +	local_flush_bp_all();
> +	local_flush_tlb_all();
> +	memset(kasan_zero_page, 0, PAGE_SIZE);
> +	pr_info("Kernel address sanitizer initialized\n");
> +	init_task.kasan_depth = 0;
> +}
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 6f319fb..12749da 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -358,7 +358,7 @@ void kasan_cache_create(struct kmem_cache *cache, size_t *size,
>  	if (redzone_adjust > 0)
>  		*size += redzone_adjust;
>  
> -	*size = min(KMALLOC_MAX_SIZE, max(*size, cache->object_size +
> +	*size = min((size_t)KMALLOC_MAX_SIZE, max(*size, cache->object_size +
>  					optimal_redzone(cache->object_size)));
>  
>  	/*
> -- 
> 2.9.0
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 01/11] Initialize the mapping of KASan shadow memory

[Liuwenliang (Abbott Liu)]

On Oct 19, 2017 at 19:09, Russell King - ARM Linux [mailto:linux at armlinux.org.uk] wrote:
>On Wed, Oct 11, 2017 at 04:22:17PM +0800, Abbott Liu wrote:
>> +#else
>> +#define pud_populate(mm,pmd,pte)	do { } while (0)
>> +#endif
>
>Please explain this change - we don't have a "pud" as far as the rest of
>the Linux MM layer is concerned, so why do we need it for kasan?
>
>I suspect it comes from the way we wrap up the page tables - where ARM
>does it one way (because it has to) vs the subsequently merged method
>which is completely upside down to what ARMs doing, and therefore is
>totally incompatible and impossible to fit in with our way.

We will use pud_polulate in kasan_populate_zero_shadow function.
....
>>  obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
>> +
>> +KASAN_SANITIZE_kasan_init.o    := n
>> +obj-$(CONFIG_KASAN)            += kasan_init.o
>
>Why is this placed in the middle of the cache object listing?

Sorry, I will place this at the end of the arch/arm/mm/Makefile.
>> +
>> +
>>  obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
...

>> +pgd_t * __meminit kasan_pgd_populate(unsigned long addr, int node)
>> +{
>> +	pgd_t *pgd = pgd_offset_k(addr);
>> +	if (pgd_none(*pgd)) {
>> +		void *p = kasan_alloc_block(PAGE_SIZE, node);
>> +		if (!p)
>> +			return NULL;
>> +		pgd_populate(&init_mm, pgd, p);
>> +	}
>> +	return pgd;
>> +}

>This all looks wrong - you are aware that on non-LPAE platforms, there
>is only a _two_ level page table - the top level page table is 16K in
>size, and each _individual_ lower level page table is actually 1024
>bytes, but we do some special handling in the kernel to combine two
>together.  It looks to me that you allocate memory for each Linux-
>abstracted page table level whether the hardware needs it or not.

You are right. If non-LPAE platform check if(pgd_none(*pgd)) true,
void *p = kasan_alloc_block(PAGE_SIZE, node) alloc space is not enough.
But the the function kasan_pgd_populate only used in :
Kasan_init-> create_mapping-> kasan_pgd_populate , so when non-LPAE platform
the if (pgd_none(*pgd)) always false.
But I also think change those code is much better :
if (IS_ENABLED(CONFIG_ARM_LPAE)) {
   p = kasan_alloc_block(PAGE_SIZE, node);
} else {
   /* non-LPAE need 16K for first level pagetabe*/
   p = kasan_alloc_block(PAGE_SIZE*4, node);
}

>Is there any reason why the pre-existing "create_mapping()" function
>can't be used, and you've had to rewrite that code here?

Two reason:
1) Here create_mapping can dynamic alloc phys memory space for mapping to virtual space 
Which from start to end, but the create_mapping in arch/arm/mm/mmu.c can't.
2) for LPAE, create_mapping need alloc pgd which we need use virtual space below 0xc0000000,
 here create_mapping can alloc pgd, but create_mapping in arch/arm/mm/mmu.c can't.

>> +
>> +static int __init create_mapping(unsigned long start, unsigned long end, int node)
>> +{
>> +	unsigned long addr = start;
>> +	pgd_t *pgd;
>> +	pud_t *pud;
>> +	pmd_t *pmd;
>> +	pte_t *pte;
>
>A blank line would help between the auto variables and the code of the
>function.

Ok, I will add blank line in new version.
>> +	pr_info("populating shadow for %lx, %lx\n", start, end);
>
>Blank line here too please.

Ok, I will add blank line in new version.

>> +	for (; addr < end; addr += PAGE_SIZE) {
>> +		pgd = kasan_pgd_populate(addr, node);
>> +		if (!pgd)
>> +			return -ENOMEM;
...
>> +void __init kasan_init(void)
>> +{
>> +	struct memblock_region *reg;
>> +	u64 orig_ttbr0;
>> +
>> +	orig_ttbr0 = cpu_get_ttbr(0);
>> +
>> +#ifdef CONFIG_ARM_LPAE
>> +	memcpy(tmp_pmd_table, pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), sizeof(tmp_pmd_table));
>> +	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
>> +	set_pgd(&tmp_page_table[pgd_index(KASAN_SHADOW_START)], __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
>> +	cpu_set_ttbr0(__pa(tmp_page_table));
>> +#else
>> +	memcpy(tmp_page_table, swapper_pg_dir, sizeof(tmp_page_table));
>> +	cpu_set_ttbr0(__pa(tmp_page_table));
>> +#endif
>> +	flush_cache_all();
>> +	local_flush_bp_all();
>> +	local_flush_tlb_all();

>What are you trying to achieve with all this complexity?  Some comments
>might be useful, especially for those of us who don't know the internals
>of kasan.
OK, I will add some comments in kasan_init function in new version.
...
>> +	for_each_memblock(memory, reg) {
>> +		void *start = __va(reg->base);
>> +		void *end = __va(reg->base + reg->size);
>
>Isn't this going to complain if the translation macro debugging is enabled?

Sorry, I don't what is the translation macro. Can you tell me.

[PATCH 02/11] replace memory function

[Abbott Liu]

From: Andrey Ryabinin <a.ryabinin@samsung.com>

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.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 arch/arm/include/asm/string.h | 18 +++++++++++++++++-
 arch/arm/lib/memcpy.S         |  3 +++
 arch/arm/lib/memmove.S        |  5 ++++-
 arch/arm/lib/memset.S         |  3 +++
 4 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index fe1c6af..43325f8 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -14,15 +14,18 @@ extern char * strchr(const char * s, int c);
 
 #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_MEMSET32
 extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t);
@@ -39,7 +42,7 @@ static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n)
 }
 
 extern void __memzero(void *ptr, __kernel_size_t n);
-
+#ifndef CONFIG_KASAN
 #define memset(p,v,n)							\
 	({								\
 	 	void *__p = (p); size_t __n = n;			\
@@ -51,5 +54,18 @@ extern void __memzero(void *ptr, __kernel_size_t n);
 		}							\
 		(__p);							\
 	})
+#endif
+
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+
+/*
+ * For files that not instrumented (e.g. mm/slub.c) we
+ * should use not instrumented version of mem* functions.
+ */
+
+#define memcpy(dst, src, len) __memcpy(dst, src, len)
+#define memmove(dst, src, len) __memmove(dst, src, len)
+#define memset(s, c, n) __memset(s, c, n)
+#endif
 
 #endif
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 64111bd..79a83f8 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -61,6 +61,8 @@
 
 /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
 
+.weak memcpy
+ENTRY(__memcpy)
 ENTRY(mmiocpy)
 ENTRY(memcpy)
 
@@ -68,3 +70,4 @@ ENTRY(memcpy)
 
 ENDPROC(memcpy)
 ENDPROC(mmiocpy)
+ENDPROC(__memcpy)
diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S
index 69a9d47..313db6c 100644
--- a/arch/arm/lib/memmove.S
+++ b/arch/arm/lib/memmove.S
@@ -27,12 +27,14 @@
  * occurring in the opposite direction.
  */
 
+.weak memmove
+ENTRY(__memmove)
 ENTRY(memmove)
 	UNWIND(	.fnstart			)
 
 		subs	ip, r0, r1
 		cmphi	r2, ip
-		bls	memcpy
+		bls	__memcpy
 
 		stmfd	sp!, {r0, r4, lr}
 	UNWIND(	.fnend				)
@@ -225,3 +227,4 @@ ENTRY(memmove)
 18:		backward_copy_shift	push=24	pull=8
 
 ENDPROC(memmove)
+ENDPROC(__memmove)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index ed6d35d..64aa06a 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -16,6 +16,8 @@
 	.text
 	.align	5
 
+.weak memset
+ENTRY(__memset)
 ENTRY(mmioset)
 ENTRY(memset)
 UNWIND( .fnstart         )
@@ -135,6 +137,7 @@ UNWIND( .fnstart            )
 UNWIND( .fnend   )
 ENDPROC(memset)
 ENDPROC(mmioset)
+ENDPROC(__memset)
 
 ENTRY(__memset32)
 UNWIND( .fnstart         )
-- 
2.9.0

[PATCH 02/11] replace memory function

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 04:22:18PM +0800, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
> 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.

KASAN in the decompressor makes no sense, so I think you need to
mark the decompressor compilation as such in this patch so it,
as a whole, sees no change.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

答复: [PATCH 02/11] replace memory function

[Liuwenliang (Lamb)]

On 10/19/2017 20:06 PM, Russell King - ARM Linux wrote:
>On Wed, Oct 11, 2017 at 04:22:18PM +0800, Abbott Liu wrote:
>> From: Andrey Ryabinin <a.ryabinin@samsung.com>
>> 
>> 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.
>
>KASAN in the decompressor makes no sense, so I think you need to
>mark the decompressor compilation as such in this patch so it,
>as a whole, sees no change.

Thanks for your reviews, I has already known some error in arm/boot/compressed/ .
I'm going to change it in this patch in new version.

[PATCH 03/11] arm: Kconfig: enable KASan

[Abbott Liu]

From: Andrey Ryabinin <a.ryabinin@samsung.com>

This patch enable kernel address sanitizer for arm.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7888c98..e9249fd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -46,6 +46,7 @@ config ARM
 	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
 	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
+	select HAVE_ARCH_KASAN if MMU
 	select HAVE_ARCH_MMAP_RND_BITS if MMU
 	select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
 	select HAVE_ARCH_TRACEHOOK
-- 
2.9.0

[PATCH 03/11] arm: Kconfig: enable KASan

[Florian Fainelli]

On 10/11/2017 01:22 AM, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
> This patch enable kernel address sanitizer for arm.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>

This needs to be the last patch in the series, otherwise you allow
people between patch 3 and 11 to have varying degrees of experience with
this patch series depending on their system type (LPAE or not, etc.)
-- 
Florian

[PATCH 03/11] arm: Kconfig: enable KASan

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 12:15:44PM -0700, Florian Fainelli wrote:
> On 10/11/2017 01:22 AM, Abbott Liu wrote:
> > From: Andrey Ryabinin <a.ryabinin@samsung.com>
> > 
> > This patch enable kernel address sanitizer for arm.
> > 
> > Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> > Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
> 
> This needs to be the last patch in the series, otherwise you allow
> people between patch 3 and 11 to have varying degrees of experience with
> this patch series depending on their system type (LPAE or not, etc.)

As the series stands, if patches 1-3 are applied, and KASAN is enabled,
there are various constants that end up being undefined, and the kernel
build will fail.  That is, of course, not acceptable.

KASAN must not be available until support for it is functionally
complete.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 03/11] arm: Kconfig: enable KASan

[Liuwenliang (Lamb)]

On 10/22/2017 01:22 AM, Russell King - ARM Linux wrote:
>On Wed, Oct 11, 2017 at 12:15:44PM -0700, Florian Fainelli wrote:
>> On 10/11/2017 01:22 AM, Abbott Liu wrote:
>> > From: Andrey Ryabinin <a.ryabinin@samsung.com>
>> > 
>> > This patch enable kernel address sanitizer for arm.
>> > 
>> > Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
>> > Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
>> 
>> This needs to be the last patch in the series, otherwise you allow
>> people between patch 3 and 11 to have varying degrees of experience with
>> this patch series depending on their system type (LPAE or not, etc.)
>
>As the series stands, if patches 1-3 are applied, and KASAN is enabled,
>there are various constants that end up being undefined, and the kernel
>build will fail.  That is, of course, not acceptable.
>
>KASAN must not be available until support for it is functionally
>complete.

Thanks for Florian Fainelli and Russell King's review.
I'm going to change it in the new version. 

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Abbott Liu]

Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for arm
kernel address sanitizer.

     +----+ 0xffffffff
     |    |
     |    |
     |    |
     +----+ CONFIG_PAGE_OFFSET
     |    |\
     |    | |->  module virtual address space area.
     |    |/
     +----+ MODULE_VADDR = KASAN_SHADOW_END
     |    |\
     |    | |-> the shadow area of kernel virtual address.
     |    |/
     +----+ TASK_SIZE(start of kernel space) = KASAN_SHADOW_START  the shadow address of MODULE_VADDR
     |    |\
     |    | ---------------------+
     |    |                      |
     +    + KASAN_SHADOW_OFFSET  |-> the user space area. Kernel address sanitizer do not use this space.
     |    |                      |
     |    | ---------------------+
     |    |/
     ------ 0

1)KASAN_SHADOW_OFFSET:
  This value is used to map an address to the corresponding shadow address by the
following formula:
  shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;

2)KASAN_SHADOW_START
  This value is the MODULE_VADDR's shadow address. It is the start of kernel virtual
space.

3) KASAN_SHADOW_END
  This value is the 0x100000000's shadow address. It is the end of kernel address
sanitizer's shadow area. It is also the start of the module area.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
---
 arch/arm/include/asm/kasan_def.h | 51 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/memory.h    |  5 ++++
 arch/arm/kernel/entry-armv.S     |  7 +++++-
 3 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/kasan_def.h

diff --git a/arch/arm/include/asm/kasan_def.h b/arch/arm/include/asm/kasan_def.h
new file mode 100644
index 0000000..7746908
--- /dev/null
+++ b/arch/arm/include/asm/kasan_def.h
@@ -0,0 +1,51 @@
+#ifndef __ASM_KASAN_DEF_H
+#define __ASM_KASAN_DEF_H
+
+#ifdef CONFIG_KASAN
+
+/*
+ *    +----+ 0xffffffff
+ *    |    |
+ *    |    |
+ *    |    |
+ *    +----+ CONFIG_PAGE_OFFSET
+ *    |    |\
+ *    |    | |->  module virtual address space area.
+ *    |    |/
+ *    +----+ MODULE_VADDR = KASAN_SHADOW_END
+ *    |    |\
+ *    |    | |-> the shadow area of kernel virtual address.
+ *    |    |/
+ *    +----+ TASK_SIZE(start of kernel space) = KASAN_SHADOW_START  the shadow address of MODULE_VADDR
+ *    |    |\
+ *    |    | ---------------------+
+ *    |    |                      |
+ *    +    + KASAN_SHADOW_OFFSET  |-> the user space area. Kernel address sanitizer do not use this space.
+ *    |    |                      |
+ *    |    | ---------------------+
+ *    |    |/
+ *    ------ 0
+ *
+ *1)KASAN_SHADOW_OFFSET:
+ *    This value is used to map an address to the corresponding shadow address by the
+ * following formula:
+ * shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
+ *
+ * 2)KASAN_SHADOW_START
+ *     This value is the MODULE_VADDR's shadow address. It is the start of kernel virtual
+ * space.
+ *
+ * 3) KASAN_SHADOW_END
+ *   This value is the 0x100000000's shadow address. It is the end of kernel address
+ * sanitizer's shadow area. It is also the start of the module area.
+ *
+ */
+
+#define KASAN_SHADOW_OFFSET     (KASAN_SHADOW_END - (1<<29))
+
+#define KASAN_SHADOW_START      ((KASAN_SHADOW_END >> 3) + KASAN_SHADOW_OFFSET)
+
+#define KASAN_SHADOW_END        (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
+
+#endif
+#endif
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1f54e4e..069710d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -21,6 +21,7 @@
 #ifdef CONFIG_NEED_MACH_MEMORY_H
 #include <mach/memory.h>
 #endif
+#include <asm/kasan_def.h>
 
 /*
  * Allow for constants defined here to be used from assembly code
@@ -37,7 +38,11 @@
  * TASK_SIZE - the maximum size of a user space task.
  * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
  */
+#ifndef CONFIG_KASAN
 #define TASK_SIZE		(UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
+#else
+#define TASK_SIZE               (KASAN_SHADOW_START)
+#endif
 #define TASK_UNMAPPED_BASE	ALIGN(TASK_SIZE / 3, SZ_16M)
 
 /*
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index fbc7076..f9efea3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -187,7 +187,12 @@ ENDPROC(__und_invalid)
 
 	get_thread_info tsk
 	ldr	r0, [tsk, #TI_ADDR_LIMIT]
-	mov	r1, #TASK_SIZE
+#ifdef CONFIG_KASAN
+	movw r1, #:lower16:TASK_SIZE
+	movt r1, #:upper16:TASK_SIZE
+#else
+	mov r1, #TASK_SIZE
+#endif
 	str	r1, [tsk, #TI_ADDR_LIMIT]
 	str	r0, [sp, #SVC_ADDR_LIMIT]
 
-- 
2.9.0

[PATCH 04/11] Define the virtual space of KASan's shadow region

[kbuild test robot]

Hi Abbott,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.14-rc4]
[cannot apply to next-20171013]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Abbott-Liu/KASan-for-arm/20171014-104108
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/kernel/entry-common.S: Assembler messages:
>> arch/arm/kernel/entry-common.S:83: Error: invalid constant (ffffffffb6e00000) after fixup
   arch/arm/kernel/entry-common.S:118: Error: invalid constant (ffffffffb6e00000) after fixup
--
   arch/arm/kernel/entry-armv.S: Assembler messages:
>> arch/arm/kernel/entry-armv.S:213: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>> arch/arm/kernel/entry-armv.S:213: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:223: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:223: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:270: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:270: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:311: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:311: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:320: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:320: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,#:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
   arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,#:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode

vim +213 arch/arm/kernel/entry-armv.S

2dede2d8e Nicolas Pitre   2006-01-14  151  
2190fed67 Russell King    2015-08-20  152  	.macro	svc_entry, stack_hole=0, trace=1, uaccess=1
c4c5716e1 Catalin Marinas 2009-02-16  153   UNWIND(.fnstart		)
c4c5716e1 Catalin Marinas 2009-02-16  154   UNWIND(.save {r0 - pc}		)
e6a9dc612 Russell King    2016-05-13  155  	sub	sp, sp, #(SVC_REGS_SIZE + \stack_hole - 4)
b86040a59 Catalin Marinas 2009-07-24  156  #ifdef CONFIG_THUMB2_KERNEL
b86040a59 Catalin Marinas 2009-07-24  157   SPFIX(	str	r0, [sp]	)	@ temporarily saved
b86040a59 Catalin Marinas 2009-07-24  158   SPFIX(	mov	r0, sp		)
b86040a59 Catalin Marinas 2009-07-24  159   SPFIX(	tst	r0, #4		)	@ test original stack alignment
b86040a59 Catalin Marinas 2009-07-24  160   SPFIX(	ldr	r0, [sp]	)	@ restored
b86040a59 Catalin Marinas 2009-07-24  161  #else
2dede2d8e Nicolas Pitre   2006-01-14  162   SPFIX(	tst	sp, #4		)
b86040a59 Catalin Marinas 2009-07-24  163  #endif
b86040a59 Catalin Marinas 2009-07-24  164   SPFIX(	subeq	sp, sp, #4	)
b86040a59 Catalin Marinas 2009-07-24  165  	stmia	sp, {r1 - r12}
ccea7a19e Russell King    2005-05-31  166  
b059bdc39 Russell King    2011-06-25  167  	ldmia	r0, {r3 - r5}
b059bdc39 Russell King    2011-06-25  168  	add	r7, sp, #S_SP - 4	@ here for interlock avoidance
b059bdc39 Russell King    2011-06-25  169  	mov	r6, #-1			@  ""  ""      ""       ""
e6a9dc612 Russell King    2016-05-13  170  	add	r2, sp, #(SVC_REGS_SIZE + \stack_hole - 4)
b059bdc39 Russell King    2011-06-25  171   SPFIX(	addeq	r2, r2, #4	)
b059bdc39 Russell King    2011-06-25  172  	str	r3, [sp, #-4]!		@ save the "real" r0 copied
ccea7a19e Russell King    2005-05-31  173  					@ from the exception stack
ccea7a19e Russell King    2005-05-31  174  
b059bdc39 Russell King    2011-06-25  175  	mov	r3, lr
^1da177e4 Linus Torvalds  2005-04-16  176  
^1da177e4 Linus Torvalds  2005-04-16  177  	@
^1da177e4 Linus Torvalds  2005-04-16  178  	@ We are now ready to fill in the remaining blanks on the stack:
^1da177e4 Linus Torvalds  2005-04-16  179  	@
b059bdc39 Russell King    2011-06-25  180  	@  r2 - sp_svc
b059bdc39 Russell King    2011-06-25  181  	@  r3 - lr_svc
b059bdc39 Russell King    2011-06-25  182  	@  r4 - lr_<exception>, already fixed up for correct return/restart
b059bdc39 Russell King    2011-06-25  183  	@  r5 - spsr_<exception>
b059bdc39 Russell King    2011-06-25  184  	@  r6 - orig_r0 (see pt_regs definition in ptrace.h)
^1da177e4 Linus Torvalds  2005-04-16  185  	@
b059bdc39 Russell King    2011-06-25  186  	stmia	r7, {r2 - r6}
^1da177e4 Linus Torvalds  2005-04-16  187  
e6978e4bf Russell King    2016-05-13  188  	get_thread_info tsk
e6978e4bf Russell King    2016-05-13  189  	ldr	r0, [tsk, #TI_ADDR_LIMIT]
74e552f98 Abbott Liu      2017-10-11  190  #ifdef CONFIG_KASAN
74e552f98 Abbott Liu      2017-10-11  191  	movw r1, #:lower16:TASK_SIZE
74e552f98 Abbott Liu      2017-10-11  192  	movt r1, #:upper16:TASK_SIZE
74e552f98 Abbott Liu      2017-10-11  193  #else
e6978e4bf Russell King    2016-05-13  194  	mov r1, #TASK_SIZE
74e552f98 Abbott Liu      2017-10-11  195  #endif
e6978e4bf Russell King    2016-05-13  196  	str	r1, [tsk, #TI_ADDR_LIMIT]
e6978e4bf Russell King    2016-05-13  197  	str	r0, [sp, #SVC_ADDR_LIMIT]
e6978e4bf Russell King    2016-05-13  198  
2190fed67 Russell King    2015-08-20  199  	uaccess_save r0
2190fed67 Russell King    2015-08-20  200  	.if \uaccess
2190fed67 Russell King    2015-08-20  201  	uaccess_disable r0
2190fed67 Russell King    2015-08-20  202  	.endif
2190fed67 Russell King    2015-08-20  203  
c0e7f7ee7 Daniel Thompson 2014-09-17  204  	.if \trace
02fe2845d Russell King    2011-06-25  205  #ifdef CONFIG_TRACE_IRQFLAGS
02fe2845d Russell King    2011-06-25  206  	bl	trace_hardirqs_off
02fe2845d Russell King    2011-06-25  207  #endif
c0e7f7ee7 Daniel Thompson 2014-09-17  208  	.endif
f2741b78b Russell King    2011-06-25  209  	.endm
^1da177e4 Linus Torvalds  2005-04-16  210  
f2741b78b Russell King    2011-06-25  211  	.align	5
f2741b78b Russell King    2011-06-25  212  __dabt_svc:
2190fed67 Russell King    2015-08-20 @213  	svc_entry uaccess=0
^1da177e4 Linus Torvalds  2005-04-16  214  	mov	r2, sp
da7404725 Russell King    2011-06-26  215  	dabt_helper
e16b31bf4 Marc Zyngier    2013-11-04  216   THUMB(	ldr	r5, [sp, #S_PSR]	)	@ potentially updated CPSR
b059bdc39 Russell King    2011-06-25  217  	svc_exit r5				@ return from exception
c4c5716e1 Catalin Marinas 2009-02-16  218   UNWIND(.fnend		)
93ed39701 Catalin Marinas 2008-08-28  219  ENDPROC(__dabt_svc)
^1da177e4 Linus Torvalds  2005-04-16  220  
^1da177e4 Linus Torvalds  2005-04-16  221  	.align	5
^1da177e4 Linus Torvalds  2005-04-16  222  __irq_svc:
ccea7a19e Russell King    2005-05-31  223  	svc_entry
187a51ad1 Russell King    2005-05-21  224  	irq_handler
1613cc111 Russell King    2011-06-25  225  

:::::: The code at line 213 was first introduced by commit
:::::: 2190fed67ba6f3e8129513929f2395843645e928 ARM: entry: provide uaccess assembly macro hooks

:::::: TO: Russell King <rmk+kernel@arm.linux.org.uk>
:::::: CC: Russell King <rmk+kernel@arm.linux.org.uk>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 64028 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171014/e2e98833/attachment-0001.gz>

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Liuwenliang (Lamb)]

On 10/16/2017 07:03 PM, Abbott Liu wrote:
>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,
  #:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,
  #:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode

Thanks for building test. This error can be solved by following code:
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -188,8 +188,7 @@ ENDPROC(__und_invalid)
        get_thread_info tsk
        ldr     r0, [tsk, #TI_ADDR_LIMIT]
 #ifdef CONFIG_KASAN
-   movw r1, #:lower16:TASK_SIZE
-   movt r1, #:upper16:TASK_SIZE
+ ldr r1, =TASK_SIZE
 #else
        mov r1, #TASK_SIZE
 #endif
@@ -446,7 +445,12 @@ ENDPROC(__fiq_abt)
        @ if it was interrupted in a critical region.  Here we
        @ perform a quick test inline since it should be false
        @ 99.9999% of the time.  The rest is done out of line.
+#if CONFIG_KASAN
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
+#else
        cmp     r4, #TASK_SIZE
+#endif
        blhs    kuser_cmpxchg64_fixup
 #endif
 #endif

movt,movw can only be used in ARMv6*, ARMv7 instruction set. But ldr can be used in ARMv4*, ARMv5T*, ARMv6*, ARMv7.
Maybe the performance is going to fall down by using ldr, but I think the influence of performance is very limited.

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Ard Biesheuvel]

On 16 October 2017 at 12:42, Liuwenliang (Lamb) <liuwenliang@huawei.com> wrote:
> On 10/16/2017 07:03 PM, Abbott Liu wrote:
>>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,
>   #:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,
>   #:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>
> Thanks for building test. This error can be solved by following code:
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -188,8 +188,7 @@ ENDPROC(__und_invalid)
>         get_thread_info tsk
>         ldr     r0, [tsk, #TI_ADDR_LIMIT]
>  #ifdef CONFIG_KASAN
> -   movw r1, #:lower16:TASK_SIZE
> -   movt r1, #:upper16:TASK_SIZE
> + ldr r1, =TASK_SIZE
>  #else
>         mov r1, #TASK_SIZE
>  #endif

This is unnecessary:

ldr r1, =TASK_SIZE

will be converted to a mov instruction by the assembler if the value
of TASK_SIZE fits its 12-bit immediate field.

So please remove the whole #ifdef, and just use ldr r1, =xxx

> @@ -446,7 +445,12 @@ ENDPROC(__fiq_abt)
>         @ if it was interrupted in a critical region.  Here we
>         @ perform a quick test inline since it should be false
>         @ 99.9999% of the time.  The rest is done out of line.
> +#if CONFIG_KASAN
> + ldr r0, =TASK_SIZE
> + cmp r4, r0
> +#else
>         cmp     r4, #TASK_SIZE
> +#endif
>         blhs    kuser_cmpxchg64_fixup
>  #endif
>  #endif
>
> movt,movw can only be used in ARMv6*, ARMv7 instruction set. But ldr can be used in ARMv4*, ARMv5T*, ARMv6*, ARMv7.
> Maybe the performance is going to fall down by using ldr, but I think the influence of performance is very limited.
>

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Liuwenliang (Lamb)]

On 10/17/2017 12:40 AM, Abbott Liu wrote:
> Ard Biesheuvel [ard.biesheuvel at linaro.org] wrote
>This is unnecessary:
>
>ldr r1, =TASK_SIZE
>
>will be converted to a mov instruction by the assembler if the value of TASK_SIZE fits its 12-bit immediate field.
>
>So please remove the whole #ifdef, and just use ldr r1, =xxx

Thanks for your review. 

The assembler on my computer don't convert ldr r1,=xxx into mov instruction. Here is the objdump for vmlinux:

c0a3b100 <__irq_svc>:
c0a3b100:       e24dd04c        sub     sp, sp, #76     ; 0x4c
c0a3b104:       e31d0004        tst     sp, #4
c0a3b108:       024dd004        subeq   sp, sp, #4
c0a3b10c:       e88d1ffe        stm     sp, {r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip}
c0a3b110:       e8900038        ldm     r0, {r3, r4, r5}
c0a3b114:       e28d7030        add     r7, sp, #48     ; 0x30
c0a3b118:       e3e06000        mvn     r6, #0
c0a3b11c:       e28d204c        add     r2, sp, #76     ; 0x4c
c0a3b120:       02822004        addeq   r2, r2, #4
c0a3b124:       e52d3004        push    {r3}            ; (str r3, [sp, #-4]!)
c0a3b128:       e1a0300e        mov     r3, lr
c0a3b12c:       e887007c        stm     r7, {r2, r3, r4, r5, r6}
c0a3b130:       e1a0972d        lsr     r9, sp, #14
c0a3b134:       e1a09709        lsl     r9, r9, #14
c0a3b138:       e5990008        ldr     r0, [r9, #8]
---c0a3b13c:       e59f1054        ldr     r1, [pc, #84]   ; c0a3b198 <__irq_svc+0x98>  //ldr r1, =TASK_SIZE
c0a3b140:       e5891008        str     r1, [r9, #8]
c0a3b144:       e58d004c        str     r0, [sp, #76]   ; 0x4c
c0a3b148:       ee130f10        mrc     15, 0, r0, cr3, cr0, {0}
c0a3b14c:       e58d0048        str     r0, [sp, #72]   ; 0x48
c0a3b150:       e3a00051        mov     r0, #81 ; 0x51
c0a3b154:       ee030f10        mcr     15, 0, r0, cr3, cr0, {0}
---c0a3b158:       e59f103c        ldr     r1, [pc, #60]   ; c0a3b19c <__irq_svc+0x9c>  //orginal irq_svc also used same instruction
c0a3b15c:       e1a0000d        mov     r0, sp
c0a3b160:       e28fe000        add     lr, pc, #0
c0a3b164:       e591f000        ldr     pc, [r1]
c0a3b168:       e5998004        ldr     r8, [r9, #4]
c0a3b16c:       e5990000        ldr     r0, [r9]
c0a3b170:       e3380000        teq     r8, #0
c0a3b174:       13a00000        movne   r0, #0
c0a3b178:       e3100002        tst     r0, #2
c0a3b17c:       1b000007        blne    c0a3b1a0 <svc_preempt>
c0a3b180:       e59d104c        ldr     r1, [sp, #76]   ; 0x4c
c0a3b184:       e59d0048        ldr     r0, [sp, #72]   ; 0x48
c0a3b188:       ee030f10        mcr     15, 0, r0, cr3, cr0, {0}
c0a3b18c:       e5891008        str     r1, [r9, #8]
c0a3b190:       e16ff005        msr     SPSR_fsxc, r5
c0a3b194:       e8ddffff        ldm     sp, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, sp, lr, pc}^
---c0a3b198:       b6e00000        .word   0xb6e00000   //TASK_SIZE:0xb6e00000
c0a3b19c:       c0ccccf0        .word   0xc0ccccf0



Even "ldr r1, =TASK_SIZE"  won't be converted to a mov instruction by some assembler, I also think it is better
to remove the whole #ifdef because the influence of performance by ldr is very limited. 

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Ard Biesheuvel]

On 17 October 2017 at 12:27, Liuwenliang (Lamb) <liuwenliang@huawei.com> wrote:
> On 10/17/2017 12:40 AM, Abbott Liu wrote:
>> Ard Biesheuvel [ard.biesheuvel at linaro.org] wrote
>>This is unnecessary:
>>
>>ldr r1, =TASK_SIZE
>>
>>will be converted to a mov instruction by the assembler if the value of TASK_SIZE fits its 12-bit immediate field.
>>
>>So please remove the whole #ifdef, and just use ldr r1, =xxx
>
> Thanks for your review.
>
> The assembler on my computer don't convert ldr r1,=xxx into mov instruction.


What I said was

'if the value of TASK_SIZE fits its 12-bit immediate field'

and your value of TASK_SIZE is 0xb6e00000, which cannot be decomposed
in the right way.

If you build with KASAN disabled, it will generate a mov instruction instead.



> Here is the objdump for vmlinux:
>
> c0a3b100 <__irq_svc>:
> c0a3b100:       e24dd04c        sub     sp, sp, #76     ; 0x4c
> c0a3b104:       e31d0004        tst     sp, #4
> c0a3b108:       024dd004        subeq   sp, sp, #4
> c0a3b10c:       e88d1ffe        stm     sp, {r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip}
> c0a3b110:       e8900038        ldm     r0, {r3, r4, r5}
> c0a3b114:       e28d7030        add     r7, sp, #48     ; 0x30
> c0a3b118:       e3e06000        mvn     r6, #0
> c0a3b11c:       e28d204c        add     r2, sp, #76     ; 0x4c
> c0a3b120:       02822004        addeq   r2, r2, #4
> c0a3b124:       e52d3004        push    {r3}            ; (str r3, [sp, #-4]!)
> c0a3b128:       e1a0300e        mov     r3, lr
> c0a3b12c:       e887007c        stm     r7, {r2, r3, r4, r5, r6}
> c0a3b130:       e1a0972d        lsr     r9, sp, #14
> c0a3b134:       e1a09709        lsl     r9, r9, #14
> c0a3b138:       e5990008        ldr     r0, [r9, #8]
> ---c0a3b13c:       e59f1054        ldr     r1, [pc, #84]   ; c0a3b198 <__irq_svc+0x98>  //ldr r1, =TASK_SIZE
> c0a3b140:       e5891008        str     r1, [r9, #8]
> c0a3b144:       e58d004c        str     r0, [sp, #76]   ; 0x4c
> c0a3b148:       ee130f10        mrc     15, 0, r0, cr3, cr0, {0}
> c0a3b14c:       e58d0048        str     r0, [sp, #72]   ; 0x48
> c0a3b150:       e3a00051        mov     r0, #81 ; 0x51
> c0a3b154:       ee030f10        mcr     15, 0, r0, cr3, cr0, {0}
> ---c0a3b158:       e59f103c        ldr     r1, [pc, #60]   ; c0a3b19c <__irq_svc+0x9c>  //orginal irq_svc also used same instruction
> c0a3b15c:       e1a0000d        mov     r0, sp
> c0a3b160:       e28fe000        add     lr, pc, #0
> c0a3b164:       e591f000        ldr     pc, [r1]
> c0a3b168:       e5998004        ldr     r8, [r9, #4]
> c0a3b16c:       e5990000        ldr     r0, [r9]
> c0a3b170:       e3380000        teq     r8, #0
> c0a3b174:       13a00000        movne   r0, #0
> c0a3b178:       e3100002        tst     r0, #2
> c0a3b17c:       1b000007        blne    c0a3b1a0 <svc_preempt>
> c0a3b180:       e59d104c        ldr     r1, [sp, #76]   ; 0x4c
> c0a3b184:       e59d0048        ldr     r0, [sp, #72]   ; 0x48
> c0a3b188:       ee030f10        mcr     15, 0, r0, cr3, cr0, {0}
> c0a3b18c:       e5891008        str     r1, [r9, #8]
> c0a3b190:       e16ff005        msr     SPSR_fsxc, r5
> c0a3b194:       e8ddffff        ldm     sp, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, sp, lr, pc}^
> ---c0a3b198:       b6e00000        .word   0xb6e00000   //TASK_SIZE:0xb6e00000
> c0a3b19c:       c0ccccf0        .word   0xc0ccccf0
>
>
>
> Even "ldr r1, =TASK_SIZE"  won't be converted to a mov instruction by some assembler, I also think it is better
> to remove the whole #ifdef because the influence of performance by ldr is very limited.
>

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Liuwenliang (Lamb)]

On 10/17/2017 8:45 PM, Abbott Liu wrote:
>What I said was
>
>'if the value of TASK_SIZE fits its 12-bit immediate field'
>
>and your value of TASK_SIZE is 0xb6e00000, which cannot be decomposed in the right way.
>
>If you build with KASAN disabled, it will generate a mov instruction instead.

Thanks for your explain. I understand now.  I has tested and the testing result proves that what 
you said is right. 

Here is test log:
c010e9e0 <__irq_svc>:
c010e9e0:       e24dd04c        sub     sp, sp, #76     ; 0x4c
c010e9e4:       e31d0004        tst     sp, #4
c010e9e8:       024dd004        subeq   sp, sp, #4
c010e9ec:       e88d1ffe        stm     sp, {r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip}
c010e9f0:       e8900038        ldm     r0, {r3, r4, r5}
c010e9f4:       e28d7030        add     r7, sp, #48     ; 0x30
c010e9f8:       e3e06000        mvn     r6, #0
c010e9fc:       e28d204c        add     r2, sp, #76     ; 0x4c
c010ea00:       02822004        addeq   r2, r2, #4
c010ea04:       e52d3004        push    {r3}            ; (str r3, [sp, #-4]!)
c010ea08:       e1a0300e        mov     r3, lr
c010ea0c:       e887007c        stm     r7, {r2, r3, r4, r5, r6}
c010ea10:       e1a0972d        lsr     r9, sp, #14
c010ea14:       e1a09709        lsl     r9, r9, #14
c010ea18:       e5990008        ldr     r0, [r9, #8]
c010ea1c:       e3a014bf        mov     r1, #-1090519040        ; 0xbf000000  // ldr r1,=0xbf000000

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Russell King - ARM Linux]

On Tue, Oct 17, 2017 at 11:27:19AM +0000, Liuwenliang (Lamb) wrote:
> ---c0a3b198:       b6e00000        .word   0xb6e00000   //TASK_SIZE:0xb6e00000

It's probably going to be better all round to round TASK_SIZE down
to something that fits in an 8-bit rotated constant anyway (like
we already guarantee) which would mean this patch is not necessary.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Liuwenliang (Lamb)]

On Tue, Oct 19, 2017 at 20:41 17PM +0000, Russell King - ARM Linux:
>On Mon, Oct 16, 2017 at 11:42:05AM +0000, Liuwenliang (Lamb) wrote:
>> On 10/16/2017 07:03 PM, Abbott Liu wrote:
> >arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,
>>   #:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>> >arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,
>>   #:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
>> 
>> Thanks for building test. This error can be solved by following code:
>> --- a/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -188,8 +188,7 @@ ENDPROC(__und_invalid)
>>         get_thread_info tsk
>>         ldr     r0, [tsk, #TI_ADDR_LIMIT]
>>  #ifdef CONFIG_KASAN
>> -   movw r1, #:lower16:TASK_SIZE
>> -   movt r1, #:upper16:TASK_SIZE
>> + ldr r1, =TASK_SIZE
>>  #else
>>         mov r1, #TASK_SIZE
>>  #endif
>
>We can surely do better than this with macros and condition support -
>we can build-time test in the assembler whether TASK_SIZE can fit in a
>normal "mov", whether we can use the movw/movt instructions, or fall
>back to ldr if necessary.  I'd rather we avoided "ldr" here where
>possible.

Thanks for your review.
I don't know why we need to avoided "ldr". The "ldr" maybe cause the 
performance fall down, but it will be very limited, and as we know the 
performance of kasan version is lower than the normal version. And usually
we don't use kasan version in our product, we only use kasan version when 
we want to debug some memory corruption problem in laboratory(not not in
commercial product) because the performance of kasan version is lower than
normal version.

So I think we can accept the influence of the performance by using "ldr" here. 




On Tue, Oct 19, 2017 at 20:44 17PM +0000, Russell King - ARM Linux:
>On Tue, Oct 17, 2017 at 11:27:19AM +0000, Liuwenliang (Lamb) wrote:
>> ---c0a3b198:       b6e00000        .word   0xb6e00000   //TASK_SIZE:0xb6e00000
>
>It's probably going to be better all round to round TASK_SIZE down
>to something that fits in an 8-bit rotated constant anyway (like
>we already guarantee) which would mean this patch is not necessary.

Thanks for you review.
If we enable CONFIG_KASAN, we need steal 130MByte(0xb6e00000 ~ 0xbf000000) from user space.
If we change to steal 130MByte(0xb6000000 ~ 0xbe200000) , the 14MB of user space is going to be 
wasted. I think it is better to to use "ldr" whose influence to the system are very limited than to waste 
14MB user space by chaned TASK_SIZE from 0xb6e00000 from 0xb6000000.


If TASK_SIZE is an 8-bit rotated constant, the compiler can convert "ldr rx,=TASK_SIZE" into mov rx, #TASK_SIZE
If TASK_SIZE is not an 8-bit rotated constant, the compiler can convert "ldr rx,=TASK_SIZE" into ldr rx, [pc,xxx],
So we can use ldr to replace mov. Here is the code which is tested by me:

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index f9efea3..00a1833 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -187,12 +187,7 @@ ENDPROC(__und_invalid)

        get_thread_info tsk
        ldr     r0, [tsk, #TI_ADDR_LIMIT]
-#ifdef CONFIG_KASAN
-   movw r1, #:lower16:TASK_SIZE
-   movt r1, #:upper16:TASK_SIZE
-#else
-   mov r1, #TASK_SIZE
-#endif
+ ldr r1, =TASK_SIZE
        str     r1, [tsk, #TI_ADDR_LIMIT]
        str     r0, [sp, #SVC_ADDR_LIMIT]

@@ -446,7 +441,8 @@ ENDPROC(__fiq_abt)
        @ if it was interrupted in a critical region.  Here we
        @ perform a quick test inline since it should be false
        @ 99.9999% of the time.  The rest is done out of line.
-   cmp     r4, #TASK_SIZE
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
        blhs    kuser_cmpxchg64_fixup
 #endif
 #endif

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Russell King - ARM Linux]

On Mon, Oct 16, 2017 at 01:14:54PM +0100, Ard Biesheuvel wrote:
> On 16 October 2017 at 12:42, Liuwenliang (Lamb) <liuwenliang@huawei.com> wrote:
> > On 10/16/2017 07:03 PM, Abbott Liu wrote:
> >>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,
> >   #:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
> >>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,
> >   #:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
> >
> > Thanks for building test. This error can be solved by following code:
> > --- a/arch/arm/kernel/entry-armv.S
> > +++ b/arch/arm/kernel/entry-armv.S
> > @@ -188,8 +188,7 @@ ENDPROC(__und_invalid)
> >         get_thread_info tsk
> >         ldr     r0, [tsk, #TI_ADDR_LIMIT]
> >  #ifdef CONFIG_KASAN
> > -   movw r1, #:lower16:TASK_SIZE
> > -   movt r1, #:upper16:TASK_SIZE
> > + ldr r1, =TASK_SIZE
> >  #else
> >         mov r1, #TASK_SIZE
> >  #endif
> 
> This is unnecessary:
> 
> ldr r1, =TASK_SIZE
> 
> will be converted to a mov instruction by the assembler if the value
> of TASK_SIZE fits its 12-bit immediate field.

It's an 8-bit immediate field for ARM.

What it won't do is expand it to a pair of movw/movt instructions if it
doesn't fit.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 04/11] Define the virtual space of KASan's shadow region

[Russell King - ARM Linux]

On Mon, Oct 16, 2017 at 11:42:05AM +0000, Liuwenliang (Lamb) wrote:
> On 10/16/2017 07:03 PM, Abbott Liu wrote:
> >arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movw r1,
>   #:lower16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
> >arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support `movt r1,
>   #:upper16:((((0xC0000000-0x01000000)>>3)+((0xC0000000-0x01000000)-(1<<29))))' in ARM mode
> 
> Thanks for building test. This error can be solved by following code:
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -188,8 +188,7 @@ ENDPROC(__und_invalid)
>         get_thread_info tsk
>         ldr     r0, [tsk, #TI_ADDR_LIMIT]
>  #ifdef CONFIG_KASAN
> -   movw r1, #:lower16:TASK_SIZE
> -   movt r1, #:upper16:TASK_SIZE
> + ldr r1, =TASK_SIZE
>  #else
>         mov r1, #TASK_SIZE
>  #endif

We can surely do better than this with macros and condition support -
we can build-time test in the assembler whether TASK_SIZE can fit in a
normal "mov", whether we can use the movw/movt instructions, or fall
back to ldr if necessary.  I'd rather we avoided "ldr" here where
possible.

> @@ -446,7 +445,12 @@ ENDPROC(__fiq_abt)
>         @ if it was interrupted in a critical region.  Here we
>         @ perform a quick test inline since it should be false
>         @ 99.9999% of the time.  The rest is done out of line.
> +#if CONFIG_KASAN
> + ldr r0, =TASK_SIZE
> + cmp r4, r0
> +#else
>         cmp     r4, #TASK_SIZE

Same sort of thing goes for here - we can select the instruction at
runtime using the assembler's macros and condition support.

We know that TASK_SIZE is going to be one of a limited set of values.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 05/11] Disable kasan's instrumentation

[Abbott Liu]

From: Andrey Ryabinin <a.ryabinin@samsung.com>

 To avoid some build and runtime errors, compiler's instrumentation must
 be disabled for code not linked with kernel image.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 arch/arm/boot/compressed/Makefile | 1 +
 arch/arm/kernel/unwind.c          | 3 ++-
 arch/arm/vdso/Makefile            | 2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index d50430c..ab5693b 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -23,6 +23,7 @@ OBJS		+= hyp-stub.o
 endif
 
 GCOV_PROFILE		:= n
+KASAN_SANITIZE		:= n
 
 #
 # Architecture dependencies
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 0bee233..2e55c7d 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -249,7 +249,8 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
 		if (*vsp >= (unsigned long *)ctrl->sp_high)
 			return -URC_FAILURE;
 
-	ctrl->vrs[reg] = *(*vsp)++;
+	ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+	(*vsp)++;
 	return URC_OK;
 }
 
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index 59a8fa7..689dfec 100644
--- a/arch/arm/vdso/Makefile
+++ b/arch/arm/vdso/Makefile
@@ -29,6 +29,8 @@ CFLAGS_vgettimeofday.o = -O2
 # Disable gcov profiling for VDSO code
 GCOV_PROFILE := n
 
+KASAN_SANITIZE := n
+
 # Force dependency
 $(obj)/vdso.o : $(obj)/vdso.so
 
-- 
2.9.0

[PATCH 05/11] Disable kasan's instrumentation

[Florian Fainelli]

On 10/11/2017 01:22 AM, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
>  To avoid some build and runtime errors, compiler's instrumentation must
>  be disabled for code not linked with kernel image.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>

Same as patch 3, this needs to be moved before you allow KAsan to be
enabled/selected. This has little to no dependencies on other patches so
this could be moved as the first patch in the series.

Thanks!
-- 
Florian

[PATCH 05/11] Disable kasan's instrumentation

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 04:22:21PM +0800, Abbott Liu wrote:
> From: Andrey Ryabinin <a.ryabinin@samsung.com>
> 
>  To avoid some build and runtime errors, compiler's instrumentation must
>  be disabled for code not linked with kernel image.

How does that explain the change to unwind.c ?

Does this also disable the string macro changes?

In any case, this should certainly precede patch 4, and very probably
patch 2.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 05/11] Disable kasan's instrumentation

[Liuwenliang (Abbott Liu)]

On 19/10/17 20:47, Russell King - ARM Linux [mailto:linux at armlinux.org.uk]  wrote:
>On Wed, Oct 11, 2017 at 04:22:21PM +0800, Abbott Liu wrote:
>> From: Andrey Ryabinin <a.ryabinin@samsung.com>
>> 
>>  To avoid some build and runtime errors, compiler's instrumentation must
>>  be disabled for code not linked with kernel image.
>
>How does that explain the change to unwind.c ?

Thanks for your review.
Here is patch code:
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -249,7 +249,8 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
                if (*vsp >= (unsigned long *)ctrl->sp_high)
                        return -URC_FAILURE;

-       ctrl->vrs[reg] = *(*vsp)++;
+       ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+       (*vsp)++;
        return URC_OK;
 }

I change here because I don't think unwind_frame need to be check by kasan, and I have ever 
found the following error which rarely appares when remove the change of unwind.c.

Here is the error log:
==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x3e0/0x788
Read of size 4 at addr 868a3b20 by task swapper/0/1

CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2+ #2
Hardware name: ARM-Versatile Express
[<8011479c>] (unwind_backtrace) from [<8010f558>] (show_stack+0x10/0x14)
[<8010f558>] (show_stack) from [<808fdca0>] (dump_stack+0x90/0xa4)
[<808fdca0>] (dump_stack) from [<802b3808>] (print_address_description+0x4c/0x270)
[<802b3808>] (print_address_description) from [<802b3ec4>] (kasan_report+0x218/0x300)
[<802b3ec4>] (kasan_report) from [<801143f4>] (unwind_frame+0x3e0/0x788)
[<801143f4>] (unwind_frame) from [<8010ebc4>] (walk_stackframe+0x2c/0x38)
[<8010ebc4>] (walk_stackframe) from [<8010ee70>] (__save_stack_trace+0x160/0x164)
[<8010ee70>] (__save_stack_trace) from [<802b342c>] (kasan_slab_free+0x84/0x158)
[<802b342c>] (kasan_slab_free) from [<802b05dc>] (kmem_cache_free+0x58/0x1d4)
[<802b05dc>] (kmem_cache_free) from [<801a6420>] (rcu_process_callbacks+0x600/0xe04)
[<801a6420>] (rcu_process_callbacks) from [<801018e8>] (__do_softirq+0x1a0/0x4e0)
[<801018e8>] (__do_softirq) from [<80131560>] (irq_exit+0xec/0x120)
[<80131560>] (irq_exit) from [<8018d2a0>] (__handle_domain_irq+0x78/0xdc)
[<8018d2a0>] (__handle_domain_irq) from [<80101700>] (gic_handle_irq+0x48/0x8c)
[<80101700>] (gic_handle_irq) from [<80110690>] (__irq_svc+0x70/0x94)
Exception stack(0x868a39f0 to 0x868a3a38)
39e0:                                     7fffffff 868a3b88 00000000 00000001
3a00: 868a3b84 7fffffff 868a3b88 6fd1474c 868a3ac0 868a0000 00000002 86898000
3a20: 00000001 868a3a40 8091b4d4 8091edb0 60000013 ffffffff
[<80110690>] (__irq_svc) from [<8091edb0>] (schedule_timeout+0x0/0x3c4)
[<8091edb0>] (schedule_timeout) from [<6fd14770>] (0x6fd14770)

The buggy address belongs to the page:
page:87fcc460 count:0 mapcount:0 mapping:  (null) index:0x0
flags: 0x0()
raw: 00000000 00000000 00000000 ffffffff 00000000 87fcc474 87fcc474 00000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 868a3a00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 868a3a80: 00 00 04 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
>868a3b00: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2
                       ^
 868a3b80: 00 00 00 00 00 04 f4 f4 f3 f3 f3 f3 00 00 00 00
 868a3c00: 00 00 00 00 f1 f1 f1 f1 00 07 f4 f4 f3 f3 f3 f3
==================================================================
Disabling lock debugging due to kernel taint

/* Before poping a register check whether it is feasible or not */
static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
				unsigned long **vsp, unsigned int reg)
{
	if (unlikely(ctrl->check_each_pop))
		if (*vsp >= (unsigned long *)ctrl->sp_high)
			return -URC_FAILURE;

	// unwind_frame+0x3e0/0x788 is here
	ctrl->vrs[reg] = *(*vsp)++;
	return URC_OK;
}
>
>Does this also disable the string macro changes?
>
>In any case, this should certainly precede patch 4, and very probably
>patch 2.

You are right. I will change it in net version.

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Abbott Liu]

 Because arm instruction set don't support access the address which is
 not aligned, so must change memory_is_poisoned_16 for arm.

Cc:  Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 mm/kasan/kasan.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 12749da..e0e152b 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -149,6 +149,25 @@ static __always_inline bool memory_is_poisoned_2_4_8(unsigned long addr,
 	return memory_is_poisoned_1(addr + size - 1);
 }
 
+#ifdef CONFIG_ARM
+static __always_inline bool memory_is_poisoned_16(unsigned long addr)
+{
+	u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
+
+	if (unlikely(shadow_addr[0] || shadow_addr[1])) return true;
+	else {
+		/*
+		 * If two shadow bytes covers 16-byte access, we don't
+		 * need to do anything more. Otherwise, test the last
+		 * shadow byte.
+		 */
+		if (likely(IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
+			return false;
+		return memory_is_poisoned_1(addr + 15);
+	}
+}
+
+#else
 static __always_inline bool memory_is_poisoned_16(unsigned long addr)
 {
 	u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
@@ -159,6 +178,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned long addr)
 
 	return *shadow_addr;
 }
+#endif
 
 static __always_inline unsigned long bytes_is_nonzero(const u8 *start,
 					size_t size)
-- 
2.9.0

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Andrew Morton]

On Wed, 11 Oct 2017 16:22:22 +0800 Abbott Liu <liuwenliang@huawei.com> wrote:

>  Because arm instruction set don't support access the address which is
>  not aligned, so must change memory_is_poisoned_16 for arm.
> 
> ...
>
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -149,6 +149,25 @@ static __always_inline bool memory_is_poisoned_2_4_8(unsigned long addr,
>  	return memory_is_poisoned_1(addr + size - 1);
>  }
>  
> +#ifdef CONFIG_ARM
> +static __always_inline bool memory_is_poisoned_16(unsigned long addr)
> +{
> +	u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
> +
> +	if (unlikely(shadow_addr[0] || shadow_addr[1])) return true;

Coding-style is messed up.  Please use scripts/checkpatch.pl.

> +	else {
> +		/*
> +		 * If two shadow bytes covers 16-byte access, we don't
> +		 * need to do anything more. Otherwise, test the last
> +		 * shadow byte.
> +		 */
> +		if (likely(IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
> +			return false;
> +		return memory_is_poisoned_1(addr + 15);
> +	}
> +}
> +
> +#else
>  static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>  {
>  	u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
> @@ -159,6 +178,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>  
>  	return *shadow_addr;
>  }
> +#endif

- I don't understand why this is necessary.  memory_is_poisoned_16()
  already handles unaligned addresses?

- If it's needed on ARM then presumably it will be needed on other
  architectures, so CONFIG_ARM is insufficiently general.

- If the present memory_is_poisoned_16() indeed doesn't work on ARM,
  it would be better to generalize/fix it in some fashion rather than
  creating a new variant of the function.

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Dmitry Vyukov]

On Thu, Oct 12, 2017 at 1:23 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 11 Oct 2017 16:22:22 +0800 Abbott Liu <liuwenliang@huawei.com> wrote:
>
>>  Because arm instruction set don't support access the address which is
>>  not aligned, so must change memory_is_poisoned_16 for arm.
>>
>> ...
>>
>> --- a/mm/kasan/kasan.c
>> +++ b/mm/kasan/kasan.c
>> @@ -149,6 +149,25 @@ static __always_inline bool memory_is_poisoned_2_4_8(unsigned long addr,
>>       return memory_is_poisoned_1(addr + size - 1);
>>  }
>>
>> +#ifdef CONFIG_ARM
>> +static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>> +{
>> +     u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
>> +
>> +     if (unlikely(shadow_addr[0] || shadow_addr[1])) return true;
>
> Coding-style is messed up.  Please use scripts/checkpatch.pl.
>
>> +     else {
>> +             /*
>> +              * If two shadow bytes covers 16-byte access, we don't
>> +              * need to do anything more. Otherwise, test the last
>> +              * shadow byte.
>> +              */
>> +             if (likely(IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>> +                     return false;
>> +             return memory_is_poisoned_1(addr + 15);
>> +     }
>> +}
>> +
>> +#else
>>  static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>>  {
>>       u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>> @@ -159,6 +178,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>>
>>       return *shadow_addr;
>>  }
>> +#endif
>
> - I don't understand why this is necessary.  memory_is_poisoned_16()
>   already handles unaligned addresses?
>
> - If it's needed on ARM then presumably it will be needed on other
>   architectures, so CONFIG_ARM is insufficiently general.
>
> - If the present memory_is_poisoned_16() indeed doesn't work on ARM,
>   it would be better to generalize/fix it in some fashion rather than
>   creating a new variant of the function.


Yes, I think it will be better to fix the current function rather then
have 2 slightly different copies with ifdef's.
Will something along these lines work for arm? 16-byte accesses are
not too common, so it should not be a performance problem. And
probably modern compilers can turn 2 1-byte checks into a 2-byte check
where safe (x86).

static __always_inline bool memory_is_poisoned_16(unsigned long addr)
{
        u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);

        if (shadow_addr[0] || shadow_addr[1])
                return true;
        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
                return memory_is_poisoned_1(addr + 15);
        return false;
}

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Liuwenliang (Lamb)]

>> - I don't understand why this is necessary.  memory_is_poisoned_16()
>>   already handles unaligned addresses?
>>
>> - If it's needed on ARM then presumably it will be needed on other
>>   architectures, so CONFIG_ARM is insufficiently general.
>>
>> - If the present memory_is_poisoned_16() indeed doesn't work on ARM,
>>   it would be better to generalize/fix it in some fashion rather than
>>   creating a new variant of the function.


>Yes, I think it will be better to fix the current function rather then
>have 2 slightly different copies with ifdef's.
>Will something along these lines work for arm? 16-byte accesses are
>not too common, so it should not be a performance problem. And
>probably modern compilers can turn 2 1-byte checks into a 2-byte check
>where safe (x86).

>static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>{
>        u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
>
>        if (shadow_addr[0] || shadow_addr[1])
>                return true;
>        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>                return memory_is_poisoned_1(addr + 15);
>        return false;
>}

Thanks for Andrew Morton and Dmitry Vyukov's review. 
If the parameter addr=0xc0000008, now in function:
static __always_inline bool memory_is_poisoned_16(unsigned long addr)
{
 ---     //shadow_addr = (u16 *)(KASAN_OFFSET+0x18000001(=0xc0000008>>3)) is not 
 ---     // unsigned by 2 bytes.
        u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr); 

        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
                return *shadow_addr || memory_is_poisoned_1(addr + 15);
----      //here is going to be error on arm, specially when kernel has not finished yet.
----      //Because the unsigned accessing cause DataAbort Exception which is not
----      //initialized when kernel is starting. 
        return *shadow_addr;
}

I also think it is better to fix this problem. 

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Russell King - ARM Linux]

On Thu, Oct 12, 2017 at 11:27:40AM +0000, Liuwenliang (Lamb) wrote:
> >> - I don't understand why this is necessary.  memory_is_poisoned_16()
> >>   already handles unaligned addresses?
> >>
> >> - If it's needed on ARM then presumably it will be needed on other
> >>   architectures, so CONFIG_ARM is insufficiently general.
> >>
> >> - If the present memory_is_poisoned_16() indeed doesn't work on ARM,
> >>   it would be better to generalize/fix it in some fashion rather than
> >>   creating a new variant of the function.
> 
> 
> >Yes, I think it will be better to fix the current function rather then
> >have 2 slightly different copies with ifdef's.
> >Will something along these lines work for arm? 16-byte accesses are
> >not too common, so it should not be a performance problem. And
> >probably modern compilers can turn 2 1-byte checks into a 2-byte check
> >where safe (x86).
> 
> >static __always_inline bool memory_is_poisoned_16(unsigned long addr)
> >{
> >        u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
> >
> >        if (shadow_addr[0] || shadow_addr[1])
> >                return true;
> >        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
> >        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
> >                return memory_is_poisoned_1(addr + 15);
> >        return false;
> >}
> 
> Thanks for Andrew Morton and Dmitry Vyukov's review. 
> If the parameter addr=0xc0000008, now in function:
> static __always_inline bool memory_is_poisoned_16(unsigned long addr)
> {
>  ---     //shadow_addr = (u16 *)(KASAN_OFFSET+0x18000001(=0xc0000008>>3)) is not 
>  ---     // unsigned by 2 bytes.
>         u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr); 
> 
>         /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>         if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>                 return *shadow_addr || memory_is_poisoned_1(addr + 15);
> ----      //here is going to be error on arm, specially when kernel has not finished yet.
> ----      //Because the unsigned accessing cause DataAbort Exception which is not
> ----      //initialized when kernel is starting. 
>         return *shadow_addr;
> }
> 
> I also think it is better to fix this problem. 

What about using get_unaligned() ?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Liuwenliang (Abbott Liu)]

On Nov 23, 2017  20:30  Russell King - ARM Linux [mailto:linux at armlinux.org.uk]  wrote:
>On Thu, Oct 12, 2017 at 11:27:40AM +0000, Liuwenliang (Lamb) wrote:
>> >> - I don't understand why this is necessary.  memory_is_poisoned_16()
>> >>   already handles unaligned addresses?
>> >>
>> >> - If it's needed on ARM then presumably it will be needed on other
>> >>   architectures, so CONFIG_ARM is insufficiently general.
>> >>
>> >> - If the present memory_is_poisoned_16() indeed doesn't work on ARM,
>> >>   it would be better to generalize/fix it in some fashion rather than
>> >>   creating a new variant of the function.
>>
>>
>> >Yes, I think it will be better to fix the current function rather then
>> >have 2 slightly different copies with ifdef's.
>> >Will something along these lines work for arm? 16-byte accesses are
>> >not too common, so it should not be a performance problem. And
>> >probably modern compilers can turn 2 1-byte checks into a 2-byte check
>> >where safe (x86).
>>
>> >static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>> >{
>> >        u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
>> >
>> >        if (shadow_addr[0] || shadow_addr[1])
>> >                return true;
>> >        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>> >        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>> >                return memory_is_poisoned_1(addr + 15);
>> >        return false;
>> >}
>>
>> Thanks for Andrew Morton and Dmitry Vyukov's review.
>> If the parameter addr=0xc0000008, now in function:
>> static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>> {
>>  ---     //shadow_addr = (u16 *)(KASAN_OFFSET+0x18000001(=0xc0000008>>3)) is not
>>  ---     // unsigned by 2 bytes.
>>         u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>>
>>         /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>>         if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>>                 return *shadow_addr || memory_is_poisoned_1(addr + 15);
>> ----      //here is going to be error on arm, specially when kernel has not finished yet.
>> ----      //Because the unsigned accessing cause DataAbort Exception which is not
>> ----      //initialized when kernel is starting.
>>         return *shadow_addr;
>> }
>>
>> I also think it is better to fix this problem.

>What about using get_unaligned() ?

Thanks for your review.

I think it is good idea to use get_unaligned. But ARMv7 support CONFIG_ HAVE_EFFICIENT_UNALIGNED_ACCESS
(arch/arm/Kconfig : select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU).
So on ARMv7, the code:
u16 *shadow_addr = get_unaligned((u16 *)kasan_mem_to_shadow((void *)addr));
equals the code:000
u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);

On ARMv7, if SCRLR.A is 0, unaligned access is OK.  Here is the description comes from ARM(r) Architecture Reference
Manual ARMv7-A and ARMv7-R edition :

A3.2.1 Unaligned data access
An ARMv7 implementation must support unaligned data accesses by some load and store instructions, as
Table A3-1 shows. Software can set the SCTLR.A bit to control whether a misaligned access by one of these
instructions causes an Alignment fault Data abort exception.

Table A3-1 Alignment requirements of load/store instructions
Instructions                     Alignment check             SCTLR.A is 0        SCTLR.A is 1

LDRB, LDREXB, LDRBT,
LDRSB, LDRSBT, STRB,             None                       -                -
STREXB, STRBT, SWPB, 
TBB 

LDRH, LDRHT, LDRSH, 
LDRSHT, STRH, STRHT,            Halfword                    Unaligned access    Alignment fault
TBH 

LDREXH, STREXH                Halfword                    Alignment fault      Alignment fault

LDR, LDRT, STR, STRT
PUSH, encodings T3 and A2 only     Word                      Unaligned access     Alignment fault
POP, encodings T3 and A2 only

LDREX, STREX                    Word                     Alignment fault       Alignment fault

LDREXD, STREXD                 Doubleword                Alignment fault       Alignment fault

All forms of LDM and STM,
LDRD, RFE, SRS, STRD, SWP
PUSH, except for encodings 
T3 and A2                       Word                      Alignment fault       Alignment fault
POP, except for encodings 
T3 and A2

LDC, LDC2, STC, STC2             Word                      Alignment fault       Alignment fault

VLDM, VLDR, VPOP,
 VPUSH, VSTM, VSTR             Word                      Alignment fault       Alignment fault

VLD1, VLD2, VLD3, VLD4,
 VST1, VST2, VST3, VST4,          Element size                Unaligned access     Alignment fault
 all with standard alignmenta      

VLD1, VLD2, VLD3, VLD4, 
VST1, VST2, VST3, VST4,           As specified by@<align>       Alignment fault       Alignment fault  
all with @<align> specifieda


On ARMv7, the following code can guarantee that if SCRLR.A is 0:
__enable_mmu:
#if defined(CONFIG_ALIGNMENT_TRAP) && __LINUX_ARM_ARCH__ < 6
	orr	r0, r0, #CR_A
#else
	bic	r0, r0, #CR_A         //clear CR_A
#endif
#ifdef CONFIG_CPU_DCACHE_DISABLE
	bic	r0, r0, #CR_C
#endif
#ifdef CONFIG_CPU_BPREDICT_DISABLE
	bic	r0, r0, #CR_Z
#endif
#ifdef CONFIG_CPU_ICACHE_DISABLE
	bic	r0, r0, #CR_I
#endif
#ifdef CONFIG_ARM_LPAE
	mcrr	p15, 0, r4, r5, c2		@ load TTBR0
#else
	mov	r5, #DACR_INIT
	mcr	p15, 0, r5, c3, c0, 0		@ load domain access register
	mcr	p15, 0, r4, c2, c0, 0		@ load page table pointer
#endif
	b	__turn_mmu_on
ENDPROC(__enable_mmu)

/*
 * Enable the MMU.  This completely changes the structure of the visible
 * memory space.  You will not be able to trace execution through this.
 * If you have an enquiry about this, *please* check the linux-arm-kernel
 * mailing list archives BEFORE sending another post to the list.
 *
 *  r0  = cp#15 control register
 *  r1  = machine ID
 *  r2  = atags or dtb pointer
 *  r9  = processor ID
 *  r13 = *virtual* address to jump to upon completion
 *
 * other registers depend on the function called upon completion
 */
	.align	5
	.pushsection	.idmap.text, "ax"
ENTRY(__turn_mmu_on)
	mov	r0, r0
	instr_sync
	mcr	p15, 0, r0, c1, c0, 0		@ write control reg   //here set SCTLR=r0 
	mrc	p15, 0, r3, c0, c0, 0		@ read id reg
	instr_sync
	mov	r3, r3
	mov	r3, r13
	ret	r3
__turn_mmu_on_end:
ENDPROC(__turn_mmu_on)

So the following code is OK:
static __always_inline bool memory_is_poisoned_16(unsigned long addr)
{
-	u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
+	u16 *shadow_addr = get_unaligned( (u16 *)kasan_mem_to_shadow((void *)addr)); 

	/* Unaligned 16-bytes access maps into 3 shadow bytes. */
	if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
		return *shadow_addr || memory_is_poisoned_1(addr + 15);

	return *shadow_addr;
}

A very good suggestion, Thanks.

[PATCH 06/11] change memory_is_poisoned_16 for aligned error

[Ard Biesheuvel]

On 5 December 2017 at 14:19, Liuwenliang (Abbott Liu)
<liuwenliang@huawei.com> wrote:
> On Nov 23, 2017  20:30  Russell King - ARM Linux [mailto:linux at armlinux.org.uk]  wrote:
>>On Thu, Oct 12, 2017 at 11:27:40AM +0000, Liuwenliang (Lamb) wrote:
>>> >> - I don't understand why this is necessary.  memory_is_poisoned_16()
>>> >>   already handles unaligned addresses?
>>> >>
>>> >> - If it's needed on ARM then presumably it will be needed on other
>>> >>   architectures, so CONFIG_ARM is insufficiently general.
>>> >>
>>> >> - If the present memory_is_poisoned_16() indeed doesn't work on ARM,
>>> >>   it would be better to generalize/fix it in some fashion rather than
>>> >>   creating a new variant of the function.
>>>
>>>
>>> >Yes, I think it will be better to fix the current function rather then
>>> >have 2 slightly different copies with ifdef's.
>>> >Will something along these lines work for arm? 16-byte accesses are
>>> >not too common, so it should not be a performance problem. And
>>> >probably modern compilers can turn 2 1-byte checks into a 2-byte check
>>> >where safe (x86).
>>>
>>> >static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>>> >{
>>> >        u8 *shadow_addr = (u8 *)kasan_mem_to_shadow((void *)addr);
>>> >
>>> >        if (shadow_addr[0] || shadow_addr[1])
>>> >                return true;
>>> >        /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>>> >        if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>>> >                return memory_is_poisoned_1(addr + 15);
>>> >        return false;
>>> >}
>>>
>>> Thanks for Andrew Morton and Dmitry Vyukov's review.
>>> If the parameter addr=0xc0000008, now in function:
>>> static __always_inline bool memory_is_poisoned_16(unsigned long addr)
>>> {
>>>  ---     //shadow_addr = (u16 *)(KASAN_OFFSET+0x18000001(=0xc0000008>>3)) is not
>>>  ---     // unsigned by 2 bytes.
>>>         u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>>>
>>>         /* Unaligned 16-bytes access maps into 3 shadow bytes. */
>>>         if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
>>>                 return *shadow_addr || memory_is_poisoned_1(addr + 15);
>>> ----      //here is going to be error on arm, specially when kernel has not finished yet.
>>> ----      //Because the unsigned accessing cause DataAbort Exception which is not
>>> ----      //initialized when kernel is starting.
>>>         return *shadow_addr;
>>> }
>>>
>>> I also think it is better to fix this problem.
>
>>What about using get_unaligned() ?
>
> Thanks for your review.
>
> I think it is good idea to use get_unaligned. But ARMv7 support CONFIG_ HAVE_EFFICIENT_UNALIGNED_ACCESS
> (arch/arm/Kconfig : select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU).
> So on ARMv7, the code:
> u16 *shadow_addr = get_unaligned((u16 *)kasan_mem_to_shadow((void *)addr));
> equals the code:000
> u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
>

No it does not. The compiler may merge adjacent accesses into ldm or
ldrd instructions, which do not tolerate misalignment regardless of
the SCTLR.A bit.

This is actually something we may need to fix for ARM, i.e., drop
HAVE_EFFICIENT_UNALIGNED_ACCESS altogether, or carefully review the
way it is used currently.

> On ARMv7, if SCRLR.A is 0, unaligned access is OK.  Here is the description comes from ARM(r) Architecture Reference
> Manual ARMv7-A and ARMv7-R edition :
>
<snip>

Could you *please* stop quoting the ARM ARM at us? People who are
seeking detailed information like that will know where to find it.

-- 
Ard.

[PATCH 07/11] Avoid cleaning the KASan shadow area's mapping table

[Abbott Liu]

From: Andrey Ryabinin <a.ryabinin@samsung.com>

 Avoid cleaning the mapping table(page table) of KASAN shadow area.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
---
 arch/arm/mm/mmu.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..f5aa1de 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1251,9 +1251,14 @@ static inline void prepare_page_table(void)
 	/*
 	 * Clear out all the mappings below the kernel image.
 	 */
-	for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
+	for (addr = 0; addr < TASK_SIZE; addr += PMD_SIZE)
 		pmd_clear(pmd_off_k(addr));
 
+#ifdef CONFIG_KASAN
+	/*TASK_SIZE ~ MODULES_VADDR is the KASAN's shadow area -- skip over it*/
+	addr = MODULES_VADDR;
+#endif
+
 #ifdef CONFIG_XIP_KERNEL
 	/* The XIP kernel is mapped in the module area -- skip over it */
 	addr = ((unsigned long)_exiprom + PMD_SIZE - 1) & PMD_MASK;
-- 
2.9.0

[PATCH 08/11] Add support arm LPAE

[Abbott Liu]

  On arm LPAE architecture,  the mapping table of KASan shadow memory(if
PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is
0xb6e000000~0xbf000000) can't be filled in do_translation_fault function,
because kasan instrumentation maybe cause do_translation_fault function
accessing KASan shadow memory. The accessing of KASan shadow memory in
do_translation_fault function maybe cause dead circle. So the mapping table
of KASan shadow memory need be copyed in pgd_alloc function.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
---
 arch/arm/mm/pgd.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
index c1c1a5c..4f73978 100644
--- a/arch/arm/mm/pgd.c
+++ b/arch/arm/mm/pgd.c
@@ -64,6 +64,18 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
 	new_pmd = pmd_alloc(mm, new_pud, 0);
 	if (!new_pmd)
 		goto no_pmd;
+#ifdef CONFIG_KASAN
+	/*
+	 *Copy PMD table for KASAN shadow mappings.
+	 */
+	init_pgd = pgd_offset_k(TASK_SIZE); 
+	init_pud = pud_offset(init_pgd, TASK_SIZE);
+	init_pmd = pmd_offset(init_pud, TASK_SIZE);
+	new_pmd = pmd_offset(new_pud,TASK_SIZE);
+	memcpy(new_pmd, init_pmd, (pmd_index(MODULES_VADDR)-pmd_index(TASK_SIZE)) * sizeof(pmd_t));
+	clean_dcache_area(new_pmd,PTRS_PER_PMD*sizeof(pmd_t));
+#endif
+
 #endif
 
 	if (!vectors_high()) {
-- 
2.9.0

[PATCH 09/11] Don't need to map the shadow of KASan's shadow memory

[Abbott Liu]

 Because the KASan's shadow memory don't need to track,so remove the
 mapping code in kasan_init.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
---
 arch/arm/mm/kasan_init.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 2bf0782..7cfdc39 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -218,10 +218,6 @@ void __init kasan_init(void)
 
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 
-	kasan_populate_zero_shadow(
-		kasan_mem_to_shadow((void *)KASAN_SHADOW_START),
-		kasan_mem_to_shadow((void *)KASAN_SHADOW_END));
-
 	kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
 				kasan_mem_to_shadow((void *)-1UL) + 1);
 
-- 
2.9.0

[PATCH 09/11] Don't need to map the shadow of KASan's shadow memory

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 04:22:25PM +0800, Abbott Liu wrote:
>  Because the KASan's shadow memory don't need to track,so remove the
>  mapping code in kasan_init.

Is there a reason why this isn't part of the earlier patch that
introduced the code below?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 09/11] Don't need to map the shadow of KASan's shadow memory

[Liuwenliang (Lamb)]

On 10/19/2017 20:56PM, Russell King - ARM Linux wrote:
>On Wed, Oct 11, 2017 at 04:22:25PM +0800, Abbott Liu wrote:
>>  Because the KASan's shadow memory don't need to track,so remove the  
>> mapping code in kasan_init.
>
>Is there a reason why this isn't part of the earlier patch that introduced the code below?
Thanks for your reviews.
I'm going to change it in the new version.

[PATCH 10/11] Change mapping of kasan_zero_page int readonly

[Abbott Liu]

 Because the kasan_zero_page(which is used as the shadow
 region for some memory that KASan doesn't need to track.) won't be writen
 after kasan_init, so change the mapping of kasan_zero_page into readonly.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
---
 arch/arm/mm/kasan_init.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 7cfdc39..c11826a 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -200,6 +200,7 @@ void __init kasan_init(void)
 {
 	struct memblock_region *reg;
 	u64 orig_ttbr0;
+	int i;
 
 	orig_ttbr0 = cpu_get_ttbr(0);
 
@@ -243,6 +244,17 @@ void __init kasan_init(void)
 	create_mapping((unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR),
 		(unsigned long)kasan_mem_to_shadow((void *)(PKMAP_BASE+PMD_SIZE)),
 		NUMA_NO_NODE);
+
+	/*
+	 * KAsan may reuse the contents of kasan_zero_pte directly, so we
+	 * should make sure that it maps the zero page read-only.
+	 */
+	for (i = 0; i < PTRS_PER_PTE; i++)
+                set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
+                        &kasan_zero_pte[i], pfn_pte(
+                                virt_to_pfn(kasan_zero_page),
+                                __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY)));
+	memset(kasan_zero_page, 0, PAGE_SIZE);
 	cpu_set_ttbr0(orig_ttbr0);
 	flush_cache_all();
 	local_flush_bp_all();
-- 
2.9.0

[PATCH 10/11] Change mapping of kasan_zero_page int readonly

[Florian Fainelli]

On 10/11/2017 01:22 AM, Abbott Liu wrote:
>  Because the kasan_zero_page(which is used as the shadow
>  region for some memory that KASan doesn't need to track.) won't be writen
>  after kasan_init, so change the mapping of kasan_zero_page into readonly.
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> ---
>  arch/arm/mm/kasan_init.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> index 7cfdc39..c11826a 100644
> --- a/arch/arm/mm/kasan_init.c
> +++ b/arch/arm/mm/kasan_init.c
> @@ -200,6 +200,7 @@ void __init kasan_init(void)
>  {
>  	struct memblock_region *reg;
>  	u64 orig_ttbr0;
> +	int i;

Nit: unsigned int i.

>  
>  	orig_ttbr0 = cpu_get_ttbr(0);
>  
> @@ -243,6 +244,17 @@ void __init kasan_init(void)
>  	create_mapping((unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR),
>  		(unsigned long)kasan_mem_to_shadow((void *)(PKMAP_BASE+PMD_SIZE)),
>  		NUMA_NO_NODE);
> +
> +	/*
> +	 * KAsan may reuse the contents of kasan_zero_pte directly, so we
> +	 * should make sure that it maps the zero page read-only.
> +	 */
> +	for (i = 0; i < PTRS_PER_PTE; i++)
> +                set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
> +                        &kasan_zero_pte[i], pfn_pte(
> +                                virt_to_pfn(kasan_zero_page),
> +                                __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN | L_PTE_RDONLY)));
> +	memset(kasan_zero_page, 0, PAGE_SIZE);



>  	cpu_set_ttbr0(orig_ttbr0);
>  	flush_cache_all();
>  	local_flush_bp_all();
> 


-- 
Florian

[PATCH 11/11] Add KASan layout

[Abbott Liu]

Add KASan layout into virtual kernel memory layout.

Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
---
 arch/arm/mm/init.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index ad80548..b490cf4 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -537,6 +537,9 @@ void __init mem_init(void)
 #ifdef CONFIG_MODULES
 			"    modules : 0x%08lx - 0x%08lx   (%4ld MB)\n"
 #endif
+#ifdef CONFIG_KASAN
+			"    kasan   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
+#endif
 			"      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
 			"      .init : 0x%p" " - 0x%p" "   (%4td kB)\n"
 			"      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
@@ -557,6 +560,9 @@ void __init mem_init(void)
 #ifdef CONFIG_MODULES
 			MLM(MODULES_VADDR, MODULES_END),
 #endif
+#ifdef CONFIG_KASAN
+			MLM(KASAN_SHADOW_START, KASAN_SHADOW_END),
+#endif
 
 			MLK_ROUNDUP(_text, _etext),
 			MLK_ROUNDUP(__init_begin, __init_end),
-- 
2.9.0

[PATCH 00/11] KASan for arm

[Florian Fainelli]

Hi Abbott,

On 10/11/2017 01:22 AM, Abbott Liu wrote:
> Hi,all:
>    These patches add 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 user space.
>    
>    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. 
> 
>   On arm LPAE architecture,  the mapping table of KASan shadow memory(if 
> PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is 
> 0xb6e000000~0xbf000000) can't be filled in do_translation_fault function, 
> because kasan instrumentation maybe cause do_translation_fault function 
> accessing KASan shadow memory. The accessing of KASan shadow memory in 
> do_translation_fault function maybe cause dead circle. So the mapping table 
> of KASan shadow memory need be copyed in pgd_alloc function.
> 
> 
> Most of the code comes from:
> https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.

Thanks for putting these patches together, I can't get a kernel to build
with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:

  AS      arch/arm/kernel/entry-common.o
arch/arm/kernel/entry-common.S: Assembler messages:
arch/arm/kernel/entry-common.S:53: Error: invalid constant
(ffffffffb6e00000) after fixup
arch/arm/kernel/entry-common.S:118: Error: invalid constant
(ffffffffb6e00000) after fixup
scripts/Makefile.build:412: recipe for target
'arch/arm/kernel/entry-common.o' failed
make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
Makefile:1019: recipe for target 'arch/arm/kernel' failed
make[2]: *** [arch/arm/kernel] Error 2
make[2]: *** Waiting for unfinished jobs....

This is coming from the increase in TASK_SIZE it seems.

This is on top of v4.14-rc4-84-gff5abbe799e2

Thank you

> 
> These patches are tested on vexpress-ca15, vexpress-ca9
> 
> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
> Tested-by: Abbott Liu <liuwenliang@huawei.com>
> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
> 
> Abbott Liu (6):
>   Define the virtual space of KASan's shadow region
>   change memory_is_poisoned_16 for aligned error
>   Add support arm LPAE
>   Don't need to map the shadow of KASan's shadow memory
>   Change mapping of kasan_zero_page int readonly
>   Add KASan layout
> 
> Andrey Ryabinin (5):
>   Initialize the mapping of KASan shadow memory
>   replace memory function
>   arm: Kconfig: enable KASan
>   Disable kasan's instrumentation
>   Avoid cleaning the KASan shadow area's mapping table
> 
>  arch/arm/Kconfig                   |   1 +
>  arch/arm/boot/compressed/Makefile  |   1 +
>  arch/arm/include/asm/kasan.h       |  20 +++
>  arch/arm/include/asm/kasan_def.h   |  51 +++++++
>  arch/arm/include/asm/memory.h      |   5 +
>  arch/arm/include/asm/pgalloc.h     |   5 +-
>  arch/arm/include/asm/pgtable.h     |   1 +
>  arch/arm/include/asm/proc-fns.h    |  33 +++++
>  arch/arm/include/asm/string.h      |  18 ++-
>  arch/arm/include/asm/thread_info.h |   4 +
>  arch/arm/kernel/entry-armv.S       |   7 +-
>  arch/arm/kernel/head-common.S      |   4 +
>  arch/arm/kernel/setup.c            |   2 +
>  arch/arm/kernel/unwind.c           |   3 +-
>  arch/arm/lib/memcpy.S              |   3 +
>  arch/arm/lib/memmove.S             |   5 +-
>  arch/arm/lib/memset.S              |   3 +
>  arch/arm/mm/Makefile               |   5 +
>  arch/arm/mm/init.c                 |   6 +
>  arch/arm/mm/kasan_init.c           | 265 +++++++++++++++++++++++++++++++++++++
>  arch/arm/mm/mmu.c                  |   7 +-
>  arch/arm/mm/pgd.c                  |  12 ++
>  arch/arm/vdso/Makefile             |   2 +
>  mm/kasan/kasan.c                   |  22 ++-
>  24 files changed, 478 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/include/asm/kasan.h
>  create mode 100644 arch/arm/include/asm/kasan_def.h
>  create mode 100644 arch/arm/mm/kasan_init.c
> 


-- 
Florian

[PATCH 00/11] KASan for arm

[Florian Fainelli]

On 10/11/2017 12:13 PM, Florian Fainelli wrote:
> Hi Abbott,
> 
> On 10/11/2017 01:22 AM, Abbott Liu wrote:
>> Hi,all:
>>    These patches add 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 user space.
>>    
>>    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. 
>>
>>   On arm LPAE architecture,  the mapping table of KASan shadow memory(if 
>> PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is 
>> 0xb6e000000~0xbf000000) can't be filled in do_translation_fault function, 
>> because kasan instrumentation maybe cause do_translation_fault function 
>> accessing KASan shadow memory. The accessing of KASan shadow memory in 
>> do_translation_fault function maybe cause dead circle. So the mapping table 
>> of KASan shadow memory need be copyed in pgd_alloc function.
>>
>>
>> Most of the code comes from:
>> https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
> 
> Thanks for putting these patches together, I can't get a kernel to build
> with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:
> 
>   AS      arch/arm/kernel/entry-common.o
> arch/arm/kernel/entry-common.S: Assembler messages:
> arch/arm/kernel/entry-common.S:53: Error: invalid constant
> (ffffffffb6e00000) after fixup
> arch/arm/kernel/entry-common.S:118: Error: invalid constant
> (ffffffffb6e00000) after fixup
> scripts/Makefile.build:412: recipe for target
> 'arch/arm/kernel/entry-common.o' failed
> make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
> Makefile:1019: recipe for target 'arch/arm/kernel' failed
> make[2]: *** [arch/arm/kernel] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> This is coming from the increase in TASK_SIZE it seems.
> 
> This is on top of v4.14-rc4-84-gff5abbe799e2

Seems like we can use the following to get through that build failure:

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 99c908226065..0de1160d136e 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -50,7 +50,13 @@ ret_fast_syscall:
  UNWIND(.cantunwind    )
        disable_irq_notrace                     @ disable interrupts
        ldr     r2, [tsk, #TI_ADDR_LIMIT]
+#ifdef CONFIG_KASAN
+       movw    r1, #:lower16:TASK_SIZE
+       movt    r1, #:upper16:TASK_SIZE
+       cmp     r2, r1
+#else
        cmp     r2, #TASK_SIZE
+#endif
        blne    addr_limit_check_failed
        ldr     r1, [tsk, #TI_FLAGS]            @ re-check for syscall
tracing
        tst     r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -115,7 +121,13 @@ ret_slow_syscall:
        disable_irq_notrace                     @ disable interrupts
 ENTRY(ret_to_user_from_irq)
        ldr     r2, [tsk, #TI_ADDR_LIMIT]
+#ifdef CONFIG_KASAN
+       movw    r1, #:lower16:TASK_SIZE
+       movt    r1, #:upper16:TASK_SIZE
+       cmp     r2, r1
+#else
        cmp     r2, #TASK_SIZE
+#endif
        blne    addr_limit_check_failed
        ldr     r1, [tsk, #TI_FLAGS]
        tst     r1, #_TIF_WORK_MASK



but then we will see another set of build failures with the decompressor
code:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  KSYM    .tmp_kallsyms1.o
  KSYM    .tmp_kallsyms2.o
  LD      vmlinux
  SORTEX  vmlinux
  SYSMAP  System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  LDS     arch/arm/boot/compressed/vmlinux.lds
  AS      arch/arm/boot/compressed/head.o
  XZKERN  arch/arm/boot/compressed/piggy_data
  CC      arch/arm/boot/compressed/misc.o
  CC      arch/arm/boot/compressed/decompress.o
  CC      arch/arm/boot/compressed/string.o
arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
 #define memmove memmove

In file included from arch/arm/boot/compressed/decompress.c:7:0:
./arch/arm/include/asm/string.h:67:0: note: this is the location of the
previous definition
 #define memmove(dst, src, len) __memmove(dst, src, len)

arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
 #define memcpy memcpy

In file included from arch/arm/boot/compressed/decompress.c:7:0:
./arch/arm/include/asm/string.h:66:0: note: this is the location of the
previous definition
 #define memcpy(dst, src, len) __memcpy(dst, src, len)

  SHIPPED arch/arm/boot/compressed/hyp-stub.S
  SHIPPED arch/arm/boot/compressed/fdt_rw.c
  SHIPPED arch/arm/boot/compressed/fdt.h
  SHIPPED arch/arm/boot/compressed/libfdt.h
  SHIPPED arch/arm/boot/compressed/libfdt_internal.h
  SHIPPED arch/arm/boot/compressed/fdt_ro.c
  SHIPPED arch/arm/boot/compressed/fdt_wip.c
  SHIPPED arch/arm/boot/compressed/fdt.c
  CC      arch/arm/boot/compressed/atags_to_fdt.o
  SHIPPED arch/arm/boot/compressed/lib1funcs.S
  SHIPPED arch/arm/boot/compressed/ashldi3.S
  SHIPPED arch/arm/boot/compressed/bswapsdi2.S
  AS      arch/arm/boot/compressed/hyp-stub.o
  CC      arch/arm/boot/compressed/fdt_rw.o
  CC      arch/arm/boot/compressed/fdt_ro.o
  CC      arch/arm/boot/compressed/fdt_wip.o
  CC      arch/arm/boot/compressed/fdt.o
  AS      arch/arm/boot/compressed/lib1funcs.o
  AS      arch/arm/boot/compressed/ashldi3.o
  AS      arch/arm/boot/compressed/bswapsdi2.o
  AS      arch/arm/boot/compressed/piggy.o
  LD      arch/arm/boot/compressed/vmlinux
arch/arm/boot/compressed/decompress.o: In function `fill_temp':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `bcj_flush':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:404:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:409:
undefined reference to `memmove'
arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:919:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `dict_flush':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:424:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `dict_uncompressed':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:390:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:400:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:859:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:884:
undefined reference to `memmove'
arch/arm/boot/compressed/decompress.o: In function `xz_dec_bcj_run':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:451:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:471:
undefined reference to `memcpy'
arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
/home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
undefined reference to `__memset'
arch/arm/boot/compressed/Makefile:182: recipe for target
'arch/arm/boot/compressed/vmlinux' failed
make[4]: *** [arch/arm/boot/compressed/vmlinux] Error 1
arch/arm/boot/Makefile:53: recipe for target
'arch/arm/boot/compressed/vmlinux' failed
make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 2

> 
> Thank you
> 
>>
>> These patches are tested on vexpress-ca15, vexpress-ca9
>>
>> Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
>> Tested-by: Abbott Liu <liuwenliang@huawei.com>
>> Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
>>
>> Abbott Liu (6):
>>   Define the virtual space of KASan's shadow region
>>   change memory_is_poisoned_16 for aligned error
>>   Add support arm LPAE
>>   Don't need to map the shadow of KASan's shadow memory
>>   Change mapping of kasan_zero_page int readonly
>>   Add KASan layout
>>
>> Andrey Ryabinin (5):
>>   Initialize the mapping of KASan shadow memory
>>   replace memory function
>>   arm: Kconfig: enable KASan
>>   Disable kasan's instrumentation
>>   Avoid cleaning the KASan shadow area's mapping table
>>
>>  arch/arm/Kconfig                   |   1 +
>>  arch/arm/boot/compressed/Makefile  |   1 +
>>  arch/arm/include/asm/kasan.h       |  20 +++
>>  arch/arm/include/asm/kasan_def.h   |  51 +++++++
>>  arch/arm/include/asm/memory.h      |   5 +
>>  arch/arm/include/asm/pgalloc.h     |   5 +-
>>  arch/arm/include/asm/pgtable.h     |   1 +
>>  arch/arm/include/asm/proc-fns.h    |  33 +++++
>>  arch/arm/include/asm/string.h      |  18 ++-
>>  arch/arm/include/asm/thread_info.h |   4 +
>>  arch/arm/kernel/entry-armv.S       |   7 +-
>>  arch/arm/kernel/head-common.S      |   4 +
>>  arch/arm/kernel/setup.c            |   2 +
>>  arch/arm/kernel/unwind.c           |   3 +-
>>  arch/arm/lib/memcpy.S              |   3 +
>>  arch/arm/lib/memmove.S             |   5 +-
>>  arch/arm/lib/memset.S              |   3 +
>>  arch/arm/mm/Makefile               |   5 +
>>  arch/arm/mm/init.c                 |   6 +
>>  arch/arm/mm/kasan_init.c           | 265 +++++++++++++++++++++++++++++++++++++
>>  arch/arm/mm/mmu.c                  |   7 +-
>>  arch/arm/mm/pgd.c                  |  12 ++
>>  arch/arm/vdso/Makefile             |   2 +
>>  mm/kasan/kasan.c                   |  22 ++-
>>  24 files changed, 478 insertions(+), 7 deletions(-)
>>  create mode 100644 arch/arm/include/asm/kasan.h
>>  create mode 100644 arch/arm/include/asm/kasan_def.h
>>  create mode 100644 arch/arm/mm/kasan_init.c
>>
> 
> 


-- 
Florian

[PATCH 00/11] KASan for arm

[Laura Abbott]

On 10/11/2017 02:36 PM, Florian Fainelli wrote:
> On 10/11/2017 12:50 PM, Florian Fainelli wrote:
>> On 10/11/2017 12:13 PM, Florian Fainelli wrote:
>>> Hi Abbott,
>>>
>>> On 10/11/2017 01:22 AM, Abbott Liu wrote:
>>>> Hi,all:
>>>>    These patches add 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 user space.
>>>>    
>>>>    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. 
>>>>
>>>>   On arm LPAE architecture,  the mapping table of KASan shadow memory(if 
>>>> PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is 
>>>> 0xb6e000000~0xbf000000) can't be filled in do_translation_fault function, 
>>>> because kasan instrumentation maybe cause do_translation_fault function 
>>>> accessing KASan shadow memory. The accessing of KASan shadow memory in 
>>>> do_translation_fault function maybe cause dead circle. So the mapping table 
>>>> of KASan shadow memory need be copyed in pgd_alloc function.
>>>>
>>>>
>>>> Most of the code comes from:
>>>> https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
>>>
>>> Thanks for putting these patches together, I can't get a kernel to build
>>> with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:
>>>
>>>   AS      arch/arm/kernel/entry-common.o
>>> arch/arm/kernel/entry-common.S: Assembler messages:
>>> arch/arm/kernel/entry-common.S:53: Error: invalid constant
>>> (ffffffffb6e00000) after fixup
>>> arch/arm/kernel/entry-common.S:118: Error: invalid constant
>>> (ffffffffb6e00000) after fixup
>>> scripts/Makefile.build:412: recipe for target
>>> 'arch/arm/kernel/entry-common.o' failed
>>> make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
>>> Makefile:1019: recipe for target 'arch/arm/kernel' failed
>>> make[2]: *** [arch/arm/kernel] Error 2
>>> make[2]: *** Waiting for unfinished jobs....
>>>
>>> This is coming from the increase in TASK_SIZE it seems.
>>>
>>> This is on top of v4.14-rc4-84-gff5abbe799e2
>>
>> Seems like we can use the following to get through that build failure:
>>
>> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
>> index 99c908226065..0de1160d136e 100644
>> --- a/arch/arm/kernel/entry-common.S
>> +++ b/arch/arm/kernel/entry-common.S
>> @@ -50,7 +50,13 @@ ret_fast_syscall:
>>   UNWIND(.cantunwind    )
>>         disable_irq_notrace                     @ disable interrupts
>>         ldr     r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +       movw    r1, #:lower16:TASK_SIZE
>> +       movt    r1, #:upper16:TASK_SIZE
>> +       cmp     r2, r1
>> +#else
>>         cmp     r2, #TASK_SIZE
>> +#endif
>>         blne    addr_limit_check_failed
>>         ldr     r1, [tsk, #TI_FLAGS]            @ re-check for syscall
>> tracing
>>         tst     r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
>> @@ -115,7 +121,13 @@ ret_slow_syscall:
>>         disable_irq_notrace                     @ disable interrupts
>>  ENTRY(ret_to_user_from_irq)
>>         ldr     r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +       movw    r1, #:lower16:TASK_SIZE
>> +       movt    r1, #:upper16:TASK_SIZE
>> +       cmp     r2, r1
>> +#else
>>         cmp     r2, #TASK_SIZE
>> +#endif
>>         blne    addr_limit_check_failed
>>         ldr     r1, [tsk, #TI_FLAGS]
>>         tst     r1, #_TIF_WORK_MASK
>>
>>
>>
>> but then we will see another set of build failures with the decompressor
>> code:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>   KSYM    .tmp_kallsyms1.o
>>   KSYM    .tmp_kallsyms2.o
>>   LD      vmlinux
>>   SORTEX  vmlinux
>>   SYSMAP  System.map
>>   OBJCOPY arch/arm/boot/Image
>>   Kernel: arch/arm/boot/Image is ready
>>   LDS     arch/arm/boot/compressed/vmlinux.lds
>>   AS      arch/arm/boot/compressed/head.o
>>   XZKERN  arch/arm/boot/compressed/piggy_data
>>   CC      arch/arm/boot/compressed/misc.o
>>   CC      arch/arm/boot/compressed/decompress.o
>>   CC      arch/arm/boot/compressed/string.o
>> arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
>>  #define memmove memmove
>>
>> In file included from arch/arm/boot/compressed/decompress.c:7:0:
>> ./arch/arm/include/asm/string.h:67:0: note: this is the location of the
>> previous definition
>>  #define memmove(dst, src, len) __memmove(dst, src, len)
>>
>> arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
>>  #define memcpy memcpy
>>
>> In file included from arch/arm/boot/compressed/decompress.c:7:0:
>> ./arch/arm/include/asm/string.h:66:0: note: this is the location of the
>> previous definition
>>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>>
>>   SHIPPED arch/arm/boot/compressed/hyp-stub.S
>>   SHIPPED arch/arm/boot/compressed/fdt_rw.c
>>   SHIPPED arch/arm/boot/compressed/fdt.h
>>   SHIPPED arch/arm/boot/compressed/libfdt.h
>>   SHIPPED arch/arm/boot/compressed/libfdt_internal.h
>>   SHIPPED arch/arm/boot/compressed/fdt_ro.c
>>   SHIPPED arch/arm/boot/compressed/fdt_wip.c
>>   SHIPPED arch/arm/boot/compressed/fdt.c
>>   CC      arch/arm/boot/compressed/atags_to_fdt.o
>>   SHIPPED arch/arm/boot/compressed/lib1funcs.S
>>   SHIPPED arch/arm/boot/compressed/ashldi3.S
>>   SHIPPED arch/arm/boot/compressed/bswapsdi2.S
>>   AS      arch/arm/boot/compressed/hyp-stub.o
>>   CC      arch/arm/boot/compressed/fdt_rw.o
>>   CC      arch/arm/boot/compressed/fdt_ro.o
>>   CC      arch/arm/boot/compressed/fdt_wip.o
>>   CC      arch/arm/boot/compressed/fdt.o
>>   AS      arch/arm/boot/compressed/lib1funcs.o
>>   AS      arch/arm/boot/compressed/ashldi3.o
>>   AS      arch/arm/boot/compressed/bswapsdi2.o
>>   AS      arch/arm/boot/compressed/piggy.o
>>   LD      arch/arm/boot/compressed/vmlinux
>> arch/arm/boot/compressed/decompress.o: In function `fill_temp':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `bcj_flush':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:404:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:409:
>> undefined reference to `memmove'
>> arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:919:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `dict_flush':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:424:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `dict_uncompressed':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:390:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:400:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:859:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:884:
>> undefined reference to `memmove'
>> arch/arm/boot/compressed/decompress.o: In function `xz_dec_bcj_run':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:451:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:471:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
>> undefined reference to `__memset'
>> arch/arm/boot/compressed/Makefile:182: recipe for target
>> 'arch/arm/boot/compressed/vmlinux' failed
>> make[4]: *** [arch/arm/boot/compressed/vmlinux] Error 1
>> arch/arm/boot/Makefile:53: recipe for target
>> 'arch/arm/boot/compressed/vmlinux' failed
>> make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 2
> 
> I ended up fixing the redefinition warnings/build failures this way, but
> I am not 100% confident this is the right fix:
> 
> diff --git a/arch/arm/boot/compressed/decompress.c
> b/arch/arm/boot/compressed/decompress.c
> index f3a4bedd1afc..7d4a47752760 100644
> --- a/arch/arm/boot/compressed/decompress.c
> +++ b/arch/arm/boot/compressed/decompress.c
> @@ -48,8 +48,10 @@ extern int memcmp(const void *cs, const void *ct,
> size_t count);
>  #endif
> 
>  #ifdef CONFIG_KERNEL_XZ
> +#ifndef CONFIG_KASAN
>  #define memmove memmove
>  #define memcpy memcpy
> +#endif
>  #include "../../../../lib/decompress_unxz.c"
>  #endif
> 
> Was not able yet to track down why __memset is not being resolved, but
> since I don't need them, disabled CONFIG_ATAGS and
> CONFIG_ARM_ATAG_DTB_COMPAT and this allowed me to get a build working.
> 
> This brought me all the way to a prompt and please find attached the
> results of insmod test_kasan.ko for CONFIG_ARM_LPAE=y and
> CONFIG_ARM_LPAE=n. Your patches actually spotted a genuine use after
> free in one of our drivers (spi-bcm-qspi) so with this:
> 
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Great job thanks!
> 

The memset failure comes from the fact that the decompressor has
its own string functions and there is an #undefine memset in there.
The git history doesn't make it clear where this comes from but
if I remove it the kernel at least compiles for me with the
multi_v7_defconfig.

Thanks,
Laura

[PATCH 00/11] KASan for arm

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 03:10:56PM -0700, Laura Abbott wrote:
> On 10/11/2017 02:36 PM, Florian Fainelli wrote:
> >>   CC      arch/arm/boot/compressed/string.o
> >> arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
> >>  #define memmove memmove
> >>
> >> In file included from arch/arm/boot/compressed/decompress.c:7:0:
> >> ./arch/arm/include/asm/string.h:67:0: note: this is the location of the
> >> previous definition
> >>  #define memmove(dst, src, len) __memmove(dst, src, len)
> >>
> >> arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
> >>  #define memcpy memcpy
> >>
> >> In file included from arch/arm/boot/compressed/decompress.c:7:0:
> >> ./arch/arm/include/asm/string.h:66:0: note: this is the location of the
> >> previous definition
> >>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
> >>
> > 
> > Was not able yet to track down why __memset is not being resolved, but
> > since I don't need them, disabled CONFIG_ATAGS and
> > CONFIG_ARM_ATAG_DTB_COMPAT and this allowed me to get a build working.
> > 
> > This brought me all the way to a prompt and please find attached the
> > results of insmod test_kasan.ko for CONFIG_ARM_LPAE=y and
> > CONFIG_ARM_LPAE=n. Your patches actually spotted a genuine use after
> > free in one of our drivers (spi-bcm-qspi) so with this:
> > 
> > Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> > 
> > Great job thanks!
> > 
> 
> The memset failure comes from the fact that the decompressor has
> its own string functions and there is an #undefine memset in there.
> The git history doesn't make it clear where this comes from but
> if I remove it the kernel at least compiles for me with the
> multi_v7_defconfig.

The decompressor does not link with the standard C library, so it
needs to provide implementations of standard C library functionality
where required.  That means, if we have any memset() users, we need
to provide the memset() function.

The undef is there to avoid the optimisation we have in asm/string.h
for __memzero, because we don't want to use __memzero in the
decompressor.

Whether memset() is required depends on which compression method is
being used - LZO and LZ4 appear to make direct references to it, but
the inflate (gzip) decompressor code does not.

What this means is that all supported kernel compression options need
to be tested.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 00/11] KASan for arm

[Liuwenliang (Lamb)]

On 10/17/2017 7:40 PM, Abbott Liu wrote:
>On Wed, Oct 11, 2017 at 03:10:56PM -0700, Laura Abbott wrote:
>The decompressor does not link with the standard C library, so it
>needs to provide implementations of standard C library functionality
>where required.  That means, if we have any memset() users, we need
>to provide the memset() function.
>
>The undef is there to avoid the optimisation we have in asm/string.h
>for __memzero, because we don't want to use __memzero in the
>decompressor.
>
>Whether memset() is required depends on which compression method is
>being used - LZO and LZ4 appear to make direct references to it, but
>the inflate (gzip) decompressor code does not.
>
>What this means is that all supported kernel compression options need
>to be tested.

Thanks for your review. I am sorry that I am so late to reply your email.
I will test all arm kernel compression options.

[PATCH 00/11] KASan for arm

[Liuwenliang (Lamb)]

On 10/12/2017 12:10 AM, Abbott Liu wrote:
>On 10/11/2017 12:50 PM, Florian Fainelli wrote:
>> On 10/11/2017 12:13 PM, Florian Fainelli wrote:
>>> Hi Abbott,
>>>
>>> On 10/11/2017 01:22 AM, Abbott Liu wrote:
>>>> Hi,all:
>>>>    These patches add 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 user space.
>>>>
>>>>    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.
>>>>
>>>>   On arm LPAE architecture,  the mapping table of KASan shadow memory(if
>>>> PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is
>>>> 0xb6e000000~0xbf000000) can't be filled in do_translation_fault function,
>>>> because kasan instrumentation maybe cause do_translation_fault function
>>>> accessing KASan shadow memory. The accessing of KASan shadow memory in
>>>> do_translation_fault function maybe cause dead circle. So the mapping table
>>>> of KASan shadow memory need be copyed in pgd_alloc function.
>>>>
>>>>
>>>> Most of the code comes from:
>>>> https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
>>>
>>> Thanks for putting these patches together, I can't get a kernel to build
>>> with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:
>>>
>>>   AS      arch/arm/kernel/entry-common.o
>>> arch/arm/kernel/entry-common.S: Assembler messages:
>>> arch/arm/kernel/entry-common.S:53: Error: invalid constant
>>> (ffffffffb6e00000) after fixup
>>> arch/arm/kernel/entry-common.S:118: Error: invalid constant
>>> (ffffffffb6e00000) after fixup
>>> scripts/Makefile.build:412: recipe for target
>>> 'arch/arm/kernel/entry-common.o' failed
>>> make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
>>> Makefile:1019: recipe for target 'arch/arm/kernel' failed
>>> make[2]: *** [arch/arm/kernel] Error 2
>>> make[2]: *** Waiting for unfinished jobs....
>>>
>>> This is coming from the increase in TASK_SIZE it seems.
>>>
>>> This is on top of v4.14-rc4-84-gff5abbe799e2
>>
>> Seems like we can use the following to get through that build failure:
>>
>> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
>> index 99c908226065..0de1160d136e 100644
>> --- a/arch/arm/kernel/entry-common.S
>> +++ b/arch/arm/kernel/entry-common.S
>> @@ -50,7 +50,13 @@ ret_fast_syscall:
>>   UNWIND(.cantunwind    )
>>         disable_irq_notrace                     @ disable interrupts
>>         ldr     r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +       movw    r1, #:lower16:TASK_SIZE
>> +       movt    r1, #:upper16:TASK_SIZE
>> +       cmp     r2, r1
>> +#else
>>         cmp     r2, #TASK_SIZE
>> +#endif
>>         blne    addr_limit_check_failed
>>         ldr     r1, [tsk, #TI_FLAGS]            @ re-check for syscall
>> tracing
>>         tst     r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
>> @@ -115,7 +121,13 @@ ret_slow_syscall:
>>         disable_irq_notrace                     @ disable interrupts
>>  ENTRY(ret_to_user_from_irq)
>>         ldr     r2, [tsk, #TI_ADDR_LIMIT]
>> +#ifdef CONFIG_KASAN
>> +       movw    r1, #:lower16:TASK_SIZE
>> +       movt    r1, #:upper16:TASK_SIZE
>> +       cmp     r2, r1
>> +#else
>>         cmp     r2, #TASK_SIZE
>> +#endif
>>         blne    addr_limit_check_failed
>>         ldr     r1, [tsk, #TI_FLAGS]
>>         tst     r1, #_TIF_WORK_MASK
>>
>>
>>
>> but then we will see another set of build failures with the decompressor
>> code:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>   KSYM    .tmp_kallsyms1.o
>>   KSYM    .tmp_kallsyms2.o
>>   LD      vmlinux
>>   SORTEX  vmlinux
>>   SYSMAP  System.map
>>   OBJCOPY arch/arm/boot/Image
>>   Kernel: arch/arm/boot/Image is ready
>>   LDS     arch/arm/boot/compressed/vmlinux.lds
>>   AS      arch/arm/boot/compressed/head.o
>>   XZKERN  arch/arm/boot/compressed/piggy_data
>>   CC      arch/arm/boot/compressed/misc.o
>>   CC      arch/arm/boot/compressed/decompress.o
>>   CC      arch/arm/boot/compressed/string.o
>> arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
>>  #define memmove memmove
>>
>> In file included from arch/arm/boot/compressed/decompress.c:7:0:
>> ./arch/arm/include/asm/string.h:67:0: note: this is the location of the
>> previous definition
>>  #define memmove(dst, src, len) __memmove(dst, src, len)
>>
>> arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
>>  #define memcpy memcpy
>>
>> In file included from arch/arm/boot/compressed/decompress.c:7:0:
>> ./arch/arm/include/asm/string.h:66:0: note: this is the location of the
>> previous definition
>>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>>
>>   SHIPPED arch/arm/boot/compressed/hyp-stub.S
>>   SHIPPED arch/arm/boot/compressed/fdt_rw.c
>>   SHIPPED arch/arm/boot/compressed/fdt.h
>>   SHIPPED arch/arm/boot/compressed/libfdt.h
>>   SHIPPED arch/arm/boot/compressed/libfdt_internal.h
>>   SHIPPED arch/arm/boot/compressed/fdt_ro.c
>>   SHIPPED arch/arm/boot/compressed/fdt_wip.c
>>   SHIPPED arch/arm/boot/compressed/fdt.c
>>   CC      arch/arm/boot/compressed/atags_to_fdt.o
>>   SHIPPED arch/arm/boot/compressed/lib1funcs.S
>>   SHIPPED arch/arm/boot/compressed/ashldi3.S
>>   SHIPPED arch/arm/boot/compressed/bswapsdi2.S
>>   AS      arch/arm/boot/compressed/hyp-stub.o
>>   CC      arch/arm/boot/compressed/fdt_rw.o
>>   CC      arch/arm/boot/compressed/fdt_ro.o
>>   CC      arch/arm/boot/compressed/fdt_wip.o
>>   CC      arch/arm/boot/compressed/fdt.o
>>   AS      arch/arm/boot/compressed/lib1funcs.o
>>   AS      arch/arm/boot/compressed/ashldi3.o
>>   AS      arch/arm/boot/compressed/bswapsdi2.o
>>   AS      arch/arm/boot/compressed/piggy.o
>>   LD      arch/arm/boot/compressed/vmlinux
>> arch/arm/boot/compressed/decompress.o: In function `fill_temp':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `bcj_flush':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:404:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:409:
>> undefined reference to `memmove'
>> arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:919:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `dict_flush':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:424:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `dict_uncompressed':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:390:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:400:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:859:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:884:
>> undefined reference to `memmove'
>> arch/arm/boot/compressed/decompress.o: In function `xz_dec_bcj_run':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:451:
>> undefined reference to `memcpy'
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:471:
>> undefined reference to `memcpy'
>> arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
>> /home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
>> undefined reference to `__memset'
>> arch/arm/boot/compressed/Makefile:182: recipe for target
>> 'arch/arm/boot/compressed/vmlinux' failed
>> make[4]: *** [arch/arm/boot/compressed/vmlinux] Error 1
>> arch/arm/boot/Makefile:53: recipe for target
>> 'arch/arm/boot/compressed/vmlinux' failed
>> make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 2

>I ended up fixing the redefinition warnings/build failures this way, but
>I am not 100% confident this is the right fix:

>diff --git a/arch/arm/boot/compressed/decompress.c
>b/arch/arm/boot/compressed/decompress.c
>index f3a4bedd1afc..7d4a47752760 100644
>--- a/arch/arm/boot/compressed/decompress.c
>+++ b/arch/arm/boot/compressed/decompress.c
>@@ -48,8 +48,10 @@ extern int memcmp(const void *cs, const void *ct,
>size_t count);
> #endif
>
> #ifdef CONFIG_KERNEL_XZ
>+#ifndef CONFIG_KASAN
> #define memmove memmove
> #define memcpy memcpy
>+#endif
> #include "../../../../lib/decompress_unxz.c"
> #endif
>
>Was not able yet to track down why __memset is not being resolved, but
>since I don't need them, disabled CONFIG_ATAGS and
>CONFIG_ARM_ATAG_DTB_COMPAT and this allowed me to get a build working.
>
>This brought me all the way to a prompt and please find attached the
>results of insmod test_kasan.ko for CONFIG_ARM_LPAE=y and
>CONFIG_ARM_LPAE=n. Your patches actually spotted a genuine use after
>free in one of our drivers (spi-bcm-qspi) so with this:
>
>Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
>Great job thanks!
>--
>Florian

Thanks for your testing and solution. I'm sorry that I don't test when CONFIG_ATAGS,
CONFIG_ARM_ATAG_DTB_COMPAT and CONFIG_KERNEL_XZ are enabling.

The fellow error:
arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
/home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
undefined reference to `__memset'

It can be resolved by the code of Andrey Ryabinin <a.ryabinin@samsung.com> on
https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
Here is the patch:

--- a/arch/arm/boot/compressed/libfdt_env.h
+++ b/arch/arm/boot/compressed/libfdt_env.h
@@ -16,4 +16,6 @@ typedef __be64 fdt64_t;
 #define fdt64_to_cpu(x)                be64_to_cpu(x)
 #define cpu_to_fdt64(x)                cpu_to_be64(x)

+#undef memset
+
 #endif

I delete it because I don't know that is needed when CONFIG_ATAGS and 
CONFIG_ARM_ATAG_DTB_COMPAT are enabling. I'm sorry for my fault.

[PATCH 00/11] KASan for arm

[Arnd Bergmann]

On Wed, Oct 11, 2017 at 10:22 AM, Abbott Liu <liuwenliang@huawei.com> wrote:
> Hi,all:
>    These patches add arch specific code for kernel address sanitizer
> (see Documentation/kasan.txt).

Nice!

When I build-tested KASAN on x86 and arm64, I ran into a lot of build-time
regressions (mostly warnings but also some errors), so I'd like to give it
a spin in my randconfig tree before this gets merged. Can you point me
to a git URL that I can pull into my testing tree?

I could of course apply the patches from email, but I expect that there
will be updated versions of the series, so it's easier if I can just pull
the latest version.

      Arnd

答复: [PATCH 00/11] KASan for arm

[Liuwenliang (Lamb)]

On 10/16/2017 07:57 PM, Abbott Liu wrote:
>Nice!
>
>When I build-tested KASAN on x86 and arm64, I ran into a lot of build-time
>regressions (mostly warnings but also some errors), so I'd like to give it
>a spin in my randconfig tree before this gets merged. Can you point me
>to a git URL that I can pull into my testing tree?
>
>I could of course apply the patches from email, but I expect that there
>will be updated versions of the series, so it's easier if I can just pull
>the latest version.
>
>      Arnd

I'm sorry. I don't have git server. These patches base on:
1. git remote -v
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)

2. the commit is:
commit 46c1e79fee417f151547aa46fae04ab06cb666f4
Merge: ec846ec b130a69
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Sep 13 12:24:20 2017 -0700

    Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

    Pull perf fixes from Ingo Molnar:
     "A handful of tooling fixes"

    * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
      perf stat: Wait for the correct child
      perf tools: Support running perf binaries with a dash in their name
      perf config: Check not only section->from_system_config but also item's
      perf ui progress: Fix progress update
      perf ui progress: Make sure we always define step value
      perf tools: Open perf.data with O_CLOEXEC flag
      tools lib api: Fix make DEBUG=1 build
      perf tests: Fix compile when libunwind's unwind.h is available
      tools include linux: Guard against redefinition of some macros
I'm sorry that I didn't base on a stabe version.

3. config: arch/arm/configs/vexpress_defconfig

4. gcc version: gcc version 6.1.0

[PATCH 00/11] KASan for arm

[Florian Fainelli]

Hi Abbott,

On 10/11/2017 01:22 AM, Abbott Liu wrote:
> Hi,all:
>    These patches add 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 user space.
>    
>    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. 
> 
>   On arm LPAE architecture,  the mapping table of KASan shadow memory(if 
> PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is 
> 0xb6e000000~0xbf000000) can't be filled in do_translation_fault function, 
> because kasan instrumentation maybe cause do_translation_fault function 
> accessing KASan shadow memory. The accessing of KASan shadow memory in 
> do_translation_fault function maybe cause dead circle. So the mapping table 
> of KASan shadow memory need be copyed in pgd_alloc function.
> 
> 
> Most of the code comes from:
> https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.

Are you planning on picking up these patches and sending a second
version? I would be more than happy to provide test results once you
have something, this is very useful, thank you!
-- 
Florian

[PATCH 00/11] KASan for arm

[Liuwenliang (Abbott Liu)]

On 2018/2/14  2:41 AM, Florian Fainelli [f.fainelli at gmail.com] wrote:
>Hi Abbott,
>
>Are you planning on picking up these patches and sending a second
>version? I would be more than happy to provide test results once you
>have something, this is very useful, thank you!
>-- 
>Florian

I'm sorry to reply you so late. I had a holiday on last few days.
Yes, I will send the second version, maybe on next two weeks.