Re: [PATCH v6 13/18] arm64: unwind: strip PAC from kernel addresses

From: James Morse <james.morse@arm.com>
To: Amit Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kees Cook <keescook@chromium.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 13/18] arm64: unwind: strip PAC from kernel addresses
Date: Wed, 11 Mar 2020 09:09:19 +0000	[thread overview]
Message-ID: <455e8848-a1c4-e279-2ec0-1edccf34bb08@arm.com> (raw)
In-Reply-To: <feb49588-56ce-8052-bef1-ef3d88c0af81@arm.com>

Hi Amit,

On 3/11/20 6:07 AM, Amit Kachhap wrote:
> On 3/10/20 11:07 PM, James Morse wrote:
>> On 10/03/2020 12:28, Amit Kachhap wrote:
>>> On 3/10/20 12:33 AM, James Morse wrote:
>>>> On 06/03/2020 06:35, Amit Daniel Kachhap wrote:
>>>>> From: Mark Rutland <mark.rutland@arm.com>
>>>>>
>>>>> When we enable pointer authentication in the kernel, LR values
>>>>> saved to
>>>>> the stack will have a PAC which we must strip in order to retrieve the
>>>>> real return address.
>>>>>
>>>>> Strip PACs when unwinding the stack in order to account for this.
>>>>
>>>> This patch had me looking at the wider pointer-auth + ftrace
>>>> interaction...

>>>>> diff --git a/arch/arm64/kernel/stacktrace.c
>>>>> b/arch/arm64/kernel/stacktrace.c
>>>>> index a336cb1..b479df7 100644
>>>>> --- a/arch/arm64/kernel/stacktrace.c
>>>>> +++ b/arch/arm64/kernel/stacktrace.c
>>>>> @@ -14,6 +14,7 @@
>>>>>    #include <linux/stacktrace.h>
>>>>>      #include <asm/irq.h>
>>>>> +#include <asm/pointer_auth.h>
>>>>>    #include <asm/stack_pointer.h>
>>>>>    #include <asm/stacktrace.h>
>>>>>    @@ -101,6 +102,8 @@ int notrace unwind_frame(struct task_struct
>>>>> *tsk, struct
>>>>> stackframe *frame)
>>>>
>>>> There is an earlier reader of frame->pc:
>>>> | #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>>> |     if (tsk->ret_stack &&
>>>> |             (frame->pc == (unsigned long)return_to_handler)) {
>>>>

>>>> Could the ptrauth_strip_insn_pac() call move above the
>>>> CONFIG_FUNCTION_GRAPH_TRACER block,
>>
>>> This may not be required as we never explicitly sign return_to_handler
>>
>> Doesn't the original caller sign it? (I agree that assembly is tricky
>> to work out)

> I used dump_stack() instead of WARN_ON and able to reproduce the issue.
> Yes ptrauth_strip_insn_pac needs to move up to fix this. Thanks for the
> details.

Great!

>>>> and could we add something like:
>>>> |    depends on (!FTRACE || HAVE_DYNAMIC_FTRACE_WITH_REGS)
>>>>
>>>> to the Kconfig to prevent both FTRACE and PTR_AUTH being enabled
>>>> unless the compiler has
>>>> support for patchable-function-entry?
>>>
>>> Yes this is a good condition to have. I feel below condition is more
>>> suitable as there is
>>> issue only with FUNCTION_GRAPH_TRACER,
>>
>> Er, yes!
>> Because its callers of prepare_ftrace_return() that have the problem,
>> and that is behind
>> #ifdef FUNCTION_GRAPH_TRACER.

With the ptrauth_strip_insn_pac() moved, and your better version of that
Kconfig suggestion:
Reviewed-by: James Morse <james.morse@arm.com>

Thanks!

James

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