All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Daniel Axtens <dja@axtens.net>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	kasan-dev@googlegroups.com, linux-mm@kvack.org
Subject: [PATCH RFC v3 17/18] kasan: allow architectures to provide an outline readiness check
Date: Tue, 12 Mar 2019 22:16:23 +0000 (UTC)	[thread overview]
Message-ID: <4f888b49a3c72105ef8e74997fcb2ab20ad2252d.1552428161.git.christophe.leroy@c-s.fr> (raw)
In-Reply-To: <cover.1552428161.git.christophe.leroy@c-s.fr>

From: Daniel Axtens <dja@axtens.net>

In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initialised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.

My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)

So, allow architectures to define a kasan_arch_is_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.

Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/      # ppc radix series
Originally-by: Balbir Singh <bsingharora@gmail.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
[check_return_arch_not_ready() ==> static inline kasan_arch_is_ready()]
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 include/linux/kasan.h | 4 ++++
 mm/kasan/generic.c    | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index f6261840f94c..a630d53f1a36 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -14,6 +14,10 @@ struct task_struct;
 #include <asm/kasan.h>
 #include <asm/pgtable.h>
 
+#ifndef kasan_arch_is_ready
+static inline bool kasan_arch_is_ready(void)	{ return true; }
+#endif
+
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
 extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
 extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index a5b28e3ceacb..0336f31bbae3 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -170,6 +170,9 @@ static __always_inline void check_memory_region_inline(unsigned long addr,
 						size_t size, bool write,
 						unsigned long ret_ip)
 {
+	if (!kasan_arch_is_ready())
+		return;
+
 	if (unlikely(size == 0))
 		return;
 
-- 
2.13.3


WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Daniel Axtens <dja@axtens.net>
Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com
Subject: [PATCH RFC v3 17/18] kasan: allow architectures to provide an outline readiness check
Date: Tue, 12 Mar 2019 22:16:23 +0000 (UTC)	[thread overview]
Message-ID: <4f888b49a3c72105ef8e74997fcb2ab20ad2252d.1552428161.git.christophe.leroy@c-s.fr> (raw)
In-Reply-To: <cover.1552428161.git.christophe.leroy@c-s.fr>

From: Daniel Axtens <dja@axtens.net>

In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initialised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.

My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)

So, allow architectures to define a kasan_arch_is_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.

Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/      # ppc radix series
Originally-by: Balbir Singh <bsingharora@gmail.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
[check_return_arch_not_ready() ==> static inline kasan_arch_is_ready()]
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 include/linux/kasan.h | 4 ++++
 mm/kasan/generic.c    | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index f6261840f94c..a630d53f1a36 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -14,6 +14,10 @@ struct task_struct;
 #include <asm/kasan.h>
 #include <asm/pgtable.h>
 
+#ifndef kasan_arch_is_ready
+static inline bool kasan_arch_is_ready(void)	{ return true; }
+#endif
+
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
 extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
 extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index a5b28e3ceacb..0336f31bbae3 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -170,6 +170,9 @@ static __always_inline void check_memory_region_inline(unsigned long addr,
 						size_t size, bool write,
 						unsigned long ret_ip)
 {
+	if (!kasan_arch_is_ready())
+		return;
+
 	if (unlikely(size == 0))
 		return;
 
-- 
2.13.3


  parent reply	other threads:[~2019-03-12 22:17 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12 22:16 [PATCH v10 00/18] KASAN for powerpc/32 and RFC for 64bit Book3E Christophe Leroy
2019-03-12 22:16 ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 01/18] powerpc/6xx: fix setup and use of SPRN_SPRG_PGDIR for hash32 Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 02/18] powerpc/32: Move early_init() in a separate file Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 03/18] powerpc: prepare string/mem functions for KASAN Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 04/18] powerpc: remove CONFIG_CMDLINE #ifdef mess Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 05/18] powerpc/prom_init: don't use string functions from lib/ Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 23:38   ` Daniel Axtens
2019-03-12 23:38     ` Daniel Axtens
2019-04-26 16:24     ` Christophe Leroy
2019-04-26 16:24       ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 06/18] powerpc/mm: don't use direct assignation during early boot Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 07/18] powerpc/32: use memset() instead of memset_io() to zero BSS Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 08/18] powerpc/32: make KVIRT_TOP dependent on FIXMAP_START Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 09/18] powerpc/32: prepare shadow area for KASAN Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 10/18] powerpc: disable KASAN instrumentation on early/critical files Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 11/18] powerpc/32: Add KASAN support Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 12/18] powerpc/32s: move hash code patching out of MMU_init_hw() Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 13/18] powerpc/32s: set up an early static hash table for KASAN Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH v10 14/18] powerpc/32s: map kasan zero shadow with PAGE_READONLY instead of PAGE_KERNEL_RO Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH RFC v3 15/18] kasan: do not open-code addr_has_shadow Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` [PATCH RFC v3 16/18] kasan: allow architectures to manage the memory-to-shadow mapping Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-12 22:16 ` Christophe Leroy [this message]
2019-03-12 22:16   ` [PATCH RFC v3 17/18] kasan: allow architectures to provide an outline readiness check Christophe Leroy
2019-03-12 22:16 ` [PATCH RFC v3 18/18] powerpc: KASAN for 64bit Book3E Christophe Leroy
2019-03-12 22:16   ` Christophe Leroy
2019-03-13  7:02   ` Christophe Leroy
2019-03-13  8:30     ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f888b49a3c72105ef8e74997fcb2ab20ad2252d.1552428161.git.christophe.leroy@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=benh@kernel.crashing.org \
    --cc=dja@axtens.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.