Re: [PATCH v4 0/5] ARM: support THREAD_INFO_IN_TASK

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Keith Packard <keithpac@amazon.com>,
	Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v4 0/5] ARM: support THREAD_INFO_IN_TASK
Date: Mon, 13 Sep 2021 12:23:37 +0100	[thread overview]
Message-ID: <YT80ud2eh3h9f77p@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210913104001.3043132-1-ardb@kernel.org>

On Mon, Sep 13, 2021 at 12:39:56PM +0200, Ard Biesheuvel wrote:
> Placing thread_info in the kernel stack leaves it vulnerable to stack
> overflow attacks. This short series addresses that by using the existing
> THREAD_INFO_IN_TASK infrastructure.
> 
> This v4 is a follow-up to Keith's v3 [0], which did not address all
> concerns I raised in response to v2. After collaborating with Keith
> off-list, we decided that I should go ahead and post our joint v4.
> 
> Changes since v3:
> 
> - Leave the CPU field in thread_info, and keep it in sync at context
>   switch time. This is by far the easiest and cleanest way to work
>   around the fact that it is infeasible to implement
>   raw_smp_processor_id() in terms of task_struct::cpu (for reasons of
>   header soup).
> 
> - Drop the VFP changes, they are no longer necessary given the previous
>   point.
> 
> - Drop the change to pass the CPU number to secondary_start_kernel().
>   Given that we also need to pass the idle task pointer, which carries
>   the CPU number, passing the CPU number directly is redundant.
> 
> - Use the TPIDRURO register to carry 'current' while running in the
>   kernel, and keep using TPIDRPRW for the per-CPU offset as before. This
>   way, there is no need to make any changes to the way the per-CPU offsets
>   are programmed. It also avoids the concurrency issues that would
>   result from carrying the 'current' pointer in a per-CPU variable.
> 
> - Update the per-task stack protector plugin to pull the stack canary
>   value directly from the task struct.

Overall, this looks much simpler than Keith's v3 to me, so probably
less likely to run into issues in the future. The only suggestion I
hvae is the comment I've made on patch 4.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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