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: <CAMj1kXEzSwOtMGUi1VMg9xj60sHJ=9GHdjK2LXBXahSPmm56jw@mail.gmail.com>
Date:   Tue, 16 Aug 2022 16:45:14 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Lecopzer Chen <lecopzer.chen@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Russell King <rmk+kernel@...linux.org.uk>,
        linux@...linux.org.uk, ryabinin.a.a@...il.com,
        matthias.bgg@...il.com, arnd@...db.de, rostedt@...dmis.org,
        nick.hawkins@....com, john@...ozen.org,
        linux-arm-kernel@...ts.infradead.org, kasan-dev@...glegroups.com,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH AUTOSEL 5.19 54/64] ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC

On Sun, 14 Aug 2022 at 17:30, Sasha Levin <sashal@...nel.org> wrote:
>
> From: Lecopzer Chen <lecopzer.chen@...iatek.com>
>
> [ Upstream commit 565cbaad83d83e288927b96565211109bc984007 ]
>
> Simply make shadow of vmalloc area mapped on demand.
>
> Since the virtual address of vmalloc for Arm is also between
> MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
> address has already included between KASAN_SHADOW_START and
> KASAN_SHADOW_END.
> Thus we need to change nothing for memory map of Arm.
>
> This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
> and support CONFIG_VMAP_STACK with KASan.
>
> Signed-off-by: Lecopzer Chen <lecopzer.chen@...iatek.com>
> Tested-by: Linus Walleij <linus.walleij@...aro.org>
> Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> Signed-off-by: Sasha Levin <sashal@...nel.org>

This patch does not belong in -stable. It has no fixes: or cc:stable
tags, and the contents are completely inappropriate for backporting
anywhere. In general, I think that no patch that touches arch/arm
(with the exception of DTS updates, perhaps) should ever be backported
unless proposed or acked by the maintainer.

I know I shouldn't ask, but how were these patches build/boot tested?
KAsan is very tricky to get right, especially on 32-bit ARM ...

> ---
>  arch/arm/Kconfig         | 1 +
>  arch/arm/mm/kasan_init.c | 6 +++++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 7630ba9cb6cc..545d2d4a492b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -75,6 +75,7 @@ config ARM
>         select HAVE_ARCH_KFENCE if MMU && !XIP_KERNEL
>         select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>         select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
> +       select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
>         select HAVE_ARCH_MMAP_RND_BITS if MMU
>         select HAVE_ARCH_PFN_VALID
>         select HAVE_ARCH_SECCOMP
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> index 5ad0d6c56d56..29caee9c79ce 100644
> --- a/arch/arm/mm/kasan_init.c
> +++ b/arch/arm/mm/kasan_init.c
> @@ -236,7 +236,11 @@ void __init kasan_init(void)
>
>         clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>
> -       kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
> +       if (!IS_ENABLED(CONFIG_KASAN_VMALLOC))
> +               kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
> +                                           kasan_mem_to_shadow((void *)VMALLOC_END));
> +
> +       kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_END),
>                                     kasan_mem_to_shadow((void *)-1UL) + 1);
>
>         for_each_mem_range(i, &pa_start, &pa_end) {
> --
> 2.35.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ