lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211027045843.1770770-2-alexandre.ghiti@canonical.com>
Date:   Wed, 27 Oct 2021 06:58:43 +0200
From:   Alexandre Ghiti <alexandre.ghiti@...onical.com>
To:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kasan-dev@...glegroups.com
Cc:     Alexandre Ghiti <alexandre.ghiti@...onical.com>
Subject: [PATCH 2/2] riscv: Fix CONFIG_KASAN_STACK build

Now that CONFIG_KASAN_SHADOW_OFFSET is correctly defined, the boot
hung while populating the shadow memory right after the call to
kasan_populate_early_shadow: when calling this function, all the shadow
memory is already populated with kasan_early_shadow_pte which has
PAGE_KERNEL protection.

kasan_populate_early_shadow write-protects the mapping of the range
of addresses passed in argument in zero_pte_populate, which actually
write-protects all the shadow memory mapping since
kasan_early_shadow_pte is used for all the shadow memory at this point.
And then when using memblock API to populate the shadow memory, the first
write access to the kernel stack triggers a trap.

We already manually populate all the shadow memory in kasan_early_init
and we write-protect kasan_early_shadow_pte at the end of kasan_init
which makes the call to kasan_populate_early_shadow superfluous so
we can remove it.

Signed-off-by: Alexandre Ghiti <alexandre.ghiti@...onical.com>
---
 arch/riscv/mm/kasan_init.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 8175e98b9073..8df937902630 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -175,13 +175,6 @@ void __init kasan_init(void)
 	phys_addr_t p_start, p_end;
 	u64 i;
 
-	/*
-	 * Populate all kernel virtual address space with kasan_early_shadow_page
-	 * except for the linear mapping and the modules/kernel/BPF mapping.
-	 */
-	kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
-				    (void *)kasan_mem_to_shadow((void *)
-								VMEMMAP_END));
 	if (IS_ENABLED(CONFIG_KASAN_VMALLOC))
 		kasan_shallow_populate(
 			(void *)kasan_mem_to_shadow((void *)VMALLOC_START),
-- 
2.30.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ