* [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 16:45 ` Florian Fainelli
2020-10-02 11:01 ` Ard Biesheuvel
2020-10-01 15:22 ` [PATCH 2/6 v14] ARM: Disable KASan instrumentation for some code Linus Walleij
` (6 subsequent siblings)
7 siblings, 2 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Linus Walleij, Arnd Bergmann, linux-arm-kernel
If the kernel grows big, it can happen that the kernel does not
fit in the first memory block. This is normally out-of-spec
but it turns out that the boot usually survives this.
What it does not survive is that the prepare_page_table() code
wipes all PMDs (page table pointers for the virtual memory)
over lowmem, including the PMD where the attached DTB is
stored. (The variable is named atags but this only really
happens for DTBs.)
Let's deal with this.
First, this makes the code jump over two PMDs where the DTB
is stored if it ends up in lowmem: it could happen that the
DTB crosses a PMD_SIZE boundary so to be on the safe side we
need to skip over the one we know it starts in and also the
next.
Next we make ARM use unflatten_and_copy_device_tree() instead
of just unflattening it where it is. Currently we just assume
that the device tree will be in some kind of "safe" memory and
as proven by KASan it will sometimes end up in the kernel lowmem
which will create crashes as the kernel will clear all lowmem
PMDs while initializing the memory manager.
Finally, we add a new call to the MMU code to go in and clear
out the PMDs in lowmem if the device tree was there.
Example boot log on an affected system:
ATAGs/DTB found in lowmem, skip clearing PMD @0xc3000000
ATAGs/DTB found in lowmem, skip clearing PMD @0xc3200000
(...)
DTB @430af0e0 (physical) copied to @cc394d80 (virtual)
Clear ATAGs/DTB PMD @0xc3000000
Clear ATAGs/DTB PMD @0xc3200000
This fixes the problem where the Qualcomm APQ8060 would not
boot while using KASan.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- New patch fixing the regression when using KASan on at least
one of the affected platforms.
---
arch/arm/include/asm/prom.h | 5 +++++
arch/arm/kernel/devtree.c | 14 +++++++++++++-
arch/arm/kernel/setup.c | 8 ++++++--
arch/arm/mm/mmu.c | 37 +++++++++++++++++++++++++++++++++++--
4 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index 1e36c40533c1..41e189a2631c 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -11,6 +11,7 @@
extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void __init arm_dt_init_cpu_maps(void);
+void __init setup_machine_copy_fdt(unsigned int dt_phys);
#else /* CONFIG_OF */
@@ -21,5 +22,9 @@ static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_init_cpu_maps(void) { }
+static inline void setup_machine_copy_fdt(unsigned int dt_phys)
+{
+}
+
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 39c978698406..267011e133a7 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -23,7 +23,7 @@
#include <asm/smp_plat.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
-
+#include <asm/mach/map.h>
#ifdef CONFIG_SMP
extern struct of_cpu_method __cpu_method_of_table[];
@@ -257,3 +257,15 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
return mdesc;
}
+
+extern void arm_mm_clear_atag_pages(void);
+
+void __init setup_machine_copy_fdt(unsigned int dt_phys)
+{
+ /* This will point the DT parser to the new location */
+ unflatten_and_copy_device_tree();
+ pr_info("DTB @%08x (physical) copied to @%px (virtual)\n",
+ dt_phys, initial_boot_params);
+ /* Clear out any mappings over the device tree */
+ arm_mm_clear_atag_pages();
+}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d8e18cdd96d3..d0562cdc919e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1076,11 +1076,14 @@ void __init hyp_mode_check(void)
void __init setup_arch(char **cmdline_p)
{
const struct machine_desc *mdesc;
+ bool using_dt = false;
setup_processor();
mdesc = setup_machine_fdt(__atags_pointer);
if (!mdesc)
mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
+ else
+ using_dt = true;
if (!mdesc) {
early_print("\nError: invalid dtb and unrecognized/unsupported machine ID\n");
early_print(" r1=0x%08x, r2=0x%08x\n", __machine_arch_type,
@@ -1109,7 +1112,6 @@ void __init setup_arch(char **cmdline_p)
early_fixmap_init();
early_ioremap_init();
-
parse_early_param();
#ifdef CONFIG_MMU
@@ -1135,7 +1137,9 @@ void __init setup_arch(char **cmdline_p)
if (mdesc->restart)
arm_pm_restart = mdesc->restart;
- unflatten_device_tree();
+ /* Remap and copy the device tree */
+ if (using_dt)
+ setup_machine_copy_fdt(__atags_pointer);
arm_dt_init_cpu_maps();
psci_dt_init();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c36f977b2ccb..732c856c357d 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -68,6 +68,8 @@ pgprot_t pgprot_kernel;
EXPORT_SYMBOL(pgprot_user);
EXPORT_SYMBOL(pgprot_kernel);
+extern unsigned long __atags_pointer;
+
struct cachepolicy {
const char policy[16];
unsigned int cr_mask;
@@ -1258,6 +1260,7 @@ void __init adjust_lowmem_bounds(void)
static inline void prepare_page_table(void)
{
unsigned long addr;
+ unsigned long atags;
phys_addr_t end;
/*
@@ -1284,9 +1287,40 @@ static inline void prepare_page_table(void)
* Clear out all the kernel space mappings, except for the first
* memory bank, up to the vmalloc region.
*/
+ atags = __phys_to_virt(__atags_pointer);
+ atags &= PMD_MASK;
for (addr = __phys_to_virt(end);
- addr < VMALLOC_START; addr += PMD_SIZE)
+ addr < VMALLOC_START; addr += PMD_SIZE) {
+ if (addr >= atags && addr < (atags + 2 * PMD_SIZE)) {
+ pr_info("ATAGs/DTB found in lowmem, skip clearing PMD @0x%08lx\n", addr);
+ continue;
+ }
pmd_clear(pmd_off_k(addr));
+ }
+}
+
+void __init arm_mm_clear_atag_pages(void)
+{
+ unsigned long addr;
+ unsigned long atags;
+ phys_addr_t end;
+
+ /*
+ * Clear out the kernel space mappings used by the attached DTB if
+ * it happens to end up in lowmem.
+ */
+ end = memblock.memory.regions[0].base + memblock.memory.regions[0].size;
+ if (end >= arm_lowmem_limit)
+ end = arm_lowmem_limit;
+ atags = __phys_to_virt(__atags_pointer);
+ atags &= PMD_MASK;
+ for (addr = __phys_to_virt(end);
+ addr < VMALLOC_START; addr += PMD_SIZE) {
+ if (addr >= atags && addr < (atags + 2 * PMD_SIZE)) {
+ pr_info("Clear ATAGs/DTB PMD @0x%08lx\n", addr);
+ pmd_clear(pmd_off_k(addr));
+ }
+ }
}
#ifdef CONFIG_ARM_LPAE
@@ -1503,7 +1537,6 @@ static void __init map_lowmem(void)
}
#ifdef CONFIG_ARM_PV_FIXUP
-extern unsigned long __atags_pointer;
typedef void pgtables_remap(long long offset, unsigned long pgd, void *bdata);
pgtables_remap lpae_pgtables_remap_asm;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-01 15:22 ` [PATCH 1/6 v14] ARM: Handle a device tree in lowmem Linus Walleij
@ 2020-10-01 16:45 ` Florian Fainelli
2020-10-01 20:31 ` Linus Walleij
2020-10-02 11:01 ` Ard Biesheuvel
1 sibling, 1 reply; 36+ messages in thread
From: Florian Fainelli @ 2020-10-01 16:45 UTC (permalink / raw)
To: Linus Walleij, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, linux-arm-kernel
On 10/1/2020 8:22 AM, Linus Walleij wrote:
> If the kernel grows big, it can happen that the kernel does not
> fit in the first memory block. This is normally out-of-spec
> but it turns out that the boot usually survives this.
>
> What it does not survive is that the prepare_page_table() code
> wipes all PMDs (page table pointers for the virtual memory)
> over lowmem, including the PMD where the attached DTB is
> stored. (The variable is named atags but this only really
> happens for DTBs.)
>
> Let's deal with this.
>
> First, this makes the code jump over two PMDs where the DTB
> is stored if it ends up in lowmem: it could happen that the
> DTB crosses a PMD_SIZE boundary so to be on the safe side we
> need to skip over the one we know it starts in and also the
> next.
>
> Next we make ARM use unflatten_and_copy_device_tree() instead
> of just unflattening it where it is. Currently we just assume
> that the device tree will be in some kind of "safe" memory and
> as proven by KASan it will sometimes end up in the kernel lowmem
> which will create crashes as the kernel will clear all lowmem
> PMDs while initializing the memory manager.
>
> Finally, we add a new call to the MMU code to go in and clear
> out the PMDs in lowmem if the device tree was there.
>
> Example boot log on an affected system:
>
> ATAGs/DTB found in lowmem, skip clearing PMD @0xc3000000
> ATAGs/DTB found in lowmem, skip clearing PMD @0xc3200000
> (...)
> DTB @430af0e0 (physical) copied to @cc394d80 (virtual)
> Clear ATAGs/DTB PMD @0xc3000000
> Clear ATAGs/DTB PMD @0xc3200000
>
> This fixes the problem where the Qualcomm APQ8060 would not
> boot while using KASan.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is a much cleaner version than what we had been carrying in our STB
Linux distribution which was:
https://github.com/Broadcom/stblinux-4.9/blob/master/linux/arch/arm/kernel/head.S#L251
https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/of/fdt.c#L688
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-01 16:45 ` Florian Fainelli
@ 2020-10-01 20:31 ` Linus Walleij
0 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 20:31 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Russell King, Mike Rapoport,
Andrey Ryabinin, Ard Biesheuvel, Linux ARM
On Thu, Oct 1, 2020 at 6:45 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> This is a much cleaner version than what we had been carrying in our STB
> Linux distribution which was:
>
> https://github.com/Broadcom/stblinux-4.9/blob/master/linux/arch/arm/kernel/head.S#L251
> https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/of/fdt.c#L688
Oh I was surprised that it didn't happen more often.
It turns out it does :D
Do you also get the prints on affected platforms?
Reviewed-by?
Let's see what others say about this approach and then put it in Russell's
patch tracker.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-01 15:22 ` [PATCH 1/6 v14] ARM: Handle a device tree in lowmem Linus Walleij
2020-10-01 16:45 ` Florian Fainelli
@ 2020-10-02 11:01 ` Ard Biesheuvel
2020-10-04 20:50 ` Linus Walleij
1 sibling, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-02 11:01 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Thu, 1 Oct 2020 at 17:22, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> If the kernel grows big, it can happen that the kernel does not
> fit in the first memory block. This is normally out-of-spec
> but it turns out that the boot usually survives this.
>
> What it does not survive is that the prepare_page_table() code
> wipes all PMDs (page table pointers for the virtual memory)
> over lowmem, including the PMD where the attached DTB is
> stored. (The variable is named atags but this only really
> happens for DTBs.)
>
> Let's deal with this.
>
> First, this makes the code jump over two PMDs where the DTB
> is stored if it ends up in lowmem: it could happen that the
> DTB crosses a PMD_SIZE boundary so to be on the safe side we
> need to skip over the one we know it starts in and also the
> next.
>
> Next we make ARM use unflatten_and_copy_device_tree() instead
> of just unflattening it where it is. Currently we just assume
> that the device tree will be in some kind of "safe" memory and
> as proven by KASan it will sometimes end up in the kernel lowmem
> which will create crashes as the kernel will clear all lowmem
> PMDs while initializing the memory manager.
>
> Finally, we add a new call to the MMU code to go in and clear
> out the PMDs in lowmem if the device tree was there.
>
> Example boot log on an affected system:
>
> ATAGs/DTB found in lowmem, skip clearing PMD @0xc3000000
> ATAGs/DTB found in lowmem, skip clearing PMD @0xc3200000
> (...)
> DTB @430af0e0 (physical) copied to @cc394d80 (virtual)
> Clear ATAGs/DTB PMD @0xc3000000
> Clear ATAGs/DTB PMD @0xc3200000
>
> This fixes the problem where the Qualcomm APQ8060 would not
> boot while using KASan.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
OK, so if I am understanding this correctly, the root problem is that
the kernel unmaps the memory that the attached DTB resides in, right?
So how is it possible that the kernel does not fit in the first
memblock? Doesn't that mean that we are using memory that is not
available to begin with?
Do you have a dump of the memory layout on the platform in question?
How do 0xc3000000/0xc3200000 map onto physical addresses, and how are
those described?
If that memory is not actually available to begin with, this fix
papers over the problem, and we should be fixing this in the
decompressor instead.
> ---
> ChangeLog v13->v14:
> - New patch fixing the regression when using KASan on at least
> one of the affected platforms.
> ---
> arch/arm/include/asm/prom.h | 5 +++++
> arch/arm/kernel/devtree.c | 14 +++++++++++++-
> arch/arm/kernel/setup.c | 8 ++++++--
> arch/arm/mm/mmu.c | 37 +++++++++++++++++++++++++++++++++++--
> 4 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index 1e36c40533c1..41e189a2631c 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -11,6 +11,7 @@
>
> extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void __init arm_dt_init_cpu_maps(void);
> +void __init setup_machine_copy_fdt(unsigned int dt_phys);
>
> #else /* CONFIG_OF */
>
> @@ -21,5 +22,9 @@ static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
>
> static inline void arm_dt_init_cpu_maps(void) { }
>
> +static inline void setup_machine_copy_fdt(unsigned int dt_phys)
> +{
> +}
> +
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 39c978698406..267011e133a7 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -23,7 +23,7 @@
> #include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
> -
> +#include <asm/mach/map.h>
>
> #ifdef CONFIG_SMP
> extern struct of_cpu_method __cpu_method_of_table[];
> @@ -257,3 +257,15 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>
> return mdesc;
> }
> +
> +extern void arm_mm_clear_atag_pages(void);
> +
> +void __init setup_machine_copy_fdt(unsigned int dt_phys)
> +{
> + /* This will point the DT parser to the new location */
> + unflatten_and_copy_device_tree();
> + pr_info("DTB @%08x (physical) copied to @%px (virtual)\n",
> + dt_phys, initial_boot_params);
> + /* Clear out any mappings over the device tree */
> + arm_mm_clear_atag_pages();
> +}
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index d8e18cdd96d3..d0562cdc919e 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -1076,11 +1076,14 @@ void __init hyp_mode_check(void)
> void __init setup_arch(char **cmdline_p)
> {
> const struct machine_desc *mdesc;
> + bool using_dt = false;
>
> setup_processor();
> mdesc = setup_machine_fdt(__atags_pointer);
> if (!mdesc)
> mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> + else
> + using_dt = true;
> if (!mdesc) {
> early_print("\nError: invalid dtb and unrecognized/unsupported machine ID\n");
> early_print(" r1=0x%08x, r2=0x%08x\n", __machine_arch_type,
> @@ -1109,7 +1112,6 @@ void __init setup_arch(char **cmdline_p)
>
> early_fixmap_init();
> early_ioremap_init();
> -
> parse_early_param();
>
> #ifdef CONFIG_MMU
> @@ -1135,7 +1137,9 @@ void __init setup_arch(char **cmdline_p)
> if (mdesc->restart)
> arm_pm_restart = mdesc->restart;
>
> - unflatten_device_tree();
> + /* Remap and copy the device tree */
> + if (using_dt)
> + setup_machine_copy_fdt(__atags_pointer);
>
> arm_dt_init_cpu_maps();
> psci_dt_init();
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index c36f977b2ccb..732c856c357d 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -68,6 +68,8 @@ pgprot_t pgprot_kernel;
> EXPORT_SYMBOL(pgprot_user);
> EXPORT_SYMBOL(pgprot_kernel);
>
> +extern unsigned long __atags_pointer;
> +
> struct cachepolicy {
> const char policy[16];
> unsigned int cr_mask;
> @@ -1258,6 +1260,7 @@ void __init adjust_lowmem_bounds(void)
> static inline void prepare_page_table(void)
> {
> unsigned long addr;
> + unsigned long atags;
> phys_addr_t end;
>
> /*
> @@ -1284,9 +1287,40 @@ static inline void prepare_page_table(void)
> * Clear out all the kernel space mappings, except for the first
> * memory bank, up to the vmalloc region.
> */
> + atags = __phys_to_virt(__atags_pointer);
> + atags &= PMD_MASK;
> for (addr = __phys_to_virt(end);
> - addr < VMALLOC_START; addr += PMD_SIZE)
> + addr < VMALLOC_START; addr += PMD_SIZE) {
> + if (addr >= atags && addr < (atags + 2 * PMD_SIZE)) {
> + pr_info("ATAGs/DTB found in lowmem, skip clearing PMD @0x%08lx\n", addr);
> + continue;
> + }
> pmd_clear(pmd_off_k(addr));
> + }
> +}
> +
> +void __init arm_mm_clear_atag_pages(void)
> +{
> + unsigned long addr;
> + unsigned long atags;
> + phys_addr_t end;
> +
> + /*
> + * Clear out the kernel space mappings used by the attached DTB if
> + * it happens to end up in lowmem.
> + */
> + end = memblock.memory.regions[0].base + memblock.memory.regions[0].size;
> + if (end >= arm_lowmem_limit)
> + end = arm_lowmem_limit;
> + atags = __phys_to_virt(__atags_pointer);
> + atags &= PMD_MASK;
> + for (addr = __phys_to_virt(end);
> + addr < VMALLOC_START; addr += PMD_SIZE) {
> + if (addr >= atags && addr < (atags + 2 * PMD_SIZE)) {
> + pr_info("Clear ATAGs/DTB PMD @0x%08lx\n", addr);
> + pmd_clear(pmd_off_k(addr));
> + }
> + }
> }
>
> #ifdef CONFIG_ARM_LPAE
> @@ -1503,7 +1537,6 @@ static void __init map_lowmem(void)
> }
>
> #ifdef CONFIG_ARM_PV_FIXUP
> -extern unsigned long __atags_pointer;
> typedef void pgtables_remap(long long offset, unsigned long pgd, void *bdata);
> pgtables_remap lpae_pgtables_remap_asm;
>
> --
> 2.26.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-02 11:01 ` Ard Biesheuvel
@ 2020-10-04 20:50 ` Linus Walleij
2020-10-05 7:14 ` Ard Biesheuvel
0 siblings, 1 reply; 36+ messages in thread
From: Linus Walleij @ 2020-10-04 20:50 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Fri, Oct 2, 2020 at 1:01 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Thu, 1 Oct 2020 at 17:22, Linus Walleij <linus.walleij@linaro.org> wrote:
> OK, so if I am understanding this correctly, the root problem is that
> the kernel unmaps the memory that the attached DTB resides in, right?
Yups, or, well in some places the kernel knows that the DT is there
so it sets up two 1MB sections over it, and then it assumes "no-one
is ever gonna touch those two section mappings, OK".
It's this code from head.S:
/*
* Then map boot params address in r2 if specified.
* We map 2 sections in case the ATAGs/DTB crosses a section boundary.
*/
mov r0, r2, lsr #SECTION_SHIFT
movs r0, r0, lsl #SECTION_SHIFT
subne r3, r0, r8
addne r3, r3, #PAGE_OFFSET
addne r3, r4, r3, lsr #(SECTION_SHIFT - PMD_ORDER)
orrne r6, r7, r0
strne r6, [r3], #1 << PMD_ORDER
addne r6, r6, #1 << SECTION_SHIFT
strne r6, [r3]
Then these two blocks end up in lowmem, and as the kernel
clears the PMD:s in prepare_page_table(), in mm/mmu.c
is clears the two PMDs covering the device tree under
some circumstances.
[Ard]
> So how is it possible that the kernel does not fit in the first
> memblock? Doesn't that mean that we are using memory that is not
> available to begin with?
>
> Do you have a dump of the memory layout on the platform in question?
>
> How do 0xc3000000/0xc3200000 map onto physical addresses, and how are
> those described?
The kernel per se actually fits inside the first memblock,
but not the attached DTB which ends up above the
*uncompressed* kernel, so there is always a gap between
the end of the kernel text and the DTB. See this illustration:
https://dflund.se/~triad/images/decompress-5.jpg
This is how it looks with all my funky debug code (that I
am in the process of merging by the way, so it is easier to
debug things like this):
This platform boots using fastboot:
# fastboot --base 40200000 --cmdline "console=ttyMSM0,115200,n8" boot zImage
So we load the zImage at 0x40200000
which is where the physical memory starts on this
platform because the modem is using 0x0-0x41ffffff.
Then I get these debug prints:
DTB:0x410A09C0 (0x000051B5)
C:0x402080C0-0x410A5C20->0x42217100-0x430B4C60
DTB:0x430AFA00 (0x00005242)
This means the DTB is first found in physical memory at 0x410A09C0
then we relocate the kernel from 0x402080C0 to 0x42217100
to make space for the uncompressed kernel above it
and after that the DTB is found located at 0x430AFA00.
This is using attached device tree so that is why the
DTB is right after the compressed kernel in memory.
Uncompressing Linux... done, booting the kernel.
MMU enable: 0x40300000->0x40300000
Kernel RAM: 0x40000000->0xc0000000
Kernel RAM: 0x40100000->0xc0100000
Kernel RAM: 0x40200000->0xc0200000
(...)
Kernel RAM: 0x42500000->0xc2500000
Kernel RAM: 0x42600000->0xc2600000
ATAG/DTB : 0x43000000->0xc3000000
ATAG/DTB : 0x43100000->0xc3100000
First is the 1:1 mapping for the MMU enable code, then all the
kernel text segment mappings. Then the DTB is mapped in
using the linear kernel map and as you can see that
ends up to be at 0xc30AFA00 so we map the 2 MB
at 0x43000000 and 0x43100000.
That is close to the kernel... so indeed:
Clear PMDs from 0x00000000 to 0xb6e00000
Clear PMDs from 0xbf000000 to 0xbf000000
Clear PMDs from 0xbf000000 to 0xc0000000
Memblock[0].base: 0x40200000 size: 0x02c00000, end: 0x42e00000
Clear PMDs from 0xc2e00000 to 0xe0800000 (lowmem)
ATAGs/DTB found in lowmem, skip clearing PMD @0xc3000000
ATAGs/DTB found in lowmem, skip clearing PMD @0xc3200000
Ooops.
(The last two messages comes from this patch, the rest is
debug prints I added.)
The first memblock is 44 MB and the linear map ends at
0xc2e00000 which will cover the whole uncompressed kernel,
but then we come to this code in prepare_page_table():
/*
* Clear out all the kernel space mappings, except for the first
* memory bank, up to the vmalloc region.
*/
for (addr = __phys_to_virt(end); addr < VMALLOC_START; addr += PMD_SIZE)
pmd_clear(pmd_off_k(addr));
This clears out all mappings from the end of the first memblock
to VMALLOC_START. Including the PMD used by the DTB.
Ooops.
> If that memory is not actually available to begin with, this fix
> papers over the problem, and we should be fixing this in the
> decompressor instead.
The kernel actually fits in the first memblock, but then it clears
the lowmem right below itself and by that point the MMU
has figured out that there is another memblock below it
that it will happily use for lowmem and just goes ahead and
wipes that. The code has no awareness
that there might be a DTB there.
The decompressor seems to have always been blissfully ignorant
about what happens with the attached DTB after it just pushed
it a bit upwards in memory (if relocating) it just passes the location
in r2 in accordance with the boot specification, to me it seems
more like something the kernel proper should handle.
I don't think that loading the DTB separately to some high
address as advocated by many peope is much better.
It can create the same problem if loaded in the wrong
place and possibly be placed in other dangerous areas
like inside the VMALLOC area where it can get its
mappings destroyed at any instance. (We don't check for that
either.)
To me it seems like it was always like this and people have
just been trial-and-erroring by putting the DTB at
address until it works.
The way attached DTB works is that the entire compressed
kernel and the attached DTB usually ends up
inside the first memblock as well so the initialization of the
kernel lowmem will not wipe its two PMDs.
The problem with that approach is that if your kernel
suddenly gets bigger - like when enabling KASan - then
this can occur, especially with attached device trees.
I can mitigate the problem for example by just loading the
kernel at 0x50000000 instead:
DTB:0x50EA09C0 (0x000051B5)
C:0x500080C0-0x50EA5C20->0x52217100-0x530B4C60
DTB:0x530AFA00 (0x00005242)
Uncompressing Linux... done, booting the kernel.
MMU enable: 0x50300000->0x50300000
Kernel RAM: 0x50000000->0xc0000000
Kernel RAM: 0x50100000->0xc0100000
Kernel RAM: 0x50200000->0xc0200000
(...)
Kernel RAM: 0x52500000->0xc2500000
Kernel RAM: 0x52600000->0xc2600000
ATAG/DTB : 0x53000000->0xc3000000
ATAG/DTB : 0x53100000->0xc3100000
(...)
Clear PMDs from 0x00000000 to 0xb6e00000
Clear PMDs from 0xbf000000 to 0xbf000000
Clear PMDs from 0xbf000000 to 0xc0000000
Memblock end is above arm_lowmem_limit (0x60000000)
Memblock[0].base: 0x50000000 size: 0x10000000, end: 0x60000000
Clear PMDs from 0xd0000000 to 0xd0800000 (lowmem)
The DTB is at physical 0x530AFA00 which is
virtual 0xC30AFA00 and since the first memblock now
is bigger, the kernel and the DTB fits inside it
and the DTB mapping is between the kernel
and the lowmem mappings, so the PMDs will not
be cleared.
I think "most" cases work for people because their
first memblock is big like this (256 MB) and their
kernel is relatively small compared to that so the
uncompressed and compressed kernel, and the
attached DTB all fit inside it. In my case the first
memblock was "just" 44 MB and that was just small
enough to trigger this.
So to summarize:
- The kernel decompressor just moves the kernel and the
attached DTB upward in memory so it will not be
overwritten by the decompressor.
- This will sometimes make part of the compressed kernel and
DTB end up above the first memblock.
- This works because there is more memory above
the first memblock, in an adjacent memblock.
(The decompressor has always assumed so much)
- The kernel then puts the lowmem mappings from
the end of the first memblock to VMALLOC_START
and clear the PMDs
- If the DTB has been pushed up to lowmem, the two
PMDs over the DTB will be cleared, resulting in a crash.
Maybe I should just put all of this into the commit
message so people can see the mess :D
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-04 20:50 ` Linus Walleij
@ 2020-10-05 7:14 ` Ard Biesheuvel
2020-10-05 9:14 ` Ard Biesheuvel
2020-10-05 12:26 ` Linus Walleij
0 siblings, 2 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-05 7:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
Hi Linus,
Thanks for the elaborate explanation.
On Sun, 4 Oct 2020 at 22:50, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Oct 2, 2020 at 1:01 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Thu, 1 Oct 2020 at 17:22, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > OK, so if I am understanding this correctly, the root problem is that
> > the kernel unmaps the memory that the attached DTB resides in, right?
>
> Yups, or, well in some places the kernel knows that the DT is there
> so it sets up two 1MB sections over it, and then it assumes "no-one
> is ever gonna touch those two section mappings, OK".
>
OK, so from your explanation, I gathered that:
- the 'appended DTB' is not appended anymore when the core kernel
boots, and the problem is caused by the fact that the decompressor
blindly chooses a location for it, whereas the firmware makes a more
informed decision when it places the DT in memory
- the memory holding the DT may be unmapped inadvertently
- the memory holding the DT may be wiped inadvertently.
...
> The kernel actually fits in the first memblock, but then it clears
> the lowmem right below itself and by that point the MMU
> has figured out that there is another memblock below it
> that it will happily use for lowmem and just goes ahead and
> wipes that. The code has no awareness
> that there might be a DTB there.
>
Where in the code does this happen? It seems to me that at this point,
the DT memory should have been memblock_reserve()d, and the code in
question should disregard it from wiping.
> The decompressor seems to have always been blissfully ignorant
> about what happens with the attached DTB after it just pushed
> it a bit upwards in memory (if relocating) it just passes the location
> in r2 in accordance with the boot specification, to me it seems
> more like something the kernel proper should handle.
>
> I don't think that loading the DTB separately to some high
> address as advocated by many peope is much better.
> It can create the same problem if loaded in the wrong
> place and possibly be placed in other dangerous areas
> like inside the VMALLOC area where it can get its
> mappings destroyed at any instance. (We don't check for that
> either.)
>
I think putting the mapping of the DT outside of the linear region is
reasonable, tbh, and this is what we do on arm64. That way, the
firmware does not have to care at all about the MM configuration of
the kernel, and it could simply put it in high memory as well.
One option would be to create a virtual mapping for the DT at the base
of the modules region. This takes up 1 MB in the typical (non-LPAE)
case, and 4 MB in the worst case, making it more likely that you will
run out of module space, but we already have infrastructure to deal
with that.
...
> So to summarize:
>
> - The kernel decompressor just moves the kernel and the
> attached DTB upward in memory so it will not be
> overwritten by the decompressor.
>
> - This will sometimes make part of the compressed kernel and
> DTB end up above the first memblock.
>
> - This works because there is more memory above
> the first memblock, in an adjacent memblock.
> (The decompressor has always assumed so much)
>
> - The kernel then puts the lowmem mappings from
> the end of the first memblock to VMALLOC_START
> and clear the PMDs
>
> - If the DTB has been pushed up to lowmem, the two
> PMDs over the DTB will be cleared, resulting in a crash.
>
> Maybe I should just put all of this into the commit
> message so people can see the mess :D
>
I'd prefer to fix this in a more structural way, tbh.
Let me see if I can code up a PoC
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 7:14 ` Ard Biesheuvel
@ 2020-10-05 9:14 ` Ard Biesheuvel
2020-10-05 13:27 ` Linus Walleij
2020-10-06 8:47 ` Linus Walleij
2020-10-05 12:26 ` Linus Walleij
1 sibling, 2 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-05 9:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Hi Linus,
>
> Thanks for the elaborate explanation.
>
> On Sun, 4 Oct 2020 at 22:50, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Fri, Oct 2, 2020 at 1:01 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Thu, 1 Oct 2020 at 17:22, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > OK, so if I am understanding this correctly, the root problem is that
> > > the kernel unmaps the memory that the attached DTB resides in, right?
> >
> > Yups, or, well in some places the kernel knows that the DT is there
> > so it sets up two 1MB sections over it, and then it assumes "no-one
> > is ever gonna touch those two section mappings, OK".
> >
>
> OK, so from your explanation, I gathered that:
> - the 'appended DTB' is not appended anymore when the core kernel
> boots, and the problem is caused by the fact that the decompressor
> blindly chooses a location for it, whereas the firmware makes a more
> informed decision when it places the DT in memory
> - the memory holding the DT may be unmapped inadvertently
> - the memory holding the DT may be wiped inadvertently.
>
> ...
> > The kernel actually fits in the first memblock, but then it clears
> > the lowmem right below itself and by that point the MMU
> > has figured out that there is another memblock below it
> > that it will happily use for lowmem and just goes ahead and
> > wipes that. The code has no awareness
> > that there might be a DTB there.
> >
>
> Where in the code does this happen? It seems to me that at this point,
> the DT memory should have been memblock_reserve()d, and the code in
> question should disregard it from wiping.
>
> > The decompressor seems to have always been blissfully ignorant
> > about what happens with the attached DTB after it just pushed
> > it a bit upwards in memory (if relocating) it just passes the location
> > in r2 in accordance with the boot specification, to me it seems
> > more like something the kernel proper should handle.
> >
> > I don't think that loading the DTB separately to some high
> > address as advocated by many peope is much better.
> > It can create the same problem if loaded in the wrong
> > place and possibly be placed in other dangerous areas
> > like inside the VMALLOC area where it can get its
> > mappings destroyed at any instance. (We don't check for that
> > either.)
> >
>
> I think putting the mapping of the DT outside of the linear region is
> reasonable, tbh, and this is what we do on arm64. That way, the
> firmware does not have to care at all about the MM configuration of
> the kernel, and it could simply put it in high memory as well.
>
> One option would be to create a virtual mapping for the DT at the base
> of the modules region. This takes up 1 MB in the typical (non-LPAE)
> case, and 4 MB in the worst case, making it more likely that you will
> run out of module space, but we already have infrastructure to deal
> with that.
>
> ...
>
> > So to summarize:
> >
> > - The kernel decompressor just moves the kernel and the
> > attached DTB upward in memory so it will not be
> > overwritten by the decompressor.
> >
> > - This will sometimes make part of the compressed kernel and
> > DTB end up above the first memblock.
> >
> > - This works because there is more memory above
> > the first memblock, in an adjacent memblock.
> > (The decompressor has always assumed so much)
> >
> > - The kernel then puts the lowmem mappings from
> > the end of the first memblock to VMALLOC_START
> > and clear the PMDs
> >
> > - If the DTB has been pushed up to lowmem, the two
> > PMDs over the DTB will be cleared, resulting in a crash.
> >
> > Maybe I should just put all of this into the commit
> > message so people can see the mess :D
> >
>
> I'd prefer to fix this in a more structural way, tbh.
>
> Let me see if I can code up a PoC
I pushed a branch to
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
that moves the DT mapping to a read-only region at the top of the
kernel VA space: there happened to be a 4 MB hole there (between
VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of
that hole was as a guard region, as a read-only mapping still catches
stray writes.
What I don't get is why the DT *contents* get clobbered -
arm_memblock_init() memblock_reserve's the DT contents, and wiping
reserved memblocks is something we really shouldn't be doing.
--
Ard.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 9:14 ` Ard Biesheuvel
@ 2020-10-05 13:27 ` Linus Walleij
2020-10-05 13:30 ` Linus Walleij
2020-10-05 13:36 ` Ard Biesheuvel
2020-10-06 8:47 ` Linus Walleij
1 sibling, 2 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-05 13:27 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel <ardb@kernel.org> wrote:
> > Let me see if I can code up a PoC
>
> I pushed a branch to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
>
> that moves the DT mapping to a read-only region at the top of the
> kernel VA space: there happened to be a 4 MB hole there (between
> VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of
> that hole was as a guard region, as a read-only mapping still catches
> stray writes.
I will test it when I'm back at the hardware.
I tried to do this thing as well but couldn't figure out a good
place to map it, putting it between VMALLOC_END
and FIXADDR_START seems like a good idea!
But this is going to be a problem:
+ map.type = MT_ROM;
Because the current code calls unflatten_device_tree() which
will unflatten the device tree right where it is.
So then the memory needs to be RW.
This is why in my patch I change that to
unflatten_and_copy_device_tree() so I can treat
it as a ROM, unflatten and copy that and then
ditch the memory where the device tree is so the
kernel does not need to work around that.
(unflatten_and_copy_device_tree()
will not delete the memblock around the device
tree, so that would need to be fixed in my patch.)
With your patch, if we call
unflatten_and_copy_device_tree() we can use
MT_ROM but then we would want to get rid of the
remapped memory and memblock
for the device tree after copying and unflattening
it, but since there is no delete_mapping()
counterpart to create_mapping() I guess that
is going to be hard?
> What I don't get is why the DT *contents* get clobbered -
> arm_memblock_init() memblock_reserve's the DT contents, and wiping
> reserved memblocks is something we really shouldn't be doing.
The contents are fine on my system, just the two section
mappings get wiped.
I hope my previous mail explains that, the code in
prepare_page_table() simply just wipes the lowmem
PMDs without any regard for any reserved memblocks being
in that range.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 13:27 ` Linus Walleij
@ 2020-10-05 13:30 ` Linus Walleij
2020-10-05 13:36 ` Ard Biesheuvel
1 sibling, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-05 13:30 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, Oct 5, 2020 at 3:27 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> The contents are fine on my system, just the two section
> mappings get wiped.
>
> I hope my previous mail explains that, the code in
> prepare_page_table() simply just wipes the lowmem
> PMDs without any regard for any reserved memblocks being
> in that range.
Would it be a viable approach to make a patch to make
prepare_page_table() respect any reserved memblocks?
That would fix this bug.
Then I could make a separate patch to copy the device tree
and delete the memblock used by it as a separate optimization.
(Not that I know if memblock actually allows for disposal
of memblocks...)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 13:27 ` Linus Walleij
2020-10-05 13:30 ` Linus Walleij
@ 2020-10-05 13:36 ` Ard Biesheuvel
2020-10-05 14:22 ` Ard Biesheuvel
1 sibling, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-05 13:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, 5 Oct 2020 at 15:27, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > > Let me see if I can code up a PoC
> >
> > I pushed a branch to
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
> >
> > that moves the DT mapping to a read-only region at the top of the
> > kernel VA space: there happened to be a 4 MB hole there (between
> > VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of
> > that hole was as a guard region, as a read-only mapping still catches
> > stray writes.
>
> I will test it when I'm back at the hardware.
> I tried to do this thing as well but couldn't figure out a good
> place to map it, putting it between VMALLOC_END
> and FIXADDR_START seems like a good idea!
>
> But this is going to be a problem:
>
> + map.type = MT_ROM;
>
> Because the current code calls unflatten_device_tree() which
> will unflatten the device tree right where it is.
> So then the memory needs to be RW.
>
I don't think this is the case. Note that arm64 has been using r/o
mappings for the device tree for a long time, and it calls
unflatten_device_tree() without any problems.
> This is why in my patch I change that to
> unflatten_and_copy_device_tree() so I can treat
> it as a ROM, unflatten and copy that and then
> ditch the memory where the device tree is so the
> kernel does not need to work around that.
>
> (unflatten_and_copy_device_tree()
> will not delete the memblock around the device
> tree, so that would need to be fixed in my patch.)
>
> With your patch, if we call
> unflatten_and_copy_device_tree() we can use
> MT_ROM but then we would want to get rid of the
> remapped memory and memblock
> for the device tree after copying and unflattening
> it, but since there is no delete_mapping()
> counterpart to create_mapping() I guess that
> is going to be hard?
>
> > What I don't get is why the DT *contents* get clobbered -
> > arm_memblock_init() memblock_reserve's the DT contents, and wiping
> > reserved memblocks is something we really shouldn't be doing.
>
> The contents are fine on my system, just the two section
> mappings get wiped.
>
Ah ok.
> I hope my previous mail explains that, the code in
> prepare_page_table() simply just wipes the lowmem
> PMDs without any regard for any reserved memblocks being
> in that range.
>
In that case, mapping the DT outside of the linear region should solve
this entirely.
Note that this code boots fine for me. The only question I have is
whether the ATAGS based systems require the ability to make changes to
the data structure at runtime.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 13:36 ` Ard Biesheuvel
@ 2020-10-05 14:22 ` Ard Biesheuvel
2020-10-06 9:11 ` Linus Walleij
0 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-05 14:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, 5 Oct 2020 at 15:36, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 5 Oct 2020 at 15:27, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > > > Let me see if I can code up a PoC
> > >
> > > I pushed a branch to
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
> > >
> > > that moves the DT mapping to a read-only region at the top of the
> > > kernel VA space: there happened to be a 4 MB hole there (between
> > > VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of
> > > that hole was as a guard region, as a read-only mapping still catches
> > > stray writes.
> >
> > I will test it when I'm back at the hardware.
> > I tried to do this thing as well but couldn't figure out a good
> > place to map it, putting it between VMALLOC_END
> > and FIXADDR_START seems like a good idea!
> >
> > But this is going to be a problem:
> >
> > + map.type = MT_ROM;
> >
> > Because the current code calls unflatten_device_tree() which
> > will unflatten the device tree right where it is.
> > So then the memory needs to be RW.
> >
>
> I don't think this is the case. Note that arm64 has been using r/o
> mappings for the device tree for a long time, and it calls
> unflatten_device_tree() without any problems.
>
I think the problem here may be that early_init_fdt_reserve_self()
uses the wrong translation for obtaining the PA of the device tree
blob. This is also the reason we no longer use it on arm64 IIRC.
When I add the following on top, everything works as expected with
MT_ROM, including the ability to dump the firmware provided DT from
/sys/firmware/fdt
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 40fe688a7b76..1dbc8a46cf5f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
#include <linux/of_platform.h>
#include <linux/init.h>
#include <linux/kexec.h>
+#include <linux/libfdt.h>
#include <linux/of_fdt.h>
#include <linux/cpu.h>
#include <linux/interrupt.h>
@@ -1082,8 +1083,11 @@ void __init setup_arch(char **cmdline_p)
atags_vaddr = FDT_VIRT_ADDR(__atags_pointer);
setup_processor();
- if (atags_vaddr)
+ if (atags_vaddr) {
mdesc = setup_machine_fdt(atags_vaddr);
+ if (mdesc)
+ memblock_reserve(__atags_pointer,
fdt_totalsize(atags_vaddr));
+ }
if (!mdesc)
mdesc = setup_machine_tags(atags_vaddr, __machine_arch_type);
if (!mdesc) {
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 000c1b48e973..652a87bd065c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -223,7 +223,6 @@ void __init arm_memblock_init(const struct
machine_desc *mdesc)
if (mdesc->reserve)
mdesc->reserve();
- early_init_fdt_reserve_self();
early_init_fdt_scan_reserved_mem();
/* reserve memory for DMA contiguous allocations */
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 14:22 ` Ard Biesheuvel
@ 2020-10-06 9:11 ` Linus Walleij
2020-10-06 9:16 ` Ard Biesheuvel
0 siblings, 1 reply; 36+ messages in thread
From: Linus Walleij @ 2020-10-06 9:11 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, Oct 5, 2020 at 4:22 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> I think the problem here may be that early_init_fdt_reserve_self()
> uses the wrong translation for obtaining the PA of the device tree
> blob. This is also the reason we no longer use it on arm64 IIRC.
>
> When I add the following on top, everything works as expected with
> MT_ROM, including the ability to dump the firmware provided DT from
> /sys/firmware/fdt
(...)
> - if (atags_vaddr)
> + if (atags_vaddr) {
> mdesc = setup_machine_fdt(atags_vaddr);
> + if (mdesc)
> + memblock_reserve(__atags_pointer,
> fdt_totalsize(atags_vaddr));
I tested with this too and it works fine, and makes perfect sense,
it should protect the physical memory used by the DT even if
that happens to be in lowmem.
Please fold this into the patch! (Reviewed/Tested-by).
If we go for copying and unflattening the
devicetree instead of just unflattning it the memblock should
be removed, which is nice and clean to my OCD because
then we don't have this random "hole" in the memory, but I
suspect then we should also drop the virtual mapping and
that seems like it could be hard.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-06 9:11 ` Linus Walleij
@ 2020-10-06 9:16 ` Ard Biesheuvel
2020-10-06 9:19 ` Linus Walleij
0 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-06 9:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Tue, 6 Oct 2020 at 11:11, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Oct 5, 2020 at 4:22 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > I think the problem here may be that early_init_fdt_reserve_self()
> > uses the wrong translation for obtaining the PA of the device tree
> > blob. This is also the reason we no longer use it on arm64 IIRC.
> >
> > When I add the following on top, everything works as expected with
> > MT_ROM, including the ability to dump the firmware provided DT from
> > /sys/firmware/fdt
> (...)
> > - if (atags_vaddr)
> > + if (atags_vaddr) {
> > mdesc = setup_machine_fdt(atags_vaddr);
> > + if (mdesc)
> > + memblock_reserve(__atags_pointer,
> > fdt_totalsize(atags_vaddr));
>
> I tested with this too and it works fine, and makes perfect sense,
> it should protect the physical memory used by the DT even if
> that happens to be in lowmem.
>
> Please fold this into the patch! (Reviewed/Tested-by).
>
OK, thanks. The patches will look slightly different, though, so you
may have to take another look, and give these in reply.
> If we go for copying and unflattening the
> devicetree instead of just unflattning it the memblock should
> be removed, which is nice and clean to my OCD because
> then we don't have this random "hole" in the memory, but I
> suspect then we should also drop the virtual mapping and
> that seems like it could be hard.
>
We don't actually unmap the DT from the linear region, we just alias
it elsewhere in the VA space, so that we don't have to reason about
whether the DT is in the first memblock or below/above/whatever.
So the DT is just one of the many memblock_reservations, and this
actually doesn't change - the DT is still there, it is reserved, we
just access it via another route.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-06 9:16 ` Ard Biesheuvel
@ 2020-10-06 9:19 ` Linus Walleij
0 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-06 9:19 UTC (permalink / raw)
To: Ard Biesheuvel, Rob Herring
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Tue, Oct 6, 2020 at 11:16 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> We don't actually unmap the DT from the linear region, we just alias
> it elsewhere in the VA space, so that we don't have to reason about
> whether the DT is in the first memblock or below/above/whatever.
>
> So the DT is just one of the many memblock_reservations, and this
> actually doesn't change - the DT is still there, it is reserved, we
> just access it via another route.
Yeah I see.
I had a conversation with Rob Herring where he said it would be
nice if ARM used unflatten_and_copy_device_tree() like most
other architectures, but I don't know what it would bring us?
(Paging Rob.)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 9:14 ` Ard Biesheuvel
2020-10-05 13:27 ` Linus Walleij
@ 2020-10-06 8:47 ` Linus Walleij
2020-10-06 8:48 ` Ard Biesheuvel
1 sibling, 1 reply; 36+ messages in thread
From: Linus Walleij @ 2020-10-06 8:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > Let me see if I can code up a PoC
>
> I pushed a branch to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
I tested these two on the APQ8060 today and it works like a charm :D
Tested-by/Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I think we can just put these into Russell's patch tracker already, they
just make everything so much cleaner.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-06 8:47 ` Linus Walleij
@ 2020-10-06 8:48 ` Ard Biesheuvel
0 siblings, 0 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-06 8:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Tue, 6 Oct 2020 at 10:47, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > > Let me see if I can code up a PoC
> >
> > I pushed a branch to
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
>
> I tested these two on the APQ8060 today and it works like a charm :D
> Tested-by/Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> I think we can just put these into Russell's patch tracker already, they
> just make everything so much cleaner.
>
Thanks.
I will send them to the list today.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
2020-10-05 7:14 ` Ard Biesheuvel
2020-10-05 9:14 ` Ard Biesheuvel
@ 2020-10-05 12:26 ` Linus Walleij
1 sibling, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-05 12:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
Hi Ard,
thanks for helping out, finally we're getting somewhere with this!
On Mon, Oct 5, 2020 at 9:15 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Sun, 4 Oct 2020 at 22:50, Linus Walleij <linus.walleij@linaro.org> wrote:
> OK, so from your explanation, I gathered that:
> - the 'appended DTB' is not appended anymore when the core kernel
> boots, and the problem is caused by the fact that the decompressor
> blindly chooses a location for it, whereas the firmware makes a more
> informed decision when it places the DT in memory
> - the memory holding the DT may be unmapped inadvertently
> - the memory holding the DT may be wiped inadvertently.
Correct.
> > The kernel actually fits in the first memblock, but then it clears
> > the lowmem right below itself and by that point the MMU
> > has figured out that there is another memblock below it
> > that it will happily use for lowmem and just goes ahead and
> > wipes that. The code has no awareness
> > that there might be a DTB there.
>
> Where in the code does this happen?
This happens in mm/mmu.c, prepare_page_table(), line1283:
/*
* Clear out all the kernel space mappings, except for the first
* memory bank, up to the vmalloc region.
*/
for (addr = __phys_to_virt(end); addr < VMALLOC_START; addr += PMD_SIZE)
pmd_clear(pmd_off_k(addr));
Here end is augmented roofed at arm_lowmem_limit which seems
common but that incidentally does not happen on my platform
because of the small size of the first memblock.
> It seems to me that at this point,
> the DT memory should have been memblock_reserve()d, and the code in
> question should disregard it from wiping.
This code seems pretty ignorant about anything like that,
This happens as the first call in paging_init() after
arm_memblock_init() but before we
have called memblock_set_current_limit().
We need to keep these mappings alive until we
have called unflatten_and_copy_device_tree()
which transfers the device tree into memory the kernel
controls. Then we should free/unmap that memory
so that the kernel can use it. What happens to the memory
where the DTB is stored right now is kind of "undefined"
which doesn't feel good to me at all.
> I think putting the mapping of the DT outside of the linear region is
> reasonable, tbh, and this is what we do on arm64.
Yes that is much better. Arm64 also relies on the bootloader
to do the decompression and some other simplifications I really
like.
> One option would be to create a virtual mapping for the DT at the base
> of the modules region. This takes up 1 MB in the typical (non-LPAE)
> case, and 4 MB in the worst case, making it more likely that you will
> run out of module space, but we already have infrastructure to deal
> with that.
2MB (two section mappings) is what head.S always maps
and that would be 4MB on LPAE indeed.
I tried to use the earlymaps for this but I couldn't get it to
work, besides it only supports some 16 pages so not good
approach since the early boot maps a whopping 2MB.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 2/6 v14] ARM: Disable KASan instrumentation for some code
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
2020-10-01 15:22 ` [PATCH 1/6 v14] ARM: Handle a device tree in lowmem Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 15:22 ` [PATCH 3/6 v14] ARM: Replace string mem* functions for KASan Linus Walleij
` (5 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Marc Zyngier, Linus Walleij, kasan-dev,
Alexander Potapenko, linux-arm-kernel, Dmitry Vyukov
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Disable instrumentation for arch/arm/boot/compressed/*
since that code is executed before the kernel has even
set up its mappings and definately out of scope for
KASan.
Disable instrumentation of arch/arm/vdso/* because that code
is not linked with the kernel image, so the KASan management
code would fail to link.
Disable instrumentation of arch/arm/mm/physaddr.c. See commit
ec6d06efb0ba ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
for more details.
Disable kasan check in the function unwind_pop_register because
it does not matter that kasan checks failed when unwind_pop_register()
reads the stack memory of a task.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Do not sanitize arch/arm/mm/mmu.c.
Apart from being intuitively correct, it turns out that KASan
will insert a __asan_load4() into the set_pte_at() function
in mmu.c and this is something that KASan calls in the early
initialization, to set up the shadow memory. Naturally,
__asan_load4() cannot be called before the shadow memory is
set up so we need to exclude mmu.c from sanitization.
ChangeLog v6->v7:
- Removed the KVM instrumentaton disablement since KVM
on ARM32 is gone.
---
arch/arm/boot/compressed/Makefile | 1 +
arch/arm/kernel/unwind.c | 6 +++++-
arch/arm/mm/Makefile | 2 ++
arch/arm/vdso/Makefile | 2 ++
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index b1147b7f2c8d..362e17e37398 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -24,6 +24,7 @@ OBJS += hyp-stub.o
endif
GCOV_PROFILE := n
+KASAN_SANITIZE := n
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index d2bd0df2318d..f35eb584a18a 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -236,7 +236,11 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
if (*vsp >= (unsigned long *)ctrl->sp_high)
return -URC_FAILURE;
- ctrl->vrs[reg] = *(*vsp)++;
+ /* Use READ_ONCE_NOCHECK here to avoid this memory access
+ * from being tracked by KASAN.
+ */
+ ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+ (*vsp)++;
return URC_OK;
}
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 7cb1699fbfc4..99699c32d8a5 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -7,6 +7,7 @@ obj-y := extable.o fault.o init.o iomap.o
obj-y += dma-mapping$(MMUEXT).o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
+KASAN_SANITIZE_mmu.o := n
ifneq ($(CONFIG_MMU),y)
obj-y += nommu.o
@@ -16,6 +17,7 @@ endif
obj-$(CONFIG_ARM_PTDUMP_CORE) += dump.o
obj-$(CONFIG_ARM_PTDUMP_DEBUGFS) += ptdump_debugfs.o
obj-$(CONFIG_MODULES) += proc-syms.o
+KASAN_SANITIZE_physaddr.o := n
obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index a54f70731d9f..171c3dcb5242 100644
--- a/arch/arm/vdso/Makefile
+++ b/arch/arm/vdso/Makefile
@@ -42,6 +42,8 @@ GCOV_PROFILE := n
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
+KASAN_SANITIZE := n
+
# Force dependency
$(obj)/vdso.o : $(obj)/vdso.so
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 3/6 v14] ARM: Replace string mem* functions for KASan
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
2020-10-01 15:22 ` [PATCH 1/6 v14] ARM: Handle a device tree in lowmem Linus Walleij
2020-10-01 15:22 ` [PATCH 2/6 v14] ARM: Disable KASan instrumentation for some code Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 15:22 ` [PATCH 4/6 v14] ARM: Define the virtual space of KASan's shadow region Linus Walleij
` (4 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Linus Walleij, kasan-dev, Alexander Potapenko,
linux-arm-kernel, Dmitry Vyukov
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Functions like memset()/memmove()/memcpy() do a lot of memory
accesses.
If a bad pointer is passed to one of these functions it is important
to catch this. Compiler instrumentation cannot do this since these
functions are written in assembly.
KASan replaces these memory functions with instrumented variants.
The original functions are declared as weak symbols so that
the strong definitions in mm/kasan/kasan.c can replace them.
The original functions have aliases with a '__' prefix in their
name, so we can call the non-instrumented variant if needed.
We must use __memcpy()/__memset() in place of memcpy()/memset()
when we copy .data to RAM and when we clear .bss, because
kasan_early_init cannot be called before the initialization of
.data and .bss.
For the kernel compression and EFI libstub's custom string
libraries we need a special quirk: even if these are built
without KASan enabled, they rely on the global headers for their
custom string libraries, which means that e.g. memcpy()
will be defined to __memcpy() and we get link failures.
Since these implementations are written i C rather than
assembly we use e.g. __alias(memcpy) to redirected any
users back to the local implementation.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Use the less invasive version of handling the global redefines
of the string functions in the decompressor: __alias() the
functions locally in the library.
- Put in some more comments so readers of the code knows what
is going on.
ChangeLog v6->v7:
- Move the hacks around __SANITIZE_ADDRESS__ into this file
- Edit the commit message
- Rebase on the other v2 patches
---
arch/arm/boot/compressed/string.c | 19 +++++++++++++++++++
arch/arm/include/asm/string.h | 21 +++++++++++++++++++++
arch/arm/kernel/head-common.S | 4 ++--
arch/arm/lib/memcpy.S | 3 +++
arch/arm/lib/memmove.S | 5 ++++-
arch/arm/lib/memset.S | 3 +++
6 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index ade5079bebbf..8c0fa276d994 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -7,6 +7,25 @@
#include <linux/string.h>
+/*
+ * The decompressor is built without KASan but uses the same redirects as the
+ * rest of the kernel when CONFIG_KASAN is enabled, defining e.g. memcpy()
+ * to __memcpy() but since we are not linking with the main kernel string
+ * library in the decompressor, that will lead to link failures.
+ *
+ * Undefine KASan's versions, define the wrapped functions and alias them to
+ * the right names so that when e.g. __memcpy() appear in the code, it will
+ * still be linked to this local version of memcpy().
+ */
+#ifdef CONFIG_KASAN
+#undef memcpy
+#undef memmove
+#undef memset
+void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy);
+void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove);
+void *__memset(void *s, int c, size_t count) __alias(memset);
+#endif
+
void *memcpy(void *__dest, __const void *__src, size_t __n)
{
int i = 0;
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index 111a1d8a41dd..947f93037d87 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -5,6 +5,9 @@
/*
* We don't do inline string functions, since the
* optimised inline asm versions are not small.
+ *
+ * The __underscore versions of some functions are for KASan to be able
+ * to replace them with instrumented versions.
*/
#define __HAVE_ARCH_STRRCHR
@@ -15,15 +18,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 *dest, const void *src, __kernel_size_t n);
#define __HAVE_ARCH_MEMMOVE
extern void * memmove(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *dest, const void *src, __kernel_size_t n);
#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 *s, int c, __kernel_size_t n);
#define __HAVE_ARCH_MEMSET32
extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t);
@@ -39,4 +45,19 @@ static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n)
return __memset64(p, v, n * 8, v >> 32);
}
+/*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * must use non-instrumented versions of the mem*
+ * functions named __memcpy() etc. All such kernel code has
+ * been tagged with KASAN_SANITIZE_file.o = n, which means
+ * that the address sanitization argument isn't passed to the
+ * compiler, and __SANITIZE_ADDRESS__ is not set. As a result
+ * these defines kick in.
+ */
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+#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/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 4a3982812a40..6840c7c60a85 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -95,7 +95,7 @@ __mmap_switched:
THUMB( ldmia r4!, {r0, r1, r2, r3} )
THUMB( mov sp, r3 )
sub r2, r2, r1
- bl memcpy @ copy .data to RAM
+ bl __memcpy @ copy .data to RAM
#endif
ARM( ldmia r4!, {r0, r1, sp} )
@@ -103,7 +103,7 @@ __mmap_switched:
THUMB( mov sp, r3 )
sub r2, r1, r0
mov r1, #0
- bl memset @ clear .bss
+ bl __memset @ clear .bss
ldmia r4, {r0, r1, r2, r3}
str r9, [r0] @ Save processor ID
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 09a333153dc6..ad4625d16e11 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -58,6 +58,8 @@
/* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
+.weak memcpy
+ENTRY(__memcpy)
ENTRY(mmiocpy)
ENTRY(memcpy)
@@ -65,3 +67,4 @@ ENTRY(memcpy)
ENDPROC(memcpy)
ENDPROC(mmiocpy)
+ENDPROC(__memcpy)
diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S
index b50e5770fb44..fd123ea5a5a4 100644
--- a/arch/arm/lib/memmove.S
+++ b/arch/arm/lib/memmove.S
@@ -24,12 +24,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 )
@@ -222,3 +224,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 6ca4535c47fb..0e7ff0423f50 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -13,6 +13,8 @@
.text
.align 5
+.weak memset
+ENTRY(__memset)
ENTRY(mmioset)
ENTRY(memset)
UNWIND( .fnstart )
@@ -132,6 +134,7 @@ UNWIND( .fnstart )
UNWIND( .fnend )
ENDPROC(memset)
ENDPROC(mmioset)
+ENDPROC(__memset)
ENTRY(__memset32)
UNWIND( .fnstart )
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 4/6 v14] ARM: Define the virtual space of KASan's shadow region
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
` (2 preceding siblings ...)
2020-10-01 15:22 ` [PATCH 3/6 v14] ARM: Replace string mem* functions for KASan Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 15:22 ` [PATCH 5/6 v14] ARM: Initialize the mapping of KASan shadow memory Linus Walleij
` (3 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Linus Walleij, kasan-dev, Alexander Potapenko,
linux-arm-kernel, Dmitry Vyukov
From: Abbott Liu <liuwenliang@huawei.com>
Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
addressable by a 32bit architecture) out of the virtual address
space to use as shadow memory for KASan as follows:
+----+ 0xffffffff
| |\
| | |-> Static kernel image (vmlinux) BSS and page table
| |/
+----+ PAGE_OFFSET
| |\
| | |-> Loadable kernel modules virtual address space area
| |/
+----+ MODULES_VADDR = KASAN_SHADOW_END
| |\
| | |-> The shadow area of kernel virtual address.
| |/
+----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
| |\ shadow address of MODULES_VADDR
| | |
| | |
| | |-> The user space area in lowmem. The kernel address
| | | sanitizer do not use this space, nor does it map it.
| | |
| | |
| | |
| | |
| |/
------ 0
0 .. TASK_SIZE is the memory that can be used by shared
userspace/kernelspace. It us used for userspace processes and for
passing parameters and memory buffers in system calls etc. We do not
need to shadow this area.
KASAN_SHADOW_START:
This value begins with the MODULE_VADDR's shadow address. It is the
start of kernel virtual space. Since we have modules to load, we need
to cover also that area with shadow memory so we can find memory
bugs in modules.
KASAN_SHADOW_END
This value is the 0x100000000's shadow address: the mapping that would
be after the end of the kernel memory at 0xffffffff. It is the end of
kernel address sanitizer shadow area. It is also the start of the
module area.
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;
As you would expect, >> 3 is equal to dividing by 8, meaning each
byte in the shadow memory covers 8 bytes of kernel memory, so one
bit shadow memory per byte of kernel memory is used.
The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
on the VMSPLIT layout of the system: the kernel and userspace can
split up lowmem in different ways according to needs, so we calculate
the shadow offset depending on this.
When kasan is enabled, the definition of TASK_SIZE is not an 8-bit
rotated constant, so we need to modify the TASK_SIZE access code in the
*.s file.
The kernel and modules may use different amounts of memory,
according to the VMSPLIT configuration, which in turn
determines the PAGE_OFFSET.
We use the following KASAN_SHADOW_OFFSETs depending on how the
virtual memory is split up:
- 0x1f000000 if we have 1G userspace / 3G kernelspace split:
- The kernel address space is 3G (0xc0000000)
- PAGE_OFFSET is then set to 0x40000000 so the kernel static
image (vmlinux) uses addresses 0x40000000 .. 0xffffffff
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x3f000000
so the modules use addresses 0x3f000000 .. 0x3fffffff
- So the addresses 0x3f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0xc1000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x18200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x26e00000, to
KASAN_SHADOW_END at 0x3effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x3f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000
KASAN_SHADOW_OFFSET = 0x1f000000
- 0x5f000000 if we have 2G userspace / 2G kernelspace split:
- The kernel space is 2G (0x80000000)
- PAGE_OFFSET is set to 0x80000000 so the kernel static
image uses 0x80000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0x7f000000
so the modules use addresses 0x7f000000 .. 0x7fffffff
- So the addresses 0x7f000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x81000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x10200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0x6ee00000, to
KASAN_SHADOW_END at 0x7effffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0x7f000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3)
KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000
KASAN_SHADOW_OFFSET = 0x5f000000
- 0x9f000000 if we have 3G userspace / 1G kernelspace split,
and this is the default split for ARM:
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xc0000000 so the kernel static
image uses 0xc0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xbf000000
so the modules use addresses 0xbf000000 .. 0xbfffffff
- So the addresses 0xbf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x41000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x08200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xb6e00000, to
KASAN_SHADOW_END at 0xbfffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xbf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000
KASAN_SHADOW_OFFSET = 0x9f000000
- 0x8f000000 if we have 3G userspace / 1G kernelspace with
full 1 GB low memory (VMSPLIT_3G_OPT):
- The kernel address space is 1GB (0x40000000)
- PAGE_OFFSET is set to 0xb0000000 so the kernel static
image uses 0xb0000000 .. 0xffffffff.
- On top of that we have the MODULES_VADDR which under
the worst case (using ARM instructions) is
PAGE_OFFSET - 16M (0x01000000) = 0xaf000000
so the modules use addresses 0xaf000000 .. 0xaffffff
- So the addresses 0xaf000000 .. 0xffffffff need to be
covered with shadow memory. That is 0x51000000 bytes
of memory.
- 1/8 of that is needed for its shadow memory, so
0x0a200000 bytes of shadow memory is needed. We
"steal" that from the remaining lowmem.
- The KASAN_SHADOW_START becomes 0xa4e00000, to
KASAN_SHADOW_END at 0xaeffffff.
- Now we can calculate the KASAN_SHADOW_OFFSET for any
kernel address as 0xaf000000 needs to map to the first
byte of shadow memory and 0xffffffff needs to map to
the last byte of shadow memory. Since:
SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET
KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3)
KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000
KASAN_SHADOW_OFFSET = 0x8f000000
- The default value of 0xffffffff for KASAN_SHADOW_OFFSET
is an error value. We should always match one of the
above shadow offsets.
When we do this, TASK_SIZE will sometimes get a bit odd values
that will not fit into immediate mov assembly instructions.
To account for this, we need to rewrite some assembly using
TASK_SIZE like this:
- mov r1, #TASK_SIZE
+ ldr r1, =TASK_SIZE
or
- cmp r4, #TASK_SIZE
+ ldr r0, =TASK_SIZE
+ cmp r4, r0
this is done to avoid the immediate #TASK_SIZE that need to
fit into a limited number of bits.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Rewrote the PMD clearing code to take into account that
KASan may not always be adjacent to MODULES_VADDR: if we
compile for thumb, then there will be an 8 MB hole between
the shadow memory and MODULES_VADDR. Make this explicit and
use the KASAN defines with an explicit ifdef so it is clear
what is going on in the prepare_page_table().
- Patch memory.rst to reflect the location of KASan shadow
memory.
ChangeLog v6->v7:
- Use the SPDX license identifier.
- Rewrote the commit message and updates the illustration.
- Move KASAN_OFFSET Kconfig set-up into this patch and put it
right after PAGE_OFFSET so it is clear how this works, and
we have all defines in one patch.
- Added KASAN_SHADOW_OFFSET of 0x8f000000 for 3G_OPT.
See the calculation in the commit message.
- Updated the commit message with detailed information on
how KASAN_SHADOW_OFFSET is obtained for the different
VMSPLIT/PAGE_OFFSET options.
---
Documentation/arm/memory.rst | 5 ++
arch/arm/Kconfig | 9 ++++
arch/arm/include/asm/kasan_def.h | 81 ++++++++++++++++++++++++++++++
arch/arm/include/asm/memory.h | 5 ++
arch/arm/include/asm/uaccess-asm.h | 2 +-
arch/arm/kernel/entry-armv.S | 3 +-
arch/arm/kernel/entry-common.S | 9 ++--
arch/arm/mm/mmu.c | 18 +++++++
8 files changed, 127 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/include/asm/kasan_def.h
diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst
index 0521b4ce5c96..36bae90cfb1e 100644
--- a/Documentation/arm/memory.rst
+++ b/Documentation/arm/memory.rst
@@ -72,6 +72,11 @@ MODULES_VADDR MODULES_END-1 Kernel module space
Kernel modules inserted via insmod are
placed here using dynamic mappings.
+TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use.
+ The range from MODULES_VADDR to the top
+ of the memory is shadowed here with 1 bit
+ per byte of memory.
+
00001000 TASK_SIZE-1 User space mappings
Per-thread mappings are placed here via
the mmap() system call.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e00d94b16658..0489b8d07172 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1324,6 +1324,15 @@ config PAGE_OFFSET
default 0xB0000000 if VMSPLIT_3G_OPT
default 0xC0000000
+config KASAN_SHADOW_OFFSET
+ hex
+ depends on KASAN
+ default 0x1f000000 if PAGE_OFFSET=0x40000000
+ default 0x5f000000 if PAGE_OFFSET=0x80000000
+ default 0x9f000000 if PAGE_OFFSET=0xC0000000
+ default 0x8f000000 if PAGE_OFFSET=0xB0000000
+ default 0xffffffff
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
diff --git a/arch/arm/include/asm/kasan_def.h b/arch/arm/include/asm/kasan_def.h
new file mode 100644
index 000000000000..5739605aa7cf
--- /dev/null
+++ b/arch/arm/include/asm/kasan_def.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * arch/arm/include/asm/kasan_def.h
+ *
+ * Copyright (c) 2018 Huawei Technologies Co., Ltd.
+ *
+ * Author: Abbott Liu <liuwenliang@huawei.com>
+ */
+
+#ifndef __ASM_KASAN_DEF_H
+#define __ASM_KASAN_DEF_H
+
+#ifdef CONFIG_KASAN
+
+/*
+ * Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
+ * the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
+ * addressable by a 32bit architecture) out of the virtual address
+ * space to use as shadow memory for KASan as follows:
+ *
+ * +----+ 0xffffffff
+ * | | \
+ * | | |-> Static kernel image (vmlinux) BSS and page table
+ * | |/
+ * +----+ PAGE_OFFSET
+ * | | \
+ * | | |-> Loadable kernel modules virtual address space area
+ * | |/
+ * +----+ MODULES_VADDR = KASAN_SHADOW_END
+ * | | \
+ * | | |-> The shadow area of kernel virtual address.
+ * | |/
+ * +----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
+ * | |\ shadow address of MODULES_VADDR
+ * | | |
+ * | | |
+ * | | |-> The user space area in lowmem. The kernel address
+ * | | | sanitizer do not use this space, nor does it map it.
+ * | | |
+ * | | |
+ * | | |
+ * | | |
+ * | |/
+ * ------ 0
+ *
+ * 1) KASAN_SHADOW_START
+ * This value begins with the MODULE_VADDR's shadow address. It is the
+ * start of kernel virtual space. Since we have modules to load, we need
+ * to cover also that area with shadow memory so we can find memory
+ * bugs in modules.
+ *
+ * 2) KASAN_SHADOW_END
+ * This value is the 0x100000000's shadow address: the mapping that would
+ * be after the end of the kernel memory at 0xffffffff. It is the end of
+ * kernel address sanitizer shadow area. It is also the start of the
+ * module area.
+ *
+ * 3) 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;
+ *
+ * As you would expect, >> 3 is equal to dividing by 8, meaning each
+ * byte in the shadow memory covers 8 bytes of kernel memory, so one
+ * bit shadow memory per byte of kernel memory is used.
+ *
+ * The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
+ * on the VMSPLIT layout of the system: the kernel and userspace can
+ * split up lowmem in different ways according to needs, so we calculate
+ * the shadow offset depending on this.
+ */
+
+#define KASAN_SHADOW_SCALE_SHIFT 3
+#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#define KASAN_SHADOW_END ((UL(1) << (32 - KASAN_SHADOW_SCALE_SHIFT)) \
+ + KASAN_SHADOW_OFFSET)
+#define KASAN_SHADOW_START ((KASAN_SHADOW_END >> 3) + KASAN_SHADOW_OFFSET)
+
+#endif
+#endif
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 99035b5891ef..5cfa9e5dc733 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -18,6 +18,7 @@
#ifdef CONFIG_NEED_MACH_MEMORY_H
#include <mach/memory.h>
#endif
+#include <asm/kasan_def.h>
/* PAGE_OFFSET - the virtual address of the start of the kernel image */
#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
@@ -28,7 +29,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/include/asm/uaccess-asm.h b/arch/arm/include/asm/uaccess-asm.h
index 907571fd05c6..e6eb7a2aaf1e 100644
--- a/arch/arm/include/asm/uaccess-asm.h
+++ b/arch/arm/include/asm/uaccess-asm.h
@@ -85,7 +85,7 @@
*/
.macro uaccess_entry, tsk, tmp0, tmp1, tmp2, disable
ldr \tmp1, [\tsk, #TI_ADDR_LIMIT]
- mov \tmp2, #TASK_SIZE
+ ldr \tmp2, =TASK_SIZE
str \tmp2, [\tsk, #TI_ADDR_LIMIT]
DACR( mrc p15, 0, \tmp0, c3, c0, 0)
DACR( str \tmp0, [sp, #SVC_DACR])
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 55a47df04773..c4220f51fcf3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -427,7 +427,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
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 271cb8a1eba1..fee279e28a72 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -50,7 +50,8 @@ __ret_fast_syscall:
UNWIND(.cantunwind )
disable_irq_notrace @ disable interrupts
ldr r2, [tsk, #TI_ADDR_LIMIT]
- cmp r2, #TASK_SIZE
+ ldr r1, =TASK_SIZE
+ cmp r2, r1
blne addr_limit_check_failed
ldr r1, [tsk, #TI_FLAGS] @ re-check for syscall tracing
tst r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -87,7 +88,8 @@ __ret_fast_syscall:
#endif
disable_irq_notrace @ disable interrupts
ldr r2, [tsk, #TI_ADDR_LIMIT]
- cmp r2, #TASK_SIZE
+ ldr r1, =TASK_SIZE
+ cmp r2, r1
blne addr_limit_check_failed
ldr r1, [tsk, #TI_FLAGS] @ re-check for syscall tracing
tst r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -128,7 +130,8 @@ ret_slow_syscall:
disable_irq_notrace @ disable interrupts
ENTRY(ret_to_user_from_irq)
ldr r2, [tsk, #TI_ADDR_LIMIT]
- cmp r2, #TASK_SIZE
+ ldr r1, =TASK_SIZE
+ cmp r2, r1
blne addr_limit_check_failed
ldr r1, [tsk, #TI_FLAGS]
tst r1, #_TIF_WORK_MASK
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 732c856c357d..89728232a99a 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -30,6 +30,7 @@
#include <asm/procinfo.h>
#include <asm/memory.h>
#include <asm/pgalloc.h>
+#include <asm/kasan_def.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -1266,8 +1267,25 @@ static inline void prepare_page_table(void)
/*
* Clear out all the mappings below the kernel image.
*/
+#ifdef CONFIG_KASAN
+ /*
+ * KASan's shadow memory inserts itself between the TASK_SIZE
+ * and MODULES_VADDR. Do not clear the KASan shadow memory mappings.
+ */
+ for (addr = 0; addr < KASAN_SHADOW_START; addr += PMD_SIZE)
+ pmd_clear(pmd_off_k(addr));
+ /*
+ * Skip over the KASan shadow area. KASAN_SHADOW_END is sometimes
+ * equal to MODULES_VADDR and then we exit the pmd clearing. If we
+ * are using a thumb-compiled kernel, there there will be 8MB more
+ * to clear as KASan always offset to 16 MB below MODULES_VADDR.
+ */
+ for (addr = KASAN_SHADOW_END; addr < MODULES_VADDR; addr += PMD_SIZE)
+ pmd_clear(pmd_off_k(addr));
+#else
for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
pmd_clear(pmd_off_k(addr));
+#endif
#ifdef CONFIG_XIP_KERNEL
/* The XIP kernel is mapped in the module area -- skip over it */
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 5/6 v14] ARM: Initialize the mapping of KASan shadow memory
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
` (3 preceding siblings ...)
2020-10-01 15:22 ` [PATCH 4/6 v14] ARM: Define the virtual space of KASan's shadow region Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 15:22 ` [PATCH 6/6 v14] ARM: Enable KASan for ARM Linus Walleij
` (2 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Linus Walleij, kasan-dev, Alexander Potapenko,
linux-arm-kernel, Dmitry Vyukov
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 is 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 does not need to track, and we
allocate a 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.
When using KASan we also need to increase the THREAD_SIZE_ORDER
from 1 to 2 as the extra calls for shadow memory uses quite a bit
of stack.
As we need to make a temporary copy of the PGD when setting up
shadow memory we create a helpful PGD_SIZE definition for both
LPAE and non-LPAE setups.
The KASan core code unconditionally calls pud_populate() so this
needs to be changed from BUG() to do {} while (0) when building
with KASan enabled.
After the initial development by Andre Ryabinin several modifications
have been made to this code:
Abbott Liu <liuwenliang@huawei.com>
- Add support ARM LPAE: If LPAE is enabled, KASan shadow region's
mapping table need be copied in the pgd_alloc() function.
- Change kasan_pte_populate,kasan_pmd_populate,kasan_pud_populate,
kasan_pgd_populate from .meminit.text section to .init.text section.
Reported by Florian Fainelli <f.fainelli@gmail.com>
Linus Walleij <linus.walleij@linaro.org>:
- Drop the custom mainpulation of TTBR0 and just use
cpu_switch_mm() to switch the pgd table.
- Adopt to handle 4th level page tabel folding.
- Rewrite the entire page directory and page entry initialization
sequence to be recursive based on ARM64:s kasan_init.c.
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Co-developed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- Provide more elaborate prints of how virtual kernel memory
is mapped to the allocated lowmem pages.
- Make sure to also map the memory around the __atags_pointer:
this memory is used for the device tree blob (DTB) and will be
accessed by the device tree parser. We were just lucky that
this was mostly in some acceptable memory location until now.
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Do not try to shadow highmem memory blocks. (Ard)
- Provoke a build bug if the entire shadow memory doesn't fit
inside a single pgd_index() (Ard)
- Move the pointer to (unsigned long) casts into the create_mapping()
function. (Ard)
- After setting up the shadow memory make sure to issue
local_flush_tlb_all() so that we refresh all the global mappings. (Ard)
- Simplify pte_populate() (Ard)
- Skip over pud population as well as p4d. (Ard)
- Drop the stop condition pmd_none(*pmdp) in the pmd population
loop. (Ard)
- Stop passing around the node (NUMA) parameter in the init code,
we are not expecting any NUMA architectures to be introduced into
ARM32 so just hardcode NUMA_NO_NODE when calling
memblock_alloc_try_nid().
ChangeLog v10->v11:
- Fix compilation on LPAE systems.
- Move the check for valid pgdp, pudp and pmdp into the loop for
each level moving over the directory pointers: we were just lucky
that we just needed one directory for each level so this fixes
the pmdp issue with LPAE and KASan now works like a charm on
LPAE as well.
- Fold fourth level page directory (p4d) into the global page directory
pgd and just skip into the page upper directory (pud) directly. We
do not anticipate that ARM32 will every use 5-level page tables.
- Simplify the ifdeffery around the temporary pgd.
- Insert a comment about pud_populate() that is unconditionally called
by the KASan core code.
ChangeLog v9->v10:
- Rebase onto v5.8-rc1
- add support for folded p4d page tables, use the primitives necessary
for the 4th level folding, add (empty) walks of p4d level.
- Use the <linux/pgtable.h> header file that has now appeared as part
of the VM consolidation series.
- Use a recursive method to walk pgd/p4d/pud/pmd/pte instead of the
separate early/main calls and the flat call structure used in the
old code. This was inspired by the ARM64 KASan init code.
- Assume authorship of this code, I have now written the majority of
it so the blame is on me and noone else.
ChangeLog v8->v9:
- Drop the custom CP15 manipulation and cache flushing for swapping
TTBR0 and instead just use cpu_switch_mm().
- Collect Ard's tags.
ChangeLog v7->v8:
- Rebased.
ChangeLog v6->v7:
- Use SPDX identifer for the license.
- Move the TTBR0 accessor calls into this patch.
---
arch/arm/include/asm/kasan.h | 32 ++++
arch/arm/include/asm/pgalloc.h | 8 +-
arch/arm/include/asm/thread_info.h | 8 +
arch/arm/kernel/head-common.S | 3 +
arch/arm/kernel/setup.c | 2 +
arch/arm/mm/Makefile | 3 +
arch/arm/mm/kasan_init.c | 286 +++++++++++++++++++++++++++++
arch/arm/mm/pgd.c | 16 +-
8 files changed, 356 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 000000000000..56b954db160e
--- /dev/null
+++ b/arch/arm/include/asm/kasan.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * arch/arm/include/asm/kasan.h
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+ *
+ */
+
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifdef CONFIG_KASAN
+
+#include <asm/kasan_def.h>
+
+#define KASAN_SHADOW_SCALE_SHIFT 3
+
+/*
+ * The compiler uses a 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 15f4674715f8..fdee1f04f4f3 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -21,6 +21,7 @@
#define _PAGE_KERNEL_TABLE (PMD_TYPE_TABLE | PMD_BIT4 | PMD_DOMAIN(DOMAIN_KERNEL))
#ifdef CONFIG_ARM_LPAE
+#define PGD_SIZE (PTRS_PER_PGD * sizeof(pgd_t))
static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
{
@@ -28,14 +29,19 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
}
#else /* !CONFIG_ARM_LPAE */
+#define PGD_SIZE (PAGE_SIZE << 2)
/*
* Since we have only two-level page tables, these are trivial
*/
#define pmd_alloc_one(mm,addr) ({ BUG(); ((pmd_t *)2); })
#define pmd_free(mm, pmd) do { } while (0)
+#ifdef CONFIG_KASAN
+/* The KASan core unconditionally calls pud_populate() on all architectures */
+#define pud_populate(mm,pmd,pte) do { } while (0)
+#else
#define pud_populate(mm,pmd,pte) BUG()
-
+#endif
#endif /* CONFIG_ARM_LPAE */
extern pgd_t *pgd_alloc(struct mm_struct *mm);
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 536b6b979f63..56fae7861fd3 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -13,7 +13,15 @@
#include <asm/fpstate.h>
#include <asm/page.h>
+#ifdef CONFIG_KASAN
+/*
+ * KASan uses a lot of extra stack space so the thread size order needs to
+ * be increased.
+ */
+#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 6840c7c60a85..89c80154b9ef 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -111,6 +111,9 @@ __mmap_switched:
str r8, [r2] @ Save atags pointer
cmp r3, #0
strne r10, [r3] @ Save control register values
+#ifdef CONFIG_KASAN
+ bl kasan_early_init
+#endif
mov lr, #0
b start_kernel
ENDPROC(__mmap_switched)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d0562cdc919e..8b28eca23326 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -58,6 +58,7 @@
#include <asm/unwind.h>
#include <asm/memblock.h>
#include <asm/virt.h>
+#include <asm/kasan.h>
#include "atags.h"
@@ -1132,6 +1133,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 99699c32d8a5..4536159bc8fa 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -113,3 +113,6 @@ obj-$(CONFIG_CACHE_L2X0_PMU) += cache-l2x0-pmu.o
obj-$(CONFIG_CACHE_XSC3L2) += cache-xsc3l2.o
obj-$(CONFIG_CACHE_TAUROS2) += cache-tauros2.o
obj-$(CONFIG_CACHE_UNIPHIER) += cache-uniphier.o
+
+KASAN_SANITIZE_kasan_init.o := n
+obj-$(CONFIG_KASAN) += kasan_init.o
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
new file mode 100644
index 000000000000..6fd9bc70970f
--- /dev/null
+++ b/arch/arm/mm/kasan_init.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This file contains kasan initialization code for ARM.
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#define pr_fmt(fmt) "kasan: " fmt
+#include <linux/kasan.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/sched/task.h>
+#include <linux/start_kernel.h>
+#include <linux/pgtable.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/procinfo.h>
+#include <asm/proc-fns.h>
+
+#include "mm.h"
+
+static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
+
+pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
+
+extern unsigned long __atags_pointer;
+
+static __init void *kasan_alloc_block(size_t size)
+{
+ return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
+ MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
+}
+
+static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
+ unsigned long end, bool early)
+{
+ unsigned long next;
+ pte_t *ptep = pte_offset_kernel(pmdp, addr);
+
+ do {
+ pte_t entry;
+
+ next = addr + PAGE_SIZE;
+
+ if (!early) {
+ void *p = kasan_alloc_block(PAGE_SIZE);
+ if (!p) {
+ panic("%s failed to alloc pte for address 0x%lx\n",
+ __func__, addr);
+ return;
+ }
+ memset(p, KASAN_SHADOW_INIT, PAGE_SIZE);
+ entry = pfn_pte(virt_to_pfn(p),
+ __pgprot(pgprot_val(PAGE_KERNEL)));
+ } else if (pte_none(READ_ONCE(*ptep))) {
+ /*
+ * The early shadow memory is mapping all KASan
+ * operations to one and the same page in memory,
+ * "kasan_early_shadow_page" so that the instrumentation
+ * will work on a scratch area until we can set up the
+ * proper KASan shadow memory.
+ */
+ entry = pfn_pte(virt_to_pfn(kasan_early_shadow_page),
+ __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
+ } else {
+ /*
+ * Early shadow mappings are PMD_SIZE aligned, so if the
+ * first entry is already set, they must all be set.
+ */
+ return;
+ }
+
+ set_pte_at(&init_mm, addr, ptep, entry);
+ } while (ptep++, addr = next, addr != end);
+}
+
+/*
+ * The pmd (page middle directory) is only used on LPAE
+ */
+static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
+ unsigned long end, bool early)
+{
+ unsigned long next;
+ pmd_t *pmdp = pmd_offset(pudp, addr);
+
+ do {
+ if (pmd_none(*pmdp)) {
+ void *p = early ? kasan_early_shadow_pte :
+ kasan_alloc_block(PAGE_SIZE);
+
+ if (!p) {
+ panic("%s failed to allocate pmd for address 0x%lx\n",
+ __func__, addr);
+ return;
+ }
+ pmd_populate_kernel(&init_mm, pmdp, p);
+ flush_pmd_entry(pmdp);
+ }
+
+ next = pmd_addr_end(addr, end);
+ kasan_pte_populate(pmdp, addr, next, early);
+ } while (pmdp++, addr = next, addr != end);
+}
+
+static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
+ bool early)
+{
+ unsigned long next;
+ pgd_t *pgdp;
+ p4d_t *p4dp;
+ pud_t *pudp;
+
+ pgdp = pgd_offset_k(addr);
+
+ do {
+ /* Allocate and populate the PGD if it doesn't already exist */
+ if (!early && pgd_none(*pgdp)) {
+ void *p = kasan_alloc_block(PAGE_SIZE);
+
+ if (!p) {
+ panic("%s failed to allocate pgd for address 0x%lx\n",
+ __func__, addr);
+ return;
+ }
+ pgd_populate(&init_mm, pgdp, p);
+ }
+
+ next = pgd_addr_end(addr, end);
+ /*
+ * We just immediately jump over the p4d and pud page
+ * directories since we believe ARM32 will never gain four
+ * nor five level page tables.
+ */
+ p4dp = p4d_offset(pgdp, addr);
+ pudp = pud_offset(p4dp, addr);
+
+ kasan_pmd_populate(pudp, addr, next, early);
+ } while (pgdp++, addr = next, addr != end);
+}
+
+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_END - (1UL << 29)) != KASAN_SHADOW_OFFSET);
+ /*
+ * We walk the page table and set all of the shadow memory to point
+ * to the scratch page.
+ */
+ kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, true);
+}
+
+static void __init clear_pgds(unsigned long start,
+ unsigned long end)
+{
+ for (; start && start < end; start += PMD_SIZE)
+ pmd_clear(pmd_off_k(start));
+}
+
+static int __init create_mapping(void *start, void *end)
+{
+ void *shadow_start, *shadow_end;
+
+ shadow_start = kasan_mem_to_shadow(start);
+ shadow_end = kasan_mem_to_shadow(end);
+
+ pr_info("Mapping kernel virtual memory block: %px-%px at shadow: %px-%px\n",
+ start, end, shadow_start, shadow_end);
+
+ kasan_pgd_populate((unsigned long)shadow_start & PAGE_MASK,
+ (unsigned long)shadow_end, false);
+ return 0;
+}
+
+void __init kasan_init(void)
+{
+ struct memblock_region *reg;
+ unsigned long atags;
+ int i;
+
+ /*
+ * We are going to perform proper setup of shadow memory.
+ *
+ * At first we should unmap early shadow (clear_pgds() call bellow).
+ * However, instrumented code can't execute without shadow memory.
+ *
+ * To keep the early shadow memory MMU tables around while setting up
+ * the proper shadow memory, we copy swapper_pg_dir (the initial page
+ * table) to tmp_pgd_table and use that to keep the early shadow memory
+ * mapped until the full shadow setup is finished. Then we swap back
+ * to the proper swapper_pg_dir.
+ */
+
+ memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table));
+#ifdef CONFIG_ARM_LPAE
+ /* We need to be in the same PGD or this won't work */
+ BUILD_BUG_ON(pgd_index(KASAN_SHADOW_START) !=
+ pgd_index(KASAN_SHADOW_END));
+ memcpy(tmp_pmd_table,
+ pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
+ sizeof(tmp_pmd_table));
+ set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
+ __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
+#endif
+ cpu_switch_mm(tmp_pgd_table, &init_mm);
+ clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
+
+ kasan_populate_early_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);
+
+ /* Do not attempt to shadow highmem */
+ if (reg->base >= arm_lowmem_limit) {
+ pr_info("Skip highmem block %px-%px\n",
+ start, end);
+ continue;
+ }
+ if (reg->base + reg->size > arm_lowmem_limit) {
+ pr_info("Truncate memory block %px-%px\n to %px-%px\n",
+ start, end, start, __va(arm_lowmem_limit));
+ end = __va(arm_lowmem_limit);
+ }
+ if (start >= end) {
+ pr_info("Skipping invalid memory block %px-%px\n",
+ start, end);
+ continue;
+ }
+
+ create_mapping(start, end);
+ }
+
+ /*
+ * 1. The module global variables are in MODULES_VADDR ~ MODULES_END,
+ * so we need to map this area.
+ * 2. PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR
+ * ~ MODULES_END's shadow is in the same PMD_SIZE, so we can't
+ * use kasan_populate_zero_shadow.
+ */
+ create_mapping((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE));
+
+ /* Populate the data area around the ATAGs pointer (also used for DTB) */
+ atags = __atags_pointer;
+ atags &= PMD_MASK;
+ create_mapping((void *)phys_to_virt(atags),
+ (void *)phys_to_virt(atags + PMD_SIZE));
+
+ /*
+ * KAsan may reuse the contents of kasan_early_shadow_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_early_shadow_pte[i],
+ pfn_pte(virt_to_pfn(kasan_early_shadow_page),
+ __pgprot(pgprot_val(PAGE_KERNEL)
+ | L_PTE_RDONLY)));
+ local_flush_tlb_all();
+
+ memset(kasan_early_shadow_page, 0, PAGE_SIZE);
+ cpu_switch_mm(swapper_pg_dir, &init_mm);
+ pr_info("Kernel address sanitizer initialized\n");
+ init_task.kasan_depth = 0;
+}
diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
index c5e1b27046a8..f8e9bc58a84f 100644
--- a/arch/arm/mm/pgd.c
+++ b/arch/arm/mm/pgd.c
@@ -66,7 +66,21 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
new_pmd = pmd_alloc(mm, new_pud, 0);
if (!new_pmd)
goto no_pmd;
-#endif
+#ifdef CONFIG_KASAN
+ /*
+ * Copy PMD table for KASAN shadow mappings.
+ */
+ init_pgd = pgd_offset_k(TASK_SIZE);
+ init_p4d = p4d_offset(init_pgd, TASK_SIZE);
+ init_pud = pud_offset(init_p4d, 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 /* CONFIG_KASAN */
+#endif /* CONFIG_LPAE */
if (!vectors_high()) {
/*
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 6/6 v14] ARM: Enable KASan for ARM
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
` (4 preceding siblings ...)
2020-10-01 15:22 ` [PATCH 5/6 v14] ARM: Initialize the mapping of KASan shadow memory Linus Walleij
@ 2020-10-01 15:22 ` Linus Walleij
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
2020-10-06 13:21 ` Linus Walleij
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 15:22 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Linus Walleij, kasan-dev, Alexander Potapenko,
linux-arm-kernel, Andrey Ryabinin, Dmitry Vyukov
From: Andrey Ryabinin <ryabinin@virtuozzo.com>
This patch enables the kernel address sanitizer for ARM. XIP_KERNEL
has not been tested and is therefore not allowed for now.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v13->v14:
- Resend with the other patches.
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Fix the arch feature matrix for Arm to include KASan.
- Collect Ard's tags.
ChangeLog v7->v8:
- Moved the hacks to __ADDRESS_SANITIZE__ to the patch
replacing the memory access functions.
- Moved the definition of KASAN_OFFSET out of this patch
and to the patch that defines the virtual memory used by
KASan.
---
Documentation/dev-tools/kasan.rst | 4 ++--
Documentation/features/debug/KASAN/arch-support.txt | 2 +-
arch/arm/Kconfig | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 38fd5681fade..050dcd346144 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -18,8 +18,8 @@ out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
-Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
-riscv architectures, and tag-based KASAN is supported only for arm64.
+Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390
+and riscv architectures, and tag-based KASAN is supported only for arm64.
Usage
-----
diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt
index c3fe9b266e7b..b2288dc14b72 100644
--- a/Documentation/features/debug/KASAN/arch-support.txt
+++ b/Documentation/features/debug/KASAN/arch-support.txt
@@ -8,7 +8,7 @@
-----------------------
| alpha: | TODO |
| arc: | TODO |
- | arm: | TODO |
+ | arm: | ok |
| arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0489b8d07172..873bd26f5d43 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -66,6 +66,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 && !XIP_KERNEL
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
` (5 preceding siblings ...)
2020-10-01 15:22 ` [PATCH 6/6 v14] ARM: Enable KASan for ARM Linus Walleij
@ 2020-10-01 19:19 ` Florian Fainelli
2020-10-01 20:34 ` Linus Walleij
` (2 more replies)
2020-10-06 13:21 ` Linus Walleij
7 siblings, 3 replies; 36+ messages in thread
From: Florian Fainelli @ 2020-10-01 19:19 UTC (permalink / raw)
To: Linus Walleij, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3626 bytes --]
On 10/1/2020 8:22 AM, Linus Walleij wrote:
> This is the 14th iteration of KASan for ARM/Aarch32.
>
> I have added one patch in the beginning of the series to
> fix the issue when the DTB (often attached DTB) ends up
> in lowmem. It also amends ARM to copy the device tree
> instead of just unflattening it and using it from where
> it is.
>
> This fixes my particular issue on the Qualcomm APQ8060
> and I hope it may also solve Florian's issue and what
> Ard has been seeing. If you inspect patch 1/6 you can
> see what has been going on for me. My hypothesis about
> what was going on was mostly right.
>
> You are encouraged to test this patch set to find memory out
> of bounds bugs with ARM32 platforms and drivers.
>
> There is a git branch you can pull in:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
It does appear to be slight better, although all platforms that I have
where memory starts at physical address 0 cannot boot, attached logs
which are all more or less the same.
The physical memory map looks like this:
0..3GB -> DRAM
3GB..4GB -> Registers, Boot ROM, Boot SRAM
4GB..12GB -> DRAM extension
Do any of the platforms you use for testing have a similar memory map?
Could you try to contrive a QEMU machine to have something similar in
case that helps reproducing these failures?
Thanks
>
> Abbott Liu (1):
> ARM: Define the virtual space of KASan's shadow region
>
> Andrey Ryabinin (3):
> ARM: Disable KASan instrumentation for some code
> ARM: Replace string mem* functions for KASan
> ARM: Enable KASan for ARM
>
> Linus Walleij (2):
> ARM: Handle a device tree in lowmem
> ARM: Initialize the mapping of KASan shadow memory
>
> Documentation/arm/memory.rst | 5 +
> Documentation/dev-tools/kasan.rst | 4 +-
> .../features/debug/KASAN/arch-support.txt | 2 +-
> arch/arm/Kconfig | 10 +
> arch/arm/boot/compressed/Makefile | 1 +
> arch/arm/boot/compressed/string.c | 19 ++
> arch/arm/include/asm/kasan.h | 32 ++
> arch/arm/include/asm/kasan_def.h | 81 +++++
> arch/arm/include/asm/memory.h | 5 +
> arch/arm/include/asm/pgalloc.h | 8 +-
> arch/arm/include/asm/prom.h | 5 +
> arch/arm/include/asm/string.h | 21 ++
> arch/arm/include/asm/thread_info.h | 8 +
> arch/arm/include/asm/uaccess-asm.h | 2 +-
> arch/arm/kernel/devtree.c | 14 +-
> arch/arm/kernel/entry-armv.S | 3 +-
> arch/arm/kernel/entry-common.S | 9 +-
> arch/arm/kernel/head-common.S | 7 +-
> arch/arm/kernel/setup.c | 10 +-
> arch/arm/kernel/unwind.c | 6 +-
> 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/kasan_init.c | 286 ++++++++++++++++++
> arch/arm/mm/mmu.c | 55 +++-
> arch/arm/mm/pgd.c | 16 +-
> arch/arm/vdso/Makefile | 2 +
> 28 files changed, 608 insertions(+), 19 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
[-- Attachment #2: 7250-bselinux-rack-20.log --]
[-- Type: text/plain, Size: 7573 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM97250SV
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x000000003cc00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000003dffefff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003dffefff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003dffefff]
[ 0.000000] kasan: Truncate memory block c0000000-fdfff000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bcdffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bcdffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bcdffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bce00000
[ 0.000000] r7 : bcdfffff r6 : eeffffff r5 : eefff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : eefff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: eefff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 eefff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 00000018 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b7600000 ef474fa0 c0006dd8 c16e2060 b75f4000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2f00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2f00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 3dfff000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 00000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 3dfff000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f3 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 0781a000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 0781a000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 0781a000 420f00f3 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 0781a000
[ 0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:eefff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:eefff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b75f4000 r9:c16e2060 r8:c0006dd8 r7:ef474fa0 r6:b7600000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2f00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:3dfff000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f3 r8:0781a000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f3 r8:0781a000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace fc1cf4c40c8932da ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #3: 7364-bselinux-rack-17.log --]
[-- Type: text/plain, Size: 7573 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM97364SV
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x000000003cc00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000003dffefff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003dffefff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003dffefff]
[ 0.000000] kasan: Truncate memory block c0000000-fdfff000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bcdffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bcdffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bcdffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bce00000
[ 0.000000] r7 : bcdfffff r6 : eeffffff r5 : eefff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : eefff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: eefff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 eefff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 00000018 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b7600000 ef474fa0 c0006dd8 c16e2060 b75f4000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2f00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2f00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 3dfff000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 00000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 3dfff000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f3 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 07819000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 07819000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 07819000 420f00f3 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07819000
[ 0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:eefff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:eefff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b75f4000 r9:c16e2060 r8:c0006dd8 r7:ef474fa0 r6:b7600000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2f00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:3dfff000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f3 r8:07819000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f3 r8:07819000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace 3c426ea188f7e274 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #4: 7366-bselinux-rack-18.log --]
[-- Type: text/plain, Size: 7656 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM97366SV_V20_NO_PKT2
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x00000000bfffefff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003dffffff]
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000bfffefff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000bfffefff]
[ 0.000000] kasan: Truncate memory block c0000000-fe000000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bcbffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bcbffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bcc00000
[ 0.000000] r7 : bcbfffff r6 : edffffff r5 : edfff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : edfff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: edfff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 edfff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 00000019 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b7c00000 ee1f1f88 c0006df0 c16e2060 b7bf1000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2e00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2e00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 3e000000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 80000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 3e000000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f3 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 0780e000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 0780e000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 0780e000 420f00f3 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 0780e000
[ 0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:edfff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:edfff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b7bf1000 r9:c16e2060 r8:c0006df0 r7:ee1f1f88 r6:b7c00000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2e00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:3e000000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f3 r8:0780e000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f3 r8:0780e000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace 692b945dc0693f87 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #5: 7445-bselinux-rack-09.log --]
[-- Type: text/plain, Size: 7645 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM97445VMS
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x00000000bfffefff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003dffffff]
[ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffefff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000bfffefff]
[ 0.000000] kasan: Truncate memory block c0000000-fe000000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bc9ffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bc9ffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bc9ffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bca00000
[ 0.000000] r7 : bc9fffff r6 : ecffffff r5 : ecfff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : ecfff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: ecfff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 ecfff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 00000019 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b8200000 ed1eef70 c0006e08 c16e2060 b81ee000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2d00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2d00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 3e000000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 40000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 3e000000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f3 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 07723000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 07723000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 07723000 420f00f3 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07723000
[ 0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:ecfff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:ecfff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b81ee000 r9:c16e2060 r8:c0006e08 r7:ed1eef70 r6:b8200000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2d00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:3e000000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f3 r8:07723000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f3 r8:07723000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace 8c76059b8bd5784b ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #6: 74371-bselinux-rack-04.log --]
[-- Type: text/plain, Size: 7574 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f2] revision 2 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM974371SV
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x000000003ec00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffefff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003fffefff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffefff]
[ 0.000000] kasan: Truncate memory block c0000000-fffff000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bcdffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bcdffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bcdffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bce00000
[ 0.000000] r7 : bcdfffff r6 : eeffffff r5 : eefff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : eefff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: eefff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 eefff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 00000018 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b7600000 ef474fa0 c0006dd8 c16e2060 b75f4000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2f00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2f00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 3ffff000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 00000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 3ffff000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f2 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 07819000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 07819000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 07819000 420f00f2 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07819000
[ 0.000000] 3fe0: 420f00f2 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:eefff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:eefff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b75f4000 r9:c16e2060 r8:c0006dd8 r7:ef474fa0 r6:b7600000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2f00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:3ffff000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f2 r8:07819000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f2 r8:07819000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #7: 7439-bselinux-rack-05.log --]
[-- Type: text/plain, Size: 7720 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g79c212fcfb1d (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #6 SMP Thu Oct 1 12:09:58 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM97449SSV_4GB
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000033fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000007dffffff]
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000bfffefff]
[ 0.000000] node 0: [mem 0x0000000300000000-0x000000033fffffff]
[ 0.000000] Zeroed struct page in unavailable ranges: 1 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000033fffffff]
[ 0.000000] kasan: Truncate memory block c0000000-3e000000
[ 0.000000] to c0000000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-f0000000 at shadow: b7000000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bc9ffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bc9ffe00] *pgd=80000000006003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g79c212fcfb1d #6
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] PC is at check_memory_region+0x54/0x1c8
[ 0.000000] LR is at 0x40
[ 0.000000] pc : [<c0455080>] lr : [<00000040>] psr: 600000d3
[ 0.000000] sp : c2803c18 ip : bc9ffe00 fp : c2803c44
[ 0.000000] r10: 00000000 r9 : 00001000 r8 : bca00000
[ 0.000000] r7 : bc9fffff r6 : ecffffff r5 : ecfff000 r4 : 00000000
[ 0.000000] r3 : c181d3fc r2 : 00000001 r1 : 00001000 r0 : ecfff000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 0.000000] Control: 30c5387d Table: 01877100 DAC: fffffffd
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2803c18 to 0xc2804000)
[ 0.000000] 3c00: c181d3fc 00001000
[ 0.000000] 3c20: ecfff000 00000000 00000000 c2806d48 00001000 00000000 c2803c64 c2803c48
[ 0.000000] 3c40: c0452e84 c0455038 b7500794 00000000 ecfff000 00000000 c2803d6c c2803c68
[ 0.000000] 3c60: c181d3fc c0452e68 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[ 0.000000] 3c80: 0000006a c2800010 c2b7ca60 c2b7ca60 c2806df0 600000d3 c2b7cc60 0000005a
[ 0.000000] 3ca0: 41b58ab3 c1681824 c181d2c4 c2803cb8 c02b4320 c02b239c c166b130 c2803dec
[ 0.000000] 3cc0: 3fffffff 00000000 c2803d24 00000001 0000001a 00000000 c166b1a4 c2690420
[ 0.000000] 3ce0: 00000000 c166b130 c2803dec 00000000 00000000 c166b1d8 c2803d1c c2803d08
[ 0.000000] 3d00: 00000001 00000000 c166b130 c2803dec c2803d4c c2803d20 c02b5a3c c02b43d8
[ 0.000000] 3d20: c02b43fc c02b4144 c166b1a4 b75007ac c2806d48 c28a29e0 c2ba0ac0 00000000
[ 0.000000] 3d40: c2803de4 00000001 00000000 b7800000 ed1f3f98 c0006de0 c16e2060 b77f3000
[ 0.000000] 3d60: c2803d9c c2803d70 c180b930 c181d2d0 3fffffff 00000000 00000001 00000000
[ 0.000000] 3d80: ffffffff c166bb78 2d00071f c2b784d8 c2803df4 c2803da0 c180babc c180b8b8
[ 0.000000] 3da0: 2d00071f 00c00000 c2803dd4 bd000000 c28a2780 00002b76 c280a484 c0003010
[ 0.000000] 3dc0: 00000000 bd000000 c2803e14 bd000000 b7000000 c28a29e0 c2ba0ac0 7e000000
[ 0.000000] 3de0: 00000000 c166b1d8 c2803e14 c2803df8 c180bbf8 c180b944 bd000000 c2803e18
[ 0.000000] 3e00: c0000000 00000000 c2803e6c c2803e18 c180beb0 c180bbac f0000000 00000000
[ 0.000000] 3e20: 80000000 c166b1a4 c16e2060 c166b17c c16e2000 c18750d8 7e000000 00000000
[ 0.000000] 3e40: c2803e6c c28a2780 c2fdcfa0 c1873a40 c0008000 e12fff1e c0226668 c18613a0
[ 0.000000] 3e60: c2803fa4 c2803e70 c1805684 c180bc78 0000006c 30c5387d 00000003 00000001
[ 0.000000] 3e80: 00000001 00000000 c16e2060 c2690420 185007d8 00000001 c2803f9c 00000000
[ 0.000000] 3ea0: 420f00f3 c2806d40 c2803ecc c2803eb8 c2803fbc c2803f60 c1200980 c2803f9c
[ 0.000000] 3ec0: 41b58ab3 c16696b0 c1804e3c c02b43d8 c02b4fd0 c02b59b0 00000000 b75007e4
[ 0.000000] 3ee0: c2806d48 30c0387d ffffffff 07822000 c2803f94 c2803f00 c02b4fd0 c02b59b0
[ 0.000000] 3f00: c2803f74 00000000 c2803f34 c2803f18 c2803f34 c2803f20 c0298af8 c0454b8c
[ 0.000000] 3f20: 41b58ab3 c166bb78 c02b4f40 c2803f38 c0320aac c0454b8c 00000000 c2865538
[ 0.000000] 3f40: c2803f9c c28653e0 c1877270 c28655ac c28653f0 07822000 c2b9b5c0 00000005
[ 0.000000] 3f60: 00000000 ffffffff c2803f84 c2803f78 c0454bec 00000000 c2803fa4 00007000
[ 0.000000] 3f80: c2806d48 30c0387d ffffffff 07822000 420f00f3 c2806d40 c2803ff4 c2803fa8
[ 0.000000] 3fa0: c1801010 c1804e48 c280a484 c0003010 00000001 bf000000 00000000 c1873a40
[ 0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07822000
[ 0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800f94 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c045502c>] (check_memory_region) from [<c0452e84>] (memset+0x28/0x44)
[ 0.000000] r10:00000000 r9:00001000 r8:c2806d48 r7:00000000 r6:00000000 r5:ecfff000
[ 0.000000] r4:00001000 r3:c181d3fc
[ 0.000000] [<c0452e5c>] (memset) from [<c181d3fc>] (memblock_alloc_try_nid+0x138/0x170)
[ 0.000000] r7:00000000 r6:ecfff000 r5:00000000 r4:b7500794
[ 0.000000] [<c181d2c4>] (memblock_alloc_try_nid) from [<c180b930>] (kasan_alloc_block.constprop.1+0x84/0x8c)
[ 0.000000] r10:b77f3000 r9:c16e2060 r8:c0006de0 r7:ed1f3f98 r6:b7800000 r5:00000000
[ 0.000000] r4:00000001
[ 0.000000] [<c180b8ac>] (kasan_alloc_block.constprop.1) from [<c180babc>] (kasan_pgd_populate+0x184/0x268)
[ 0.000000] r5:c2b784d8 r4:2d00071f
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbf8>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b1d8 r9:00000000 r8:7e000000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:bd000000
[ 0.000000] [<c180bba0>] (create_mapping) from [<c180beb0>] (kasan_init+0x244/0x394)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc6c>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c18613a0 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:420f00f3 r8:07822000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:420f00f3 r8:07822000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0)
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[ 0.000000] ---[ end trace 53c87bc3ccbdcda0 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #8: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
@ 2020-10-01 20:34 ` Linus Walleij
2020-10-01 20:38 ` Florian Fainelli
2020-10-01 21:18 ` Linus Walleij
2020-10-03 15:50 ` Ard Biesheuvel
2 siblings, 1 reply; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 20:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Russell King, Mike Rapoport,
Andrey Ryabinin, Ard Biesheuvel, Linux ARM
On Thu, Oct 1, 2020 at 9:19 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> The physical memory map looks like this:
>
> 0..3GB -> DRAM
> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> 4GB..12GB -> DRAM extension
>
> Do any of the platforms you use for testing have a similar memory map?
> Could you try to contrive a QEMU machine to have something similar in
Nothing with the DRAM extension, no. I do test on a bunch of
platforms that have the RAM at starting at 0x0.
> case that helps reproducing these failures?
Are these Broadcom chips hard to get for me? If it is a reference
design I can certainly afford to just buy one. If there is a hackable
product I can buy and pry apart and play with just point me at it
and I'll get it.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 20:34 ` Linus Walleij
@ 2020-10-01 20:38 ` Florian Fainelli
0 siblings, 0 replies; 36+ messages in thread
From: Florian Fainelli @ 2020-10-01 20:38 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Abbott Liu, Russell King, Mike Rapoport,
Andrey Ryabinin, Ard Biesheuvel, Linux ARM
On 10/1/2020 1:34 PM, Linus Walleij wrote:
> On Thu, Oct 1, 2020 at 9:19 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> The physical memory map looks like this:
>>
>> 0..3GB -> DRAM
>> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
>> 4GB..12GB -> DRAM extension
>>
>> Do any of the platforms you use for testing have a similar memory map?
>> Could you try to contrive a QEMU machine to have something similar in
>
> Nothing with the DRAM extension, no. I do test on a bunch of
> platforms that have the RAM at starting at 0x0.
>
>> case that helps reproducing these failures?
>
> Are these Broadcom chips hard to get for me?
Yes they are hard for you to get.
> If it is a reference
> design I can certainly afford to just buy one. If there is a hackable
> product I can buy and pry apart and play with just point me at it
> and I'll get it.
Testing anything or asking me to sprinkle debug would probably be
easier. Have you got your hands on a Raspberry Pi 4? That one would be
quite similar to one of our Broadcom STB chips (7211) and I would be
curious to know if it even works there.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
2020-10-01 20:34 ` Linus Walleij
@ 2020-10-01 21:18 ` Linus Walleij
2020-10-01 21:29 ` Arnd Bergmann
2020-10-01 21:35 ` Florian Fainelli
2020-10-03 15:50 ` Ard Biesheuvel
2 siblings, 2 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-01 21:18 UTC (permalink / raw)
To: Florian Fainelli, Arnd Bergmann
Cc: Abbott Liu, Russell King, Mike Rapoport, Andrey Ryabinin,
Ard Biesheuvel, Linux ARM
On Thu, Oct 1, 2020 at 9:19 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> The physical memory map looks like this:
>
> 0..3GB -> DRAM
> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> 4GB..12GB -> DRAM extension
So plenty of highmem, and then with LPAE you have
theoretically 12 GB of RAM. In an ARM32 system?
I think Arnd is gonna love this system for our highmem
experiments if that is something that is going to happen
often... Is that DRAM extension often mounted and
used?
> > Are these Broadcom chips hard to get for me?
>
> Yes they are hard for you to get.
Isn't one of them this beast:
https://www.ebay.com/c/502488121
Or do you mean that this device is locked down like
a fortress and not really hackable? There seems to
be a UART on the back and all.
> Have you got your hands on a Raspberry Pi 4? That one would be
> quite similar to one of our Broadcom STB chips (7211) and I would be
> curious to know if it even works there.
Pi 3 and 4 are 64bit Cortex A53 and A72 CPUs IIUC, so they
are in arch/arm64 and does not have this problem.
Your systems are curiously interesting, there is copious
highmem etc.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 21:18 ` Linus Walleij
@ 2020-10-01 21:29 ` Arnd Bergmann
2020-10-01 21:35 ` Florian Fainelli
1 sibling, 0 replies; 36+ messages in thread
From: Arnd Bergmann @ 2020-10-01 21:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, Abbott Liu, Russell King, Mike Rapoport,
Andrey Ryabinin, Ard Biesheuvel, Linux ARM
On Thu, Oct 1, 2020 at 11:18 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Oct 1, 2020 at 9:19 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> > Have you got your hands on a Raspberry Pi 4? That one would be
> > quite similar to one of our Broadcom STB chips (7211) and I would be
> > curious to know if it even works there.
>
> Pi 3 and 4 are 64bit Cortex A53 and A72 CPUs IIUC, so they
> are in arch/arm64 and does not have this problem.
They should be good enough for testing though -- Raspberry Pi 4
can run both 32-bit or 64-bit kernels.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 21:18 ` Linus Walleij
2020-10-01 21:29 ` Arnd Bergmann
@ 2020-10-01 21:35 ` Florian Fainelli
1 sibling, 0 replies; 36+ messages in thread
From: Florian Fainelli @ 2020-10-01 21:35 UTC (permalink / raw)
To: Linus Walleij, Arnd Bergmann
Cc: Abbott Liu, Russell King, Mike Rapoport, Andrey Ryabinin,
Ard Biesheuvel, Linux ARM
On 10/1/2020 2:18 PM, Linus Walleij wrote:
> On Thu, Oct 1, 2020 at 9:19 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> The physical memory map looks like this:
>>
>> 0..3GB -> DRAM
>> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
>> 4GB..12GB -> DRAM extension
>
> So plenty of highmem, and then with LPAE you have
> theoretically 12 GB of RAM. In an ARM32 system?
>
> I think Arnd is gonna love this system for our highmem
> experiments if that is something that is going to happen
> often... Is that DRAM extension often mounted and
> used?
>
>>> Are these Broadcom chips hard to get for me?
>>
>> Yes they are hard for you to get.
>
> Isn't one of them this beast:
> https://www.ebay.com/c/502488121
What the heck... someone must have been dumpster diving or been given a
gift :) This one is a BCM97425 which is MIPS-based.
>
> Or do you mean that this device is locked down like
> a fortress and not really hackable? There seems to
> be a UART on the back and all.
The devices are locked down and we don't send devices unless you are a
customer. Since our business unit never signed up for Linaro we do not
have an exchange program and every attempt in the past to send devices
has been met with rejection. I did manage to get Kevin Hilman a couple
of devices that we could consider using.
>
>> Have you got your hands on a Raspberry Pi 4? That one would be
>> quite similar to one of our Broadcom STB chips (7211) and I would be
>> curious to know if it even works there.
>
> Pi 3 and 4 are 64bit Cortex A53 and A72 CPUs IIUC, so they
> are in arch/arm64 and does not have this problem.
>
> Your systems are curiously interesting, there is copious
> highmem etc.
Yes, yes they are curious beasts :)
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
2020-10-01 20:34 ` Linus Walleij
2020-10-01 21:18 ` Linus Walleij
@ 2020-10-03 15:50 ` Ard Biesheuvel
2020-10-04 8:06 ` Ard Biesheuvel
2 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-03 15:50 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Linus Walleij, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 10/1/2020 8:22 AM, Linus Walleij wrote:
> > This is the 14th iteration of KASan for ARM/Aarch32.
> >
> > I have added one patch in the beginning of the series to
> > fix the issue when the DTB (often attached DTB) ends up
> > in lowmem. It also amends ARM to copy the device tree
> > instead of just unflattening it and using it from where
> > it is.
> >
> > This fixes my particular issue on the Qualcomm APQ8060
> > and I hope it may also solve Florian's issue and what
> > Ard has been seeing. If you inspect patch 1/6 you can
> > see what has been going on for me. My hypothesis about
> > what was going on was mostly right.
> >
> > You are encouraged to test this patch set to find memory out
> > of bounds bugs with ARM32 platforms and drivers.
> >
> > There is a git branch you can pull in:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
>
> It does appear to be slight better, although all platforms that I have
> where memory starts at physical address 0 cannot boot, attached logs
> which are all more or less the same.
>
> The physical memory map looks like this:
>
> 0..3GB -> DRAM
> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> 4GB..12GB -> DRAM extension
>
> Do any of the platforms you use for testing have a similar memory map?
> Could you try to contrive a QEMU machine to have something similar in
> case that helps reproducing these failures?
>
I am getting very similar failures on a Raspberry Pi4 booting in
32-bit mode from U-boot+EFI
Full log attached.
I will try to dig a bit deeper.
[-- Attachment #2: screen-exchange --]
[-- Type: application/octet-stream, Size: 13476 bytes --]
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200
Loading recovery.elf hnd: 0x00000000
Failed to read recovery.elf error: 6
Loading start4.elf hnd: 0x00000206
Loading fixup4.dat hnd: 0x00000202
MEM GPU: 76 ARM: 948 TOTAL: 1024
FIXUP src: 128 256 dst: 948 1024
Starting start4.elf @ 0xfec00200
INFO: BL33 will boot in Non-secure AArch32 Hypervisor mode
NOTICE: BL31: v2.3(debug):v2.3-140-g967a6d162d9d
NOTICE: BL31: Built : 17:26:28, Jun 11 2020
INFO: Changed device tree to advertise PSCI.
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a72: CPU workaround for 859971 was applied
INFO: BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied
INFO: BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x20000
INFO: SPSR = 0x1da
U-Boot 2020.07-rc4-00027-g7f3689f236cd (Jun 11 2020 - 18:07:34 +0200)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
Hit any key to stop autoboot: 0
U-Boot> setenv bootargs earlycon efi=debug
U-Boot> boot
ERROR: reserving fdt memory region failed (addr=0 size=80000)
15188480 bytes read in 838 ms (17.3 MiB/s)
Card did not respond to voltage select!
Scanning disk mmcnr@7e300000.blk...
Disk mmcnr@7e300000.blk not ready
Scanning disk emmc2@7e340000.blk...
Found 2 disks
EFI stub: Entering in HYP mode with MMU enabled
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7+ (ard@gambale) (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #186 SMP PREEMPT Sat Oct 3 17:41:42 CEST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=70c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[ 0.000000] earlycon: pl11 at MMIO 0x00000000fe201000 (options '')
[ 0.000000] printk: bootconsole [pl11] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: Getting UEFI parameters from /chosen in DT:
[ 0.000000] efi: System Table : 0x3b36c890
[ 0.000000] efi: MemMap Address : 0x00000000390c3040
[ 0.000000] efi: MemMap Size : 0x000003c0
[ 0.000000] efi: MemMap Desc. Size : 0x00000028
[ 0.000000] efi: MemMap Desc. Version : 0x00000001
[ 0.000000] efi: EFI v2.80 by Das U-Boot
[ 0.000000] efi: RTPROP=0x39f52040 SMBIOS=0x39f4c000 MEMRESERVE=0x390c6040
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x000000000000-0x000000000fff [Reserved | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000000001000-0x000000202fff [Conventional Memory| | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000000203000-0x000002202fff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000002203000-0x000007cfffff [Conventional Memory| | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000007d00000-0x000007efffff [Loader Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000007f00000-0x000007f0efff [ACPI Reclaim Memory| | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000007f0f000-0x0000390c2fff [Conventional Memory| | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000390c3000-0x0000390c8fff [Loader Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000390c9000-0x000039f46fff [Loader Code | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f47000-0x000039f4afff [Reserved | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f4b000-0x000039f4bfff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f4c000-0x000039f4cfff [Runtime Data |RUN| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f4d000-0x000039f4efff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f4f000-0x000039f4ffff [Reserved | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f50000-0x000039f51fff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f52000-0x000039f53fff [Runtime Data |RUN| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f54000-0x000039f54fff [Reserved | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f55000-0x000039f56fff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f57000-0x000039f5afff [Reserved | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000039f5b000-0x00003b36bfff [Loader Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x00003b36c000-0x00003b36cfff [Runtime Code |RUN| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x00003b36d000-0x00003b3fffff [Loader Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x000040000000-0x0000fbffffff [Boot Data | | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000fe100000-0x0000fe100fff [Memory Mapped I/O |RUN| | | | | | | | | | | | ]
[ 0.000000] efi: CPSR at EFI stub entry : 0x600001da
[ 0.000000] efi: SCTLR at EFI stub entry : 0x30c51835
[ 0.000000] efi: CPSR after ExitBootServices() : 0x600001da
[ 0.000000] efi: SCTLR after ExitBootServices(): 0x30c51835
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000002c000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xc7c00000
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xc7e00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000080000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x00000000fbffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000080000-0x00000000001fffff]
[ 0.000000] node 0: [mem 0x0000000000200000-0x0000000039f46fff]
[ 0.000000] node 0: [mem 0x0000000039f47000-0x0000000039f4afff]
[ 0.000000] node 0: [mem 0x0000000039f4b000-0x0000000039f4bfff]
[ 0.000000] node 0: [mem 0x0000000039f4c000-0x0000000039f4cfff]
[ 0.000000] node 0: [mem 0x0000000039f4d000-0x0000000039f4efff]
[ 0.000000] node 0: [mem 0x0000000039f4f000-0x0000000039f4ffff]
[ 0.000000] node 0: [mem 0x0000000039f50000-0x0000000039f51fff]
[ 0.000000] node 0: [mem 0x0000000039f52000-0x0000000039f54fff]
[ 0.000000] node 0: [mem 0x0000000039f55000-0x0000000039f56fff]
[ 0.000000] node 0: [mem 0x0000000039f57000-0x0000000039f5afff]
[ 0.000000] node 0: [mem 0x0000000039f5b000-0x000000003b36bfff]
[ 0.000000] node 0: [mem 0x000000003b36c000-0x000000003b36cfff]
[ 0.000000] node 0: [mem 0x000000003b36d000-0x000000003b3fffff]
[ 0.000000] node 0: [mem 0x0000000040000000-0x00000000fbffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000080000-0x00000000fbffffff]
[ 0.000000] kasan: Mapping kernel virtual memory block: c0080000-c0200000 at shadow: b7010000-b7040000
[ 0.000000] kasan: Truncate memory block c0200000-f9f47000
[ 0.000000] to c0200000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0200000-f0000000 at shadow: b7040000-bd000000
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address bc1ffe00
[ 0.000000] pgd = (ptrval)
[ 0.000000] [bc1ffe00] *pgd=80000000206003, *pmd=00000000
[ 0.000000] Internal error: Oops: 206 [#1] PREEMPT SMP THUMB2
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7+ #186
[ 0.000000] Hardware name: BCM2711
[ 0.000000] PC is at check_memory_region+0x3e/0x12c
[ 0.000000] LR is at 0xbc1fffff
[ 0.000000] pc : [<c05c57ce>] lr : [<bc1fffff>] psr: 000000f3
[ 0.000000] sp : c2403be8 ip : e8ffffff fp : 00000000
[ 0.000000] r10: ffffffff r9 : ffffffff r8 : bc200000
[ 0.000000] r7 : 00001000 r6 : 00000000 r5 : 00000040 r4 : bc1ffe00
[ 0.000000] r3 : c22244d3 r2 : 00000001 r1 : 00001000 r0 : e8fff000
[ 0.000000] Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA Thumb Segment user
[ 0.000000] Control: 70c5383d Table: 022d5140 DAC: ffffffff
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc2403be8 to 0xc2404000)
[ 0.000000] 3be0: 00001000 e8fff000 00000000 00001000 e8fff000 ffffffff
[ 0.000000] 3c00: ffffffff c05c41eb b7480788 00000000 c2400000 c22244d3 40000000 ffffffff
[ 0.000000] 3c20: 00000001 00000000 ffffffff 00000000 80000000 00000050 00000000 c121f723
[ 0.000000] 3c40: 41b58ab3 c1f94398 c22243f0 00000000 00000050 c04a6225 00000400 00000006
[ 0.000000] 3c60: 40000000 ffffffff 00000000 00000000 c2cb4a28 600000d3 c247d8a0 ffffc000
[ 0.000000] 3c80: 00000000 c2406cf8 c2400000 c2cb1560 c2406d70 c2400000 0000005a 00000002
[ 0.000000] 3ca0: 00000001 00000000 00000001 c04a753b c1f76e94 c2403d8c 00000050 00000000
[ 0.000000] 3cc0: 00000001 b74807a0 c2400000 c04a7c40 c1f76f08 c24c71a0 39f47000 00000000
[ 0.000000] 3ce0: c1f76f3c c04a75eb c1f76e94 00000000 39f47000 00000001 00000000 40000000
[ 0.000000] 3d00: ffffffff e9083418 c2416cf8 c0206de8 c2074084 c2209eed 40000000 ffffffff
[ 0.000000] 3d20: 00000001 00000000 ffffffff 00000000 00000000 b7883000 2900071f b7a00000
[ 0.000000] 3d40: c2ca5a38 c220a02b 2900071f 00c00000 c1f76f3c bd000000 00000000 c24c6f40
[ 0.000000] 3d60: c2ca1000 c0203010 00002ca3 bd000000 bd100000 bd000000 b7040000 c0200000
[ 0.000000] 3d80: c1f76f08 c24c71a0 39f47000 00000000 c1f76f3c c220a101 bd000000 c220a2ed
[ 0.000000] 3da0: c1f76f08 c2ce2858 c22d30d8 c220a311 f0000000 ffff1000 39f47000 00000000
[ 0.000000] 3dc0: c2074000 c2074084 c2403f80 c22c38e0 c0208000 c314453f c22d1a40 c24c6f40
[ 0.000000] 3de0: c2074000 c041f6fc c2403f80 c2203d1f 0000006c 70c5383d 00000000 00000000
[ 0.000000] 3e00: 00000000 00000000 00000000 c04e7495 c2490c08 c04e778d 00000000 00000000
[ 0.000000] 3e20: 00000000 00000000 00000002 c2cb4b12 00000000 00000002 c2410660 c2403fcc
[ 0.000000] 3e40: 00000001 184807cc c247da60 c247da68 c2cb4a20 00000002 00000000 c121f723
[ 0.000000] 3e60: 41b58ab3 c1f74b60 c22036e4 00000000 00000002 c04a6225 00000400 00000005
[ 0.000000] 3e80: 00000002 00000000 00000000 00000000 c2cb4a28 600001d3 c247d8a0 ffffc000
[ 0.000000] 3ea0: 00000000 c2406cf8 c2400000 c2cb1560 c2406d70 c2400000 000000ae 00000002
[ 0.000000] 3ec0: ffffc000 600001d3 00000001 c04a753b c1400980 c2403fac 00000002 00000000
[ 0.000000] 3ee0: 00000000 b74807e4 c2400000 c04a7c40 c2406cc0 ffffffff 00000001 70c5387d
[ 0.000000] 3f00: 00000000 c04a75eb c1400980 c2403fac 00000001 c04a7ca7 00000000 00000000
[ 0.000000] 3f20: 41b58ab3 c1f82ac4 c04a7c40 00000000 00000000 00000000 00000000 00000000
[ 0.000000] 3f40: c2403fac 00000000 00000000 00000000 00000000 00000000 00000000 c049370b
[ 0.000000] 3f60: 00000000 c24953f0 c146b1a0 c04fa117 c24953e0 c22d6274 c24955ac c24953f0
[ 0.000000] 3f80: ffffffff 00000001 70c5387d 00000000 c22d6274 c2ca4000 c2ca4000 c2406cc0
[ 0.000000] 3fa0: c2406cc0 ffffffff 00000001 70c5387d 00000000 c2200aeb 00000001 c24c6f40
[ 0.000000] 3fc0: c2ca1000 c0203010 00002ca3 c22d1a40 00000000 00000000 00000000 c220032c
[ 0.000000] 3fe0: 00000000 30c0387d ffffffff 07d00000 410fd083 00000000 00000000 00000000
[ 0.000000] [<c05c57ce>] (check_memory_region) from [<c05c41eb>] (memset+0x13/0x24)
[ 0.000000] [<c05c41eb>] (memset) from [<c22244d3>] (memblock_alloc_try_nid+0xe3/0x108)
[ 0.000000] [<c22244d3>] (memblock_alloc_try_nid) from [<c2209eed>] (kasan_alloc_block.constprop.1+0x65/0x68)
[ 0.000000] [<c2209eed>] (kasan_alloc_block.constprop.1) from [<c220a02b>] (kasan_pgd_populate+0x13b/0x1dc)
[ 0.000000] [<c220a02b>] (kasan_pgd_populate) from [<c220a101>] (create_mapping+0x35/0x3a)
[ 0.000000] [<c220a101>] (create_mapping) from [<c220a311>] (kasan_init+0x1d3/0x2fa)
[ 0.000000] [<c220a311>] (kasan_init) from [<c2203d1f>] (setup_arch+0x63b/0xe58)
[ 0.000000] [<c2203d1f>] (setup_arch) from [<c2200aeb>] (start_kernel+0x69/0x2fe)
[ 0.000000] [<c2200aeb>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] Code: f014 0607 d131 10ed (e9d4) 6700
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x1f/0x40 with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-03 15:50 ` Ard Biesheuvel
@ 2020-10-04 8:06 ` Ard Biesheuvel
2020-10-04 8:41 ` Ard Biesheuvel
0 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-04 8:06 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Linus Walleij, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Sat, 3 Oct 2020 at 17:50, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 10/1/2020 8:22 AM, Linus Walleij wrote:
> > > This is the 14th iteration of KASan for ARM/Aarch32.
> > >
> > > I have added one patch in the beginning of the series to
> > > fix the issue when the DTB (often attached DTB) ends up
> > > in lowmem. It also amends ARM to copy the device tree
> > > instead of just unflattening it and using it from where
> > > it is.
> > >
> > > This fixes my particular issue on the Qualcomm APQ8060
> > > and I hope it may also solve Florian's issue and what
> > > Ard has been seeing. If you inspect patch 1/6 you can
> > > see what has been going on for me. My hypothesis about
> > > what was going on was mostly right.
> > >
> > > You are encouraged to test this patch set to find memory out
> > > of bounds bugs with ARM32 platforms and drivers.
> > >
> > > There is a git branch you can pull in:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> >
> > It does appear to be slight better, although all platforms that I have
> > where memory starts at physical address 0 cannot boot, attached logs
> > which are all more or less the same.
> >
> > The physical memory map looks like this:
> >
> > 0..3GB -> DRAM
> > 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> > 4GB..12GB -> DRAM extension
> >
> > Do any of the platforms you use for testing have a similar memory map?
> > Could you try to contrive a QEMU machine to have something similar in
> > case that helps reproducing these failures?
> >
>
> I am getting very similar failures on a Raspberry Pi4 booting in
> 32-bit mode from U-boot+EFI
>
> Full log attached.
>
> I will try to dig a bit deeper.
OK, one obvious issue with the code as-is is that the following routine
static __init void *kasan_alloc_block(size_t size)
{
return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
}
is called after the early shadow is unmapped, but before the permanent
shadow is in place. memblock_alloc_try_nid() clears the newly
allocated memory using memset(), which checks the associated shadow,
which is unmapped -> BOOM.
With the following implementation, I can avoid the crash similar to
the one Florian is reporting:
static __init void *kasan_alloc_block(size_t size)
{
void *p = memblock_alloc_try_nid_raw(size, size,
__pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_KASAN,
NUMA_NO_NODE);
if (p)
__memset(p, 0, size);
return p;
}
However, I still get a hang a bit later, and I haven't tracked that down yet.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-04 8:06 ` Ard Biesheuvel
@ 2020-10-04 8:41 ` Ard Biesheuvel
2020-10-04 9:09 ` Ard Biesheuvel
0 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-04 8:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Linus Walleij, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Sun, 4 Oct 2020 at 10:06, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sat, 3 Oct 2020 at 17:50, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > >
> > >
> > >
> > > On 10/1/2020 8:22 AM, Linus Walleij wrote:
> > > > This is the 14th iteration of KASan for ARM/Aarch32.
> > > >
> > > > I have added one patch in the beginning of the series to
> > > > fix the issue when the DTB (often attached DTB) ends up
> > > > in lowmem. It also amends ARM to copy the device tree
> > > > instead of just unflattening it and using it from where
> > > > it is.
> > > >
> > > > This fixes my particular issue on the Qualcomm APQ8060
> > > > and I hope it may also solve Florian's issue and what
> > > > Ard has been seeing. If you inspect patch 1/6 you can
> > > > see what has been going on for me. My hypothesis about
> > > > what was going on was mostly right.
> > > >
> > > > You are encouraged to test this patch set to find memory out
> > > > of bounds bugs with ARM32 platforms and drivers.
> > > >
> > > > There is a git branch you can pull in:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > >
> > > It does appear to be slight better, although all platforms that I have
> > > where memory starts at physical address 0 cannot boot, attached logs
> > > which are all more or less the same.
> > >
> > > The physical memory map looks like this:
> > >
> > > 0..3GB -> DRAM
> > > 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> > > 4GB..12GB -> DRAM extension
> > >
> > > Do any of the platforms you use for testing have a similar memory map?
> > > Could you try to contrive a QEMU machine to have something similar in
> > > case that helps reproducing these failures?
> > >
> >
> > I am getting very similar failures on a Raspberry Pi4 booting in
> > 32-bit mode from U-boot+EFI
> >
> > Full log attached.
> >
> > I will try to dig a bit deeper.
>
> OK, one obvious issue with the code as-is is that the following routine
>
> static __init void *kasan_alloc_block(size_t size)
> {
> return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
> MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
> }
>
> is called after the early shadow is unmapped, but before the permanent
> shadow is in place. memblock_alloc_try_nid() clears the newly
> allocated memory using memset(), which checks the associated shadow,
> which is unmapped -> BOOM.
>
> With the following implementation, I can avoid the crash similar to
> the one Florian is reporting:
>
> static __init void *kasan_alloc_block(size_t size)
> {
> void *p = memblock_alloc_try_nid_raw(size, size,
> __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_KASAN,
> NUMA_NO_NODE);
>
> if (p)
> __memset(p, 0, size);
> return p;
> }
>
> However, I still get a hang a bit later, and I haven't tracked that down yet.
The above issue appears to be related to TLB maintenance. So keeping
kasan_alloc_block() as is, and doing
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -223,6 +223,8 @@ void __init kasan_init(void)
__pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
#endif
cpu_switch_mm(tmp_pgd_table, &init_mm);
+ local_flush_tlb_all();
+
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
instead fixes the crash as well.
Still have the hang right after though ..
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-04 8:41 ` Ard Biesheuvel
@ 2020-10-04 9:09 ` Ard Biesheuvel
2020-10-04 20:24 ` Florian Fainelli
2020-10-05 8:40 ` Linus Walleij
0 siblings, 2 replies; 36+ messages in thread
From: Ard Biesheuvel @ 2020-10-04 9:09 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Abbott Liu, Linus Walleij, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
[-- Attachment #1: Type: text/plain, Size: 6078 bytes --]
On Sun, 4 Oct 2020 at 10:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sun, 4 Oct 2020 at 10:06, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Sat, 3 Oct 2020 at 17:50, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > On 10/1/2020 8:22 AM, Linus Walleij wrote:
> > > > > This is the 14th iteration of KASan for ARM/Aarch32.
> > > > >
> > > > > I have added one patch in the beginning of the series to
> > > > > fix the issue when the DTB (often attached DTB) ends up
> > > > > in lowmem. It also amends ARM to copy the device tree
> > > > > instead of just unflattening it and using it from where
> > > > > it is.
> > > > >
> > > > > This fixes my particular issue on the Qualcomm APQ8060
> > > > > and I hope it may also solve Florian's issue and what
> > > > > Ard has been seeing. If you inspect patch 1/6 you can
> > > > > see what has been going on for me. My hypothesis about
> > > > > what was going on was mostly right.
> > > > >
> > > > > You are encouraged to test this patch set to find memory out
> > > > > of bounds bugs with ARM32 platforms and drivers.
> > > > >
> > > > > There is a git branch you can pull in:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > >
> > > > It does appear to be slight better, although all platforms that I have
> > > > where memory starts at physical address 0 cannot boot, attached logs
> > > > which are all more or less the same.
> > > >
> > > > The physical memory map looks like this:
> > > >
> > > > 0..3GB -> DRAM
> > > > 3GB..4GB -> Registers, Boot ROM, Boot SRAM
> > > > 4GB..12GB -> DRAM extension
> > > >
> > > > Do any of the platforms you use for testing have a similar memory map?
> > > > Could you try to contrive a QEMU machine to have something similar in
> > > > case that helps reproducing these failures?
> > > >
> > >
> > > I am getting very similar failures on a Raspberry Pi4 booting in
> > > 32-bit mode from U-boot+EFI
> > >
> > > Full log attached.
> > >
> > > I will try to dig a bit deeper.
> >
> > OK, one obvious issue with the code as-is is that the following routine
> >
> > static __init void *kasan_alloc_block(size_t size)
> > {
> > return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
> > MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
> > }
> >
> > is called after the early shadow is unmapped, but before the permanent
> > shadow is in place. memblock_alloc_try_nid() clears the newly
> > allocated memory using memset(), which checks the associated shadow,
> > which is unmapped -> BOOM.
> >
> > With the following implementation, I can avoid the crash similar to
> > the one Florian is reporting:
> >
> > static __init void *kasan_alloc_block(size_t size)
> > {
> > void *p = memblock_alloc_try_nid_raw(size, size,
> > __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_KASAN,
> > NUMA_NO_NODE);
> >
> > if (p)
> > __memset(p, 0, size);
> > return p;
> > }
> >
> > However, I still get a hang a bit later, and I haven't tracked that down yet.
>
> The above issue appears to be related to TLB maintenance. So keeping
> kasan_alloc_block() as is, and doing
>
> --- a/arch/arm/mm/kasan_init.c
> +++ b/arch/arm/mm/kasan_init.c
> @@ -223,6 +223,8 @@ void __init kasan_init(void)
> __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
> #endif
> cpu_switch_mm(tmp_pgd_table, &init_mm);
> + local_flush_tlb_all();
> +
> clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>
> kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
>
> instead fixes the crash as well.
>
> Still have the hang right after though ..
OK, booting now - turns out the switch back to swapper_pg_dir needs a
proper TLB flush as well.
Full patch below - with that applied, I can boot the RPi4 to the point
where it wants to mount the rootfs (but I don't have a 32-bit rootfs
at hand)
The first change avoids reallocating KASAN blocks when a range gets
mapped twice - this occurs when mapping the DTB space explicitly
(although I am not sure that that is still needed now that you move
the DTB)
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 6fd9bc70970f..6877212a370d 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -45,11 +45,15 @@
do {
pte_t entry;
+ void *p;
next = addr + PAGE_SIZE;
if (!early) {
- void *p = kasan_alloc_block(PAGE_SIZE);
+ if (!pte_none(READ_ONCE(*ptep)))
+ continue;
+
+ p = kasan_alloc_block(PAGE_SIZE);
if (!p) {
panic("%s failed to alloc pte for
address 0x%lx\n",
__func__, addr);
@@ -223,11 +227,15 @@
__pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
#endif
cpu_switch_mm(tmp_pgd_table, &init_mm);
+ local_flush_tlb_all();
+
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
kasan_mem_to_shadow((void *)-1UL) + 1);
+ __memblock_dump_all();
+
for_each_memblock(memory, reg) {
void *start = __va(reg->base);
void *end = __va(reg->base + reg->size);
@@ -277,10 +285,11 @@
pfn_pte(virt_to_pfn(kasan_early_shadow_page),
__pgprot(pgprot_val(PAGE_KERNEL)
| L_PTE_RDONLY)));
+
+ cpu_switch_mm(swapper_pg_dir, &init_mm);
local_flush_tlb_all();
memset(kasan_early_shadow_page, 0, PAGE_SIZE);
- cpu_switch_mm(swapper_pg_dir, &init_mm);
pr_info("Kernel address sanitizer initialized\n");
init_task.kasan_depth = 0;
}
Full boot log attached.
[-- Attachment #2: screen-exchange --]
[-- Type: application/octet-stream, Size: 23457 bytes --]
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200
Loading recovery.elf hnd: 0x00000000
Failed to read recovery.elf error: 6
Loading start4.elf hnd: 0x00000206
Loading fixup4.dat hnd: 0x00000202
MEM GPU: 76 ARM: 948 TOTAL: 1024
FIXUP src: 128 256 dst: 948 1024
Starting start4.elf @ 0xfec00200
INFO: BL33 will boot in Non-secure AArch32 Hypervisor mode
NOTICE: BL31: v2.3(debug):v2.3-140-g967a6d162d9d
NOTICE: BL31: Built : 17:26:28, Jun 11 2020
INFO: Changed device tree to advertise PSCI.
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a72: CPU workaround for 859971 was applied
INFO: BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied
INFO: BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x20000
INFO: SPSR = 0x1da
U-Boot 2020.07-rc4-00027-g7f3689f236cd (Jun 11 2020 - 18:07:34 +0200)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
Hit any key to stop autoboot: 0
ERROR: reserving fdt memory region failed (addr=0 size=80000)
15188480 bytes read in 842 ms (17.2 MiB/s)
Card did not respond to voltage select!
Scanning disk mmcnr@7e300000.blk...
Disk mmcnr@7e300000.blk not ready
Scanning disk emmc2@7e340000.blk...
Found 2 disks
EFI stub: Entering in HYP mode with MMU enabled
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7+ (ard@gambale) (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #201 SMP PREEMPT Sun Oct 4 11:00:50 CEST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=70c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: EFI v2.80 by Das U-Boot
[ 0.000000] efi: RTPROP=0x39f52040 SMBIOS=0x39f4c000 MEMRESERVE=0x390c6040
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000002c000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xc7c00000
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xc7e00000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000080000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x00000000fbffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000080000-0x00000000001fffff]
[ 0.000000] node 0: [mem 0x0000000000200000-0x0000000039f46fff]
[ 0.000000] node 0: [mem 0x0000000039f47000-0x0000000039f4afff]
[ 0.000000] node 0: [mem 0x0000000039f4b000-0x0000000039f4bfff]
[ 0.000000] node 0: [mem 0x0000000039f4c000-0x0000000039f4cfff]
[ 0.000000] node 0: [mem 0x0000000039f4d000-0x0000000039f4efff]
[ 0.000000] node 0: [mem 0x0000000039f4f000-0x0000000039f4ffff]
[ 0.000000] node 0: [mem 0x0000000039f50000-0x0000000039f51fff]
[ 0.000000] node 0: [mem 0x0000000039f52000-0x0000000039f54fff]
[ 0.000000] node 0: [mem 0x0000000039f55000-0x0000000039f56fff]
[ 0.000000] node 0: [mem 0x0000000039f57000-0x0000000039f5afff]
[ 0.000000] node 0: [mem 0x0000000039f5b000-0x000000003b36bfff]
[ 0.000000] node 0: [mem 0x000000003b36c000-0x000000003b36cfff]
[ 0.000000] node 0: [mem 0x000000003b36d000-0x000000003b3fffff]
[ 0.000000] node 0: [mem 0x0000000040000000-0x00000000fbffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000080000-0x00000000fbffffff]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x00000000f7380000 reserved size = 0x00000000094ec04b
[ 0.000000] memory.cnt = 0xf
[ 0.000000] memory[0x0] [0x0000000000080000-0x00000000001fffff], 0x0000000000180000 bytes flags: 0x4
[ 0.000000] memory[0x1] [0x0000000000200000-0x0000000039f46fff], 0x0000000039d47000 bytes flags: 0x0
[ 0.000000] memory[0x2] [0x0000000039f47000-0x0000000039f4afff], 0x0000000000004000 bytes flags: 0x4
[ 0.000000] memory[0x3] [0x0000000039f4b000-0x0000000039f4bfff], 0x0000000000001000 bytes flags: 0x0
[ 0.000000] memory[0x4] [0x0000000039f4c000-0x0000000039f4cfff], 0x0000000000001000 bytes flags: 0x4
[ 0.000000] memory[0x5] [0x0000000039f4d000-0x0000000039f4efff], 0x0000000000002000 bytes flags: 0x0
[ 0.000000] memory[0x6] [0x0000000039f4f000-0x0000000039f4ffff], 0x0000000000001000 bytes flags: 0x4
[ 0.000000] memory[0x7] [0x0000000039f50000-0x0000000039f51fff], 0x0000000000002000 bytes flags: 0x0
[ 0.000000] memory[0x8] [0x0000000039f52000-0x0000000039f54fff], 0x0000000000003000 bytes flags: 0x4
[ 0.000000] memory[0x9] [0x0000000039f55000-0x0000000039f56fff], 0x0000000000002000 bytes flags: 0x0
[ 0.000000] memory[0xa] [0x0000000039f57000-0x0000000039f5afff], 0x0000000000004000 bytes flags: 0x4
[ 0.000000] memory[0xb] [0x0000000039f5b000-0x000000003b36bfff], 0x0000000001411000 bytes flags: 0x0
[ 0.000000] memory[0xc] [0x000000003b36c000-0x000000003b36cfff], 0x0000000000001000 bytes flags: 0x4
[ 0.000000] memory[0xd] [0x000000003b36d000-0x000000003b3fffff], 0x0000000000093000 bytes flags: 0x0
[ 0.000000] memory[0xe] [0x0000000040000000-0x00000000fbffffff], 0x00000000bc000000 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0xa
[ 0.000000] reserved[0x0] [0x0000000000203000-0x0000000000207fff], 0x0000000000005000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x0000000000400000-0x000000000314453f], 0x0000000002d44540 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x0000000007d00000-0x0000000007d0b99e], 0x000000000000b99f bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x0000000007f00000-0x0000000007f0efff], 0x000000000000f000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x0000000029878000-0x000000002bffefff], 0x0000000002787000 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x000000002bfffe40-0x000000002bffff0b], 0x00000000000000cc bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x000000002bffff40-0x000000002bffff6f], 0x0000000000000030 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x000000002bffffa0-0x000000002fffffff], 0x0000000004000060 bytes flags: 0x0
[ 0.000000] reserved[0x8] [0x00000000390c3000-0x00000000390c3fff], 0x0000000000001000 bytes flags: 0x0
[ 0.000000] reserved[0x9] [0x00000000390c6040-0x00000000390c604f], 0x0000000000000010 bytes flags: 0x0
[ 0.000000] kasan: Mapping kernel virtual memory block: c0080000-c0200000 at shadow: b7010000-b7040000
[ 0.000000] kasan: Truncate memory block c0200000-f9f47000
[ 0.000000] to c0200000-f0000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c0200000-f0000000 at shadow: b7040000-bd000000
[ 0.000000] kasan: Skip highmem block f9f47000-f9f4b000
[ 0.000000] kasan: Skip highmem block f9f4b000-f9f4c000
[ 0.000000] kasan: Skip highmem block f9f4c000-f9f4d000
[ 0.000000] kasan: Skip highmem block f9f4d000-f9f4f000
[ 0.000000] kasan: Skip highmem block f9f4f000-f9f50000
[ 0.000000] kasan: Skip highmem block f9f50000-f9f52000
[ 0.000000] kasan: Skip highmem block f9f52000-f9f55000
[ 0.000000] kasan: Skip highmem block f9f55000-f9f57000
[ 0.000000] kasan: Skip highmem block f9f57000-f9f5b000
[ 0.000000] kasan: Skip highmem block f9f5b000-fb36c000
[ 0.000000] kasan: Skip highmem block fb36c000-fb36d000
[ 0.000000] kasan: Skip highmem block fb36d000-fb400000
[ 0.000000] kasan: Skip highmem block 00000000-bc000000
[ 0.000000] kasan: Mapping kernel virtual memory block: bf800000-c0000000 at shadow: b6f00000-b7000000
[ 0.000000] kasan: Mapping kernel virtual memory block: c7c00000-c7e00000 at shadow: b7f80000-b7fc0000
[ 0.000000] kasan: Kernel address sanitizer initialized
[ 0.000000] DTB @07d00000 (physical) copied to @e374b640 (virtual)
[ 0.000000] Clear ATAGs/DTB PMD @0xc7c00000
[ 0.000000] Clear ATAGs/DTB PMD @0xc7e00000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.2
[ 0.000000] percpu: Embedded 20 pages/cpu s50060 r8192 d23668 u81920
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1010689
[ 0.000000] Kernel command line: rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] software IO TLB: mapped [mem 0x1f61b000-0x2361b000] (64MB)
[ 0.000000] Memory: 3730416K/4050432K available (16384K kernel code, 8829K rwdata, 13344K rodata, 2048K init, 4755K bss, 254480K reserved, 65536K cma-reserved, 3264448K highmem)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] random: get_random_bytes called from start_kernel+0x19d/0x2fe with crng_init=0
[ 0.000013] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[ 0.000083] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[ 0.000296] bcm2835: system timer (irq = 17)
[ 0.009824] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[ 0.009851] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[ 0.009879] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[ 0.009900] Switching to timer-based delay loop, resolution 18ns
[ 0.013241] Console: colour dummy device 80x30
[ 0.017363] printk: console [tty0] enabled
[ 0.017442] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)
[ 0.017514] pid_max: default: 32768 minimum: 301
[ 0.018442] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.018507] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.024460] CPU: Testing write buffer coherency: ok
[ 0.024692] CPU0: Spectre v2: using firmware workaround
[ 0.025381] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.027838] Setting up static identity map for 0x400000 - 0x400160
[ 0.031116] rcu: Hierarchical SRCU implementation.
[ 0.039325] Remapping and enabling EFI services.
[ 0.040439] smp: Bringing up secondary CPUs ...
[ 0.043207] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.043225] CPU1: Spectre v2: using firmware workaround
[ 0.046186] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.046203] CPU2: Spectre v2: using firmware workaround
[ 0.049125] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.049142] CPU3: Spectre v2: using firmware workaround
[ 0.049394] smp: Brought up 1 node, 4 CPUs
[ 0.049435] SMP: Total of 4 processors activated (432.00 BogoMIPS).
[ 0.049473] CPU: All CPU(s) started in HYP mode.
[ 0.049506] CPU: Virtualization extensions available.
[ 0.053859] devtmpfs: initialized
[ 0.272079] VFP support v0.3: implementor 41 architecture 3 part 40 variant 8 rev 0
[ 0.274711] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.274794] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.284793] pinctrl core: initialized pinctrl subsystem
[ 0.301167] SMBIOS 3.0 present.
[ 0.301240] DMI: raspberrypi rpi/rpi, BIOS 2020.07-rc4-00027-g7f3689f236cd 06/11/2020
[ 0.305060] NET: Registered protocol family 16
[ 0.312134] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.336434] thermal_sys: Registered thermal governor 'step_wise'
[ 0.338319] cpuidle: using governor menu
[ 0.339480] No ATAGs?
[ 0.339688] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.339743] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.360492] Serial: AMBA PL011 UART driver
[ 7.960729] AT91: Could not find identification node
[ 7.982086] iommu: Default domain type: Translated
[ 7.983696] vgaarb: loaded
[ 7.997570] SCSI subsystem initialized
[ 8.003072] usbcore: registered new interface driver usbfs
[ 8.003839] usbcore: registered new interface driver hub
[ 8.004362] usbcore: registered new device driver usb
[ 8.011460] pps_core: LinuxPPS API ver. 1 registered
[ 8.011504] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 8.011885] PTP clock support registered
[ 8.033370] clocksource: Switched to clocksource arch_sys_counter
[ 10.577266] NET: Registered protocol family 2
[ 10.582536] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 10.582705] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 10.583129] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 10.583518] TCP: Hash tables configured (established 8192 bind 8192)
[ 10.584217] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 10.584366] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 10.585623] NET: Registered protocol family 1
[ 10.590449] RPC: Registered named UNIX socket transport module.
[ 10.590495] RPC: Registered udp transport module.
[ 10.590531] RPC: Registered tcp transport module.
[ 10.590566] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 10.590613] PCI: CLS 0 bytes, default 64
[ 10.597885] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[ 10.611384] Initialise system trusted keyrings
[ 10.612156] workingset: timestamp_bits=30 max_order=20 bucket_order=0
[ 10.750772] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 10.763208] NFS: Registering the id_resolver key type
[ 10.763402] Key type id_resolver registered
[ 10.763440] Key type id_legacy registered
[ 10.765087] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 10.765382] ntfs: driver 2.1.32 [Flags: R/O].
[ 10.772851] Key type asymmetric registered
[ 10.772892] Asymmetric key parser 'x509' registered
[ 10.773149] bounce: pool size: 64 pages
[ 10.773895] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[ 10.773948] io scheduler mq-deadline registered
[ 10.773984] io scheduler kyber registered
[ 10.814117] ------------[ cut here ]------------
[ 10.814190] WARNING: CPU: 0 PID: 1 at kernel/irq/chip.c:996 irq_set_chained_handler_and_data+0x85/0xa8
[ 10.814243] Modules linked in:
[ 10.814287] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc7+ #201
[ 10.814329] Hardware name: raspberrypi rpi/rpi, BIOS 2020.07-rc4-00027-g7f3689f236cd 06/11/2020
[ 10.814404] [<c0412a25>] (unwind_backtrace) from [<c040c0b7>] (show_stack+0xb/0xc)
[ 10.814471] [<c040c0b7>] (show_stack) from [<c08af38d>] (dump_stack+0x8d/0xa0)
[ 10.814535] [<c08af38d>] (dump_stack) from [<c0447135>] (__warn+0xe5/0xf4)
[ 10.814591] [<c0447135>] (__warn) from [<c04474cb>] (warn_slowpath_fmt+0x7f/0xc8)
[ 10.814658] [<c04474cb>] (warn_slowpath_fmt) from [<c04af129>] (irq_set_chained_handler_and_data+0x85/0xa8)
[ 10.814734] [<c04af129>] (irq_set_chained_handler_and_data) from [<c0948ee9>] (gpiochip_add_data_with_key+0x9b5/0xf2c)
[ 10.814811] [<c0948ee9>] (gpiochip_add_data_with_key) from [<c091bb51>] (bcm2835_pinctrl_probe+0x4d1/0x620)
[ 10.814887] [<c091bb51>] (bcm2835_pinctrl_probe) from [<c0bd787f>] (platform_drv_probe+0x43/0x80)
[ 10.814951] [<c0bd787f>] (platform_drv_probe) from [<c0bd5281>] (really_probe+0x105/0x3e4)
[ 10.815013] [<c0bd5281>] (really_probe) from [<c0bd56a9>] (driver_probe_device+0x51/0x90)
[ 10.815074] [<c0bd56a9>] (driver_probe_device) from [<c0bd587b>] (device_driver_attach+0x5b/0x60)
[ 10.815137] [<c0bd587b>] (device_driver_attach) from [<c0bd58c3>] (__driver_attach+0x43/0x9c)
[ 10.815202] [<c0bd58c3>] (__driver_attach) from [<c0bd343f>] (bus_for_each_dev+0xab/0xdc)
[ 10.815269] [<c0bd343f>] (bus_for_each_dev) from [<c0bd463f>] (bus_add_driver+0x1a3/0x1c8)
[ 10.815334] [<c0bd463f>] (bus_add_driver) from [<c0bd64d9>] (driver_register+0x89/0x124)
[ 10.815397] [<c0bd64d9>] (driver_register) from [<c0402247>] (do_one_initcall+0x87/0x308)
[ 10.815465] [<c0402247>] (do_one_initcall) from [<c2200f61>] (kernel_init_freeable+0x1a1/0x1ec)
[ 10.815533] [<c2200f61>] (kernel_init_freeable) from [<c1216a9b>] (kernel_init+0x7/0xd0)
[ 10.815595] [<c1216a9b>] (kernel_init) from [<c0400249>] (ret_from_fork+0x11/0x28)
[ 10.815645] Exception stack(0xc02c7fb0 to 0xc02c7ff8)
[ 10.815689] 7fa0: 00000000 00000000 00000000 00000000
[ 10.815751] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 10.815809] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 10.815858] ---[ end trace e18024a7dcc03eb9 ]---
[ 11.469484] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 11.491993] bcm2835-aux-uart fe215040.serial: there is not valid maps for state default
[ 11.498593] fe215040.serial: ttyS1 at MMIO 0xfe215040 (irq = 31, base_baud = 62499999) is a 16550
[ 11.512391] SuperH (H)SCI(F) driver initialized
[ 11.516928] msm_serial: driver initialized
[ 11.517876] STMicroelectronics ASC driver initialized
[ 11.524198] STM32 USART driver initialized
[ 11.533317] iproc-rng200 fe104000.rng: hwrng registered
[ 11.661993] brd: module loaded
[ 11.767131] loop: module loaded
[ 11.779110] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 11.839111] libphy: Fixed MDIO Bus: probed
[ 11.859421] CAN device driver interface
[ 11.862792] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
[ 11.866372] e1000e: Intel(R) PRO/1000 Network Driver
[ 11.866411] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 11.867148] igb: Intel(R) Gigabit Ethernet Network Driver
[ 11.867187] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 11.881956] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[ 11.882474] usbcore: registered new interface driver pegasus
[ 11.883180] usbcore: registered new interface driver asix
[ 11.883688] usbcore: registered new interface driver ax88179_178a
[ 11.884128] usbcore: registered new interface driver cdc_ether
[ 11.884809] usbcore: registered new interface driver smsc75xx
[ 11.885505] usbcore: registered new interface driver smsc95xx
[ 11.885941] usbcore: registered new interface driver net1080
[ 11.886377] usbcore: registered new interface driver cdc_subset
[ 11.886811] usbcore: registered new interface driver zaurus
[ 11.887518] usbcore: registered new interface driver cdc_ncm
[ 11.900172] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 11.900221] ehci-pci: EHCI PCI platform driver
[ 11.900638] ehci-platform: EHCI generic platform driver
[ 11.901293] ehci-orion: EHCI orion driver
[ 11.901867] SPEAr-ehci: EHCI SPEAr driver
[ 11.902391] ehci-st: EHCI STMicroelectronics driver
[ 11.902913] ehci-exynos: EHCI Exynos driver
[ 11.903472] ehci-atmel: EHCI Atmel driver
[ 11.904003] tegra-ehci: Tegra EHCI driver
[ 11.904565] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 11.904699] ohci-pci: OHCI PCI platform driver
[ 11.905129] ohci-platform: OHCI generic platform driver
[ 11.905788] SPEAr-ohci: OHCI SPEAr driver
[ 11.906328] ohci-st: OHCI STMicroelectronics driver
[ 11.906852] ohci-atmel: OHCI Atmel driver
[ 11.910001] usbcore: registered new interface driver usb-storage
[ 11.932956] i2c /dev entries driver
[ 11.976053] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 11.989857] sdhci: Secure Digital Host Controller Interface driver
[ 11.989904] sdhci: Copyright(c) Pierre Ossman
[ 11.996141] Synopsys Designware Multimedia Card Interface Driver
[ 12.000824] sdhci-pltfm: SDHCI platform and OF driver helper
[ 12.049618] mmc0: SDHCI controller on fe300000.mmcnr [fe300000.mmcnr] using PIO
[ 12.066581] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[ 12.068466] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 12.070357] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 12.073635] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 12.075501] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 12.079504] ledtrig-cpu: registered to indicate activity on CPUs
[ 12.081481] SMCCC: SOC_ID: ARCH_SOC_ID(0) returned error: ffffffff
[ 12.086306] usbcore: registered new interface driver usbhid
[ 12.086450] usbhid: USB HID core driver
[ 12.094396] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[ 12.111795] drop_monitor: Initializing network drop monitor service
[ 12.126160] NET: Registered protocol family 10
[ 12.138207] random: fast init done
[ 12.145018] mmc0: new high speed SDIO card at address 0001
[ 12.152384] Segment Routing with IPv6
[ 12.152975] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 12.161370] NET: Registered protocol family 17
[ 12.161453] can: controller area network core (rev 20170425 abi 9)
[ 12.163132] NET: Registered protocol family 29
[ 12.163172] can: raw protocol (rev 20170425)
[ 12.163206] can: broadcast manager protocol (rev 20170425 t)
[ 12.163279] can: netlink gateway (rev 20190810) max_hops=1
[ 12.166508] Key type dns_resolver registered
[ 12.166697] Registering SWP/SWPB emulation handler
[ 12.168357] Loading compiled-in X.509 certificates
[ 12.235310] uart-pl011 fe201000.serial: there is not valid maps for state default
[ 12.237103] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 29, base_baud = 0) is a PL011 rev2
[ 14.106799] printk: console [ttyAMA0] enabled
[ 14.164933] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-05-01T17:55:30
[ 14.322646] mmc1: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
[ 14.354019] uart-pl011 fe201000.serial: no DMA platform data
[ 14.360192] Waiting for root device ...
[ 14.395722] mmc1: new high speed SD card at address 1234
[ 14.410071] mmcblk1: mmc1:1234 SA02G 1.84 GiB
[ 14.433977] mmcblk1: p1
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-04 9:09 ` Ard Biesheuvel
@ 2020-10-04 20:24 ` Florian Fainelli
2020-10-05 8:40 ` Linus Walleij
1 sibling, 0 replies; 36+ messages in thread
From: Florian Fainelli @ 2020-10-04 20:24 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Arnd Bergmann, Abbott Liu, Linus Walleij, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
[-- Attachment #1: Type: text/plain, Size: 4532 bytes --]
On 10/4/2020 2:09 AM, Ard Biesheuvel wrote:
> On Sun, 4 Oct 2020 at 10:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Sun, 4 Oct 2020 at 10:06, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>
>>> On Sat, 3 Oct 2020 at 17:50, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>>
>>>> On Thu, 1 Oct 2020 at 21:19, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 10/1/2020 8:22 AM, Linus Walleij wrote:
>>>>>> This is the 14th iteration of KASan for ARM/Aarch32.
>>>>>>
>>>>>> I have added one patch in the beginning of the series to
>>>>>> fix the issue when the DTB (often attached DTB) ends up
>>>>>> in lowmem. It also amends ARM to copy the device tree
>>>>>> instead of just unflattening it and using it from where
>>>>>> it is.
>>>>>>
>>>>>> This fixes my particular issue on the Qualcomm APQ8060
>>>>>> and I hope it may also solve Florian's issue and what
>>>>>> Ard has been seeing. If you inspect patch 1/6 you can
>>>>>> see what has been going on for me. My hypothesis about
>>>>>> what was going on was mostly right.
>>>>>>
>>>>>> You are encouraged to test this patch set to find memory out
>>>>>> of bounds bugs with ARM32 platforms and drivers.
>>>>>>
>>>>>> There is a git branch you can pull in:
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
>>>>>
>>>>> It does appear to be slight better, although all platforms that I have
>>>>> where memory starts at physical address 0 cannot boot, attached logs
>>>>> which are all more or less the same.
>>>>>
>>>>> The physical memory map looks like this:
>>>>>
>>>>> 0..3GB -> DRAM
>>>>> 3GB..4GB -> Registers, Boot ROM, Boot SRAM
>>>>> 4GB..12GB -> DRAM extension
>>>>>
>>>>> Do any of the platforms you use for testing have a similar memory map?
>>>>> Could you try to contrive a QEMU machine to have something similar in
>>>>> case that helps reproducing these failures?
>>>>>
>>>>
>>>> I am getting very similar failures on a Raspberry Pi4 booting in
>>>> 32-bit mode from U-boot+EFI
>>>>
>>>> Full log attached.
>>>>
>>>> I will try to dig a bit deeper.
>>>
>>> OK, one obvious issue with the code as-is is that the following routine
>>>
>>> static __init void *kasan_alloc_block(size_t size)
>>> {
>>> return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
>>> MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
>>> }
>>>
>>> is called after the early shadow is unmapped, but before the permanent
>>> shadow is in place. memblock_alloc_try_nid() clears the newly
>>> allocated memory using memset(), which checks the associated shadow,
>>> which is unmapped -> BOOM.
>>>
>>> With the following implementation, I can avoid the crash similar to
>>> the one Florian is reporting:
>>>
>>> static __init void *kasan_alloc_block(size_t size)
>>> {
>>> void *p = memblock_alloc_try_nid_raw(size, size,
>>> __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_KASAN,
>>> NUMA_NO_NODE);
>>>
>>> if (p)
>>> __memset(p, 0, size);
>>> return p;
>>> }
>>>
>>> However, I still get a hang a bit later, and I haven't tracked that down yet.
>>
>> The above issue appears to be related to TLB maintenance. So keeping
>> kasan_alloc_block() as is, and doing
>>
>> --- a/arch/arm/mm/kasan_init.c
>> +++ b/arch/arm/mm/kasan_init.c
>> @@ -223,6 +223,8 @@ void __init kasan_init(void)
>> __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
>> #endif
>> cpu_switch_mm(tmp_pgd_table, &init_mm);
>> + local_flush_tlb_all();
>> +
>> clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>>
>> kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
>>
>> instead fixes the crash as well.
>>
>> Still have the hang right after though ..
>
> OK, booting now - turns out the switch back to swapper_pg_dir needs a
> proper TLB flush as well.
>
> Full patch below - with that applied, I can boot the RPi4 to the point
> where it wants to mount the rootfs (but I don't have a 32-bit rootfs
> at hand)
>
>
> The first change avoids reallocating KASAN blocks when a range gets
> mapped twice - this occurs when mapping the DTB space explicitly
> (although I am not sure that that is still needed now that you move
> the DTB)
We are almost there it seems. There are only 3 boards that do not boot
(they are all similar in configuration, amounts of memory and placement
of reserved regions), see the attached log. Every other platform now
boots correctly so this is definitively a big improvement!
--
Florian
[-- Attachment #2: 72112-bselinux-rack-03.log --]
[-- Type: text/plain, Size: 5290 bytes --]
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.9.0-rc7-g6e04af38fd04 (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #12 SMP Sun Oct 4 13:06:11 PDT 2020
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: BCM972112SV
[ 0.000000] earlycon: pl11 at MMIO 0x000000047e201000 (options '115200')
[ 0.000000] printk: bootconsole [pl11] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x000000007f000000
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xce5fe000
[ 0.000000] ATAGs/DTB found in lowmem, skip clearing PMD @0xce7fe000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000007fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x00000000063fdfff]
[ 0.000000] node 0: [mem 0x0000000006400000-0x000000000fffffff]
[ 0.000000] node 0: [mem 0x0000000010400000-0x000000007fffffff]
[ 0.000000] Zeroed struct page in unavailable ranges: 2 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]
[ 0.000000] MEMBLOCK configuration:
[ 0.000000] memory size = 0x000000007fbfe000 reserved size = 0x00000000053ef6e0
[ 0.000000] memory.cnt = 0x3
[ 0.000000] memory[0x0] [0x0000000000000000-0x00000000063fdfff], 0x00000000063fe000 bytes flags: 0x0
[ 0.000000] memory[0x1] [0x0000000006400000-0x000000000fffffff], 0x0000000009c00000 bytes flags: 0x0
[ 0.000000] memory[0x2] [0x0000000010400000-0x000000007fffffff], 0x000000006fc00000 bytes flags: 0x0
[ 0.000000] reserved.cnt = 0xb
[ 0.000000] reserved[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x0000000000003000-0x0000000000007fff], 0x0000000000005000 bytes flags: 0x0
[ 0.000000] reserved[0x2] [0x0000000000200000-0x0000000002fdcf9f], 0x0000000002ddcfa0 bytes flags: 0x0
[ 0.000000] reserved[0x3] [0x00000000061ff000-0x00000000061fffff], 0x0000000000001000 bytes flags: 0x0
[ 0.000000] reserved[0x4] [0x0000000006400000-0x00000000065fffff], 0x0000000000200000 bytes flags: 0x0
[ 0.000000] reserved[0x5] [0x000000000e415000-0x000000000e41960f], 0x0000000000004610 bytes flags: 0x0
[ 0.000000] reserved[0x6] [0x000000002e980000-0x000000002fd7ffff], 0x0000000001400000 bytes flags: 0x0
[ 0.000000] reserved[0x7] [0x000000002fff8000-0x000000002fffdfff], 0x0000000000006000 bytes flags: 0x0
[ 0.000000] reserved[0x8] [0x000000002fffeec0-0x000000002fffefbf], 0x0000000000000100 bytes flags: 0x0
[ 0.000000] reserved[0x9] [0x000000002fffefd0-0x000000002fffffff], 0x0000000000001030 bytes flags: 0x0
[ 0.000000] reserved[0xa] [0x000000007f000000-0x000000007fffffff], 0x0000000001000000 bytes flags: 0x0
[ 0.000000] kasan: Mapping kernel virtual memory block: c0000000-c63fe000 at shadow: b7000000-b7c7fc00
[ 0.000000] Kernel panic - not syncing: kasan_pte_populate failed to alloc pte for address 0xe2806000
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc7-g6e04af38fd04 #12
[ 0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[ 0.000000] Backtrace:
[ 0.000000] [<c02120b4>] (dump_backtrace) from [<c02123d8>] (show_stack+0x20/0x24)
[ 0.000000] r9:ffffffff r8:00000080 r7:c298e900 r6:600000d3 r5:00000000 r4:c298e900
[ 0.000000] [<c02123b8>] (show_stack) from [<c08869e0>] (dump_stack+0xbc/0xe0)
[ 0.000000] [<c0886924>] (dump_stack) from [<c022fc6c>] (panic+0x19c/0x3e4)
[ 0.000000] r10:e2806000 r9:c2b790e0 r8:c166b5bc r7:c2803d60 r6:00000000 r5:c2b7df00
[ 0.000000] r4:c2b78e20 r3:00000001
[ 0.000000] [<c022fad0>] (panic) from [<c180bae4>] (kasan_pgd_populate+0x1ac/0x26c)
[ 0.000000] r3:00000000 r2:e2806000 r1:c1212734 r0:c166b5bc
[ 0.000000] r7:b7c7fc00
[ 0.000000] [<c180b938>] (kasan_pgd_populate) from [<c180bbfc>] (create_mapping+0x58/0x64)
[ 0.000000] r10:c166b690 r9:00000000 r8:063fe000 r7:c2ba0ac0 r6:c28a29e0 r5:b7000000
[ 0.000000] r4:b7c7fc00
[ 0.000000] [<c180bba4>] (create_mapping) from [<c180bee0>] (kasan_init+0x270/0x3c0)
[ 0.000000] r5:00000000 r4:c0000000
[ 0.000000] [<c180bc70>] (kasan_init) from [<c1805684>] (setup_arch+0x848/0x1048)
[ 0.000000] r10:c1861450 r9:c0226668 r8:e12fff1e r7:c0008000 r6:c1873a40 r5:c2fdcfa0
[ 0.000000] r4:c28a2780
[ 0.000000] [<c1804e3c>] (setup_arch) from [<c1801010>] (start_kernel+0x88/0x3e4)
[ 0.000000] r10:c2806d40 r9:410fd083 r8:0e415000 r7:ffffffff r6:30c0387d r5:c2806d48
[ 0.000000] r4:00007000
[ 0.000000] [<c1800f88>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:30c5387d r9:410fd083 r8:0e415000 r7:ffffffff r6:30c0387d r5:00000000
[ 0.000000] r4:c1800334
[ 0.000000] ---[ end Kernel panic - not syncing: kasan_pte_populate failed to alloc pte for address 0xe2806000 ]---
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-04 9:09 ` Ard Biesheuvel
2020-10-04 20:24 ` Florian Fainelli
@ 2020-10-05 8:40 ` Linus Walleij
1 sibling, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-05 8:40 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Florian Fainelli, Arnd Bergmann, Abbott Liu, Russell King,
Mike Rapoport, Andrey Ryabinin, Linux ARM
On Sun, Oct 4, 2020 at 11:09 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> OK, booting now - turns out the switch back to swapper_pg_dir needs a
> proper TLB flush as well.
Wow this is so nice, thanks a ton Ard!!
I folded this into my kasan init patch.
> The first change avoids reallocating KASAN blocks when a range gets
> mapped twice - this occurs when mapping the DTB space explicitly
> (although I am not sure that that is still needed now that you move
> the DTB)
Sooner or later someone is going to make this happen anyway
so better be safe than sorry.
Thanks!!
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/6 v14] KASan for Arm
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
` (6 preceding siblings ...)
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
@ 2020-10-06 13:21 ` Linus Walleij
7 siblings, 0 replies; 36+ messages in thread
From: Linus Walleij @ 2020-10-06 13:21 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin, Mike Rapoport
Cc: Arnd Bergmann, Linux ARM
On Thu, Oct 1, 2020 at 5:22 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> There is a git branch you can pull in:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
I have updated this branch with a version with Ard's patches for
relocating the DTB to fixed mapping underneath, and the patches
there have Ard's fixes folded in as well.
Will resend tomorrow or so.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread
