Re: [PATCH 0/4] PAN for ARM32 using LPAE

From: Kees Cook <keescook@chromium.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Stefan Wahren <wahrenst@gmx.net>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH 0/4] PAN for ARM32 using LPAE
Date: Tue, 23 Jan 2024 13:28:52 -0800	[thread overview]
Message-ID: <202401231317.26C7E64D6@keescook> (raw)
In-Reply-To: <20240123-arm32-lpae-pan-v1-0-7ea98a20514c@linaro.org>

On Tue, Jan 23, 2024 at 10:16:13PM +0100, Linus Walleij wrote:
> This is a patch set from Catalin that ended up on the back burner.
>
> Since LPAE systems, i.e. ARM32 systems with a lot of physical memory,
> will be with us for a while more, this is a pretty straight-forward
> hardening measure that we should support.
>
> The last patch explains the mechanism: since PAN using CPU domains
> isn't available when using the LPAE MMU tables, we use the split
> between the two translation base tables instead: TTBR0 is for
> userspace pages and TTBR1 is for kernelspace tables. When executing
> in kernelspace: we protect userspace by simply disabling page
> walks in TTBR0.
>
> This was tested by a simple hack in the ELF loader:
>
> create_elf_tables()
> +       unsigned char *test;
> (...)
>         if (copy_to_user(u_rand_bytes, k_rand_bytes, sizeof(k_rand_bytes)))
>                 return -EFAULT;
> +       /* Cause a kernelspace access to userspace memory */
> +       test = (char *)u_rand_bytes;
> +       pr_info("Some byte: %02x\n", *test);
>
> This tries to read a byte from userspace memory right after the
> first unconditional copy_to_user(), a function that carefully
> switches access permissions if we're using PAN.

You can also use CONFIG_LKDTM to test, with:

# echo "ACCESS_USERSPACE" | cat >/sys/kernel/debug/provoke-crash/DIRECT
...
lkdtm: Performing direct entry ACCESS_USERSPACE
lkdtm: attempting bad read at 76fe9000
8<--- cut here ---
Unable to handle kernel paging request at virtual address 76fe9000 when read
[76fe9000] *pgd=45e47003, *pmd=43fd3003, *pte=a0000048af7f5f
Internal error: Oops: 206 [#1] SMP ARM
...

# echo "EXEC_USERSPACE" | cat >/sys/kernel/debug/provoke-crash/DIRECT
...
lkdtm: Performing direct entry EXEC_USERSPACE
lkdtm: attempting ok execution at 8083707c
lkdtm: attempting bad execution at 76f38000
8<--- cut here ---
Unable to handle kernel paging request at virtual address 76f38000 when execute
[76f38000] *pgd=49ed2003, *pmd=49e19003, *pte=a00000494a5f5f
Internal error: Oops: 80000206 [#2] SMP ARM
...

I can confirm it works as expected. :)

Tested-by: Kees Cook <keescook@chromium.org>

Thanks!

-Kees

--
Kees Cook

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel