From: Lecopzer Chen <lecopzer.chen@mediatek.com> To: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <kasan-dev@googlegroups.com>, <catalin.marinas@arm.com>, <will@kernel.org> Cc: <ryabinin.a.a@gmail.com>, <glider@google.com>, <andreyknvl@gmail.com>, <dvyukov@google.com>, <akpm@linux-foundation.org>, <tyhicks@linux.microsoft.com>, <maz@kernel.org>, <rppt@kernel.org>, <linux@roeck-us.net>, <gustavoars@kernel.org>, <yj.chiang@mediatek.com>, Lecopzer Chen <lecopzer.chen@mediatek.com> Subject: [PATCH v4 4/5] arm64: kaslr: support randomized module area with KASAN_VMALLOC Date: Wed, 24 Mar 2021 12:05:21 +0800 [thread overview] Message-ID: <20210324040522.15548-5-lecopzer.chen@mediatek.com> (raw) In-Reply-To: <20210324040522.15548-1-lecopzer.chen@mediatek.com> After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now. Test: VMALLOC area ffffffc010000000 fffffffdf0000000 before the patch: module_alloc_base/end ffffffc008b80000 ffffffc010000000 after the patch: module_alloc_base/end ffffffdcf4bed000 ffffffc010000000 And the function that insmod some modules is fine. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> --- arch/arm64/kernel/kaslr.c | 18 ++++++++++-------- arch/arm64/kernel/module.c | 16 +++++++++------- 2 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c index 27f8939deb1b..341342b207f6 100644 --- a/arch/arm64/kernel/kaslr.c +++ b/arch/arm64/kernel/kaslr.c @@ -128,15 +128,17 @@ u64 __init kaslr_early_init(void) /* use the top 16 bits to randomize the linear region */ memstart_offset_seed = seed >> 48; - if (IS_ENABLED(CONFIG_KASAN_GENERIC) || - IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) && + (IS_ENABLED(CONFIG_KASAN_GENERIC) || + IS_ENABLED(CONFIG_KASAN_SW_TAGS))) /* - * KASAN does not expect the module region to intersect the - * vmalloc region, since shadow memory is allocated for each - * module at load time, whereas the vmalloc region is shadowed - * by KASAN zero pages. So keep modules out of the vmalloc - * region if KASAN is enabled, and put the kernel well within - * 4 GB of the module region. + * KASAN without KASAN_VMALLOC does not expect the module region + * to intersect the vmalloc region, since shadow memory is + * allocated for each module at load time, whereas the vmalloc + * region is shadowed by KASAN zero pages. So keep modules + * out of the vmalloc region if KASAN is enabled without + * KASAN_VMALLOC, and put the kernel well within 4 GB of the + * module region. */ return offset % SZ_2G; diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index fe21e0f06492..b5ec010c481f 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -40,14 +40,16 @@ void *module_alloc(unsigned long size) NUMA_NO_NODE, __builtin_return_address(0)); if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) && - !IS_ENABLED(CONFIG_KASAN_GENERIC) && - !IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + (IS_ENABLED(CONFIG_KASAN_VMALLOC) || + (!IS_ENABLED(CONFIG_KASAN_GENERIC) && + !IS_ENABLED(CONFIG_KASAN_SW_TAGS)))) /* - * KASAN can only deal with module allocations being served - * from the reserved module region, since the remainder of - * the vmalloc region is already backed by zero shadow pages, - * and punching holes into it is non-trivial. Since the module - * region is not randomized when KASAN is enabled, it is even + * KASAN without KASAN_VMALLOC can only deal with module + * allocations being served from the reserved module region, + * since the remainder of the vmalloc region is already + * backed by zero shadow pages, and punching holes into it + * is non-trivial. Since the module region is not randomized + * when KASAN is enabled without KASAN_VMALLOC, it is even * less likely that the module region gets exhausted, so we * can simply omit this fallback in that case. */ -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Lecopzer Chen <lecopzer.chen@mediatek.com> To: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <kasan-dev@googlegroups.com>, <catalin.marinas@arm.com>, <will@kernel.org> Cc: <ryabinin.a.a@gmail.com>, <glider@google.com>, <andreyknvl@gmail.com>, <dvyukov@google.com>, <akpm@linux-foundation.org>, <tyhicks@linux.microsoft.com>, <maz@kernel.org>, <rppt@kernel.org>, <linux@roeck-us.net>, <gustavoars@kernel.org>, <yj.chiang@mediatek.com>, Lecopzer Chen <lecopzer.chen@mediatek.com> Subject: [PATCH v4 4/5] arm64: kaslr: support randomized module area with KASAN_VMALLOC Date: Wed, 24 Mar 2021 12:05:21 +0800 [thread overview] Message-ID: <20210324040522.15548-5-lecopzer.chen@mediatek.com> (raw) In-Reply-To: <20210324040522.15548-1-lecopzer.chen@mediatek.com> After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now. Test: VMALLOC area ffffffc010000000 fffffffdf0000000 before the patch: module_alloc_base/end ffffffc008b80000 ffffffc010000000 after the patch: module_alloc_base/end ffffffdcf4bed000 ffffffc010000000 And the function that insmod some modules is fine. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> --- arch/arm64/kernel/kaslr.c | 18 ++++++++++-------- arch/arm64/kernel/module.c | 16 +++++++++------- 2 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c index 27f8939deb1b..341342b207f6 100644 --- a/arch/arm64/kernel/kaslr.c +++ b/arch/arm64/kernel/kaslr.c @@ -128,15 +128,17 @@ u64 __init kaslr_early_init(void) /* use the top 16 bits to randomize the linear region */ memstart_offset_seed = seed >> 48; - if (IS_ENABLED(CONFIG_KASAN_GENERIC) || - IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) && + (IS_ENABLED(CONFIG_KASAN_GENERIC) || + IS_ENABLED(CONFIG_KASAN_SW_TAGS))) /* - * KASAN does not expect the module region to intersect the - * vmalloc region, since shadow memory is allocated for each - * module at load time, whereas the vmalloc region is shadowed - * by KASAN zero pages. So keep modules out of the vmalloc - * region if KASAN is enabled, and put the kernel well within - * 4 GB of the module region. + * KASAN without KASAN_VMALLOC does not expect the module region + * to intersect the vmalloc region, since shadow memory is + * allocated for each module at load time, whereas the vmalloc + * region is shadowed by KASAN zero pages. So keep modules + * out of the vmalloc region if KASAN is enabled without + * KASAN_VMALLOC, and put the kernel well within 4 GB of the + * module region. */ return offset % SZ_2G; diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index fe21e0f06492..b5ec010c481f 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -40,14 +40,16 @@ void *module_alloc(unsigned long size) NUMA_NO_NODE, __builtin_return_address(0)); if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) && - !IS_ENABLED(CONFIG_KASAN_GENERIC) && - !IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + (IS_ENABLED(CONFIG_KASAN_VMALLOC) || + (!IS_ENABLED(CONFIG_KASAN_GENERIC) && + !IS_ENABLED(CONFIG_KASAN_SW_TAGS)))) /* - * KASAN can only deal with module allocations being served - * from the reserved module region, since the remainder of - * the vmalloc region is already backed by zero shadow pages, - * and punching holes into it is non-trivial. Since the module - * region is not randomized when KASAN is enabled, it is even + * KASAN without KASAN_VMALLOC can only deal with module + * allocations being served from the reserved module region, + * since the remainder of the vmalloc region is already + * backed by zero shadow pages, and punching holes into it + * is non-trivial. Since the module region is not randomized + * when KASAN is enabled without KASAN_VMALLOC, it is even * less likely that the module region gets exhausted, so we * can simply omit this fallback in that case. */ -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-24 4:06 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-24 4:05 [PATCH v4 0/5] arm64: kasan: support CONFIG_KASAN_VMALLOC Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen 2021-03-24 4:05 ` [PATCH v4 1/5] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen 2021-03-24 4:05 ` [PATCH v4 2/5] arm64: kasan: abstract _text and _end to KERNEL_START/END Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen 2021-03-24 4:05 ` [PATCH v4 3/5] arm64: Kconfig: support CONFIG_KASAN_VMALLOC Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen [this message] 2021-03-24 4:05 ` [PATCH v4 4/5] arm64: kaslr: support randomized module area with KASAN_VMALLOC Lecopzer Chen 2021-03-24 4:05 ` [PATCH v4 5/5] arm64: Kconfig: select KASAN_VMALLOC if KANSAN_GENERIC is enabled Lecopzer Chen 2021-03-24 4:05 ` Lecopzer Chen 2021-03-29 12:54 ` Will Deacon 2021-03-29 12:54 ` Will Deacon 2021-03-30 8:14 ` Lecopzer Chen 2021-03-30 8:14 ` Lecopzer Chen 2021-03-30 15:41 ` Andrey Konovalov 2021-03-30 15:41 ` Andrey Konovalov 2021-03-29 12:28 ` [PATCH v4 0/5] arm64: kasan: support CONFIG_KASAN_VMALLOC Catalin Marinas 2021-03-29 12:28 ` Catalin Marinas
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=20210324040522.15548-5-lecopzer.chen@mediatek.com \ --to=lecopzer.chen@mediatek.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=gustavoars@kernel.org \ --cc=kasan-dev@googlegroups.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=maz@kernel.org \ --cc=rppt@kernel.org \ --cc=ryabinin.a.a@gmail.com \ --cc=tyhicks@linux.microsoft.com \ --cc=will@kernel.org \ --cc=yj.chiang@mediatek.com \ /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: linkBe 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.