linux-kernel - Re: [PATCH] ARM: unwind: improve unwinders for noreturn case

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: <fb8c6e8f-de47-8cbc-e30a-60961f5ce7ad@huawei.com>
Date: Wed, 20 Mar 2024 11:30:13 +0800
From: Jiangfeng Xiao <xiaojiangfeng@...wei.com>
To: Kees Cook <keescook@...omium.org>
CC: <linux@...linux.org.uk>, <arnd@...db.de>, <rmk+kernel@...linux.org.uk>,
	<haibo.li@...iatek.com>, <angelogioacchino.delregno@...labora.com>,
	<amergnat@...libre.com>, <akpm@...ux-foundation.org>,
	<dave.hansen@...ux.intel.com>, <douzhaolei@...wei.com>,
	<gustavoars@...nel.org>, <jpoimboe@...nel.org>, <kepler.chenxin@...wei.com>,
	<kirill.shutemov@...ux.intel.com>, <linux-hardening@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-arm-kernel@...ts.infradead.org>, <nixiaoming@...wei.com>,
	<peterz@...radead.org>, <wangbing6@...wei.com>, <wangfangpeng1@...wei.com>,
	<jannh@...gle.com>, <David.Laight@...lab.com>
Subject: Re: [PATCH] ARM: unwind: improve unwinders for noreturn case



On 2024/3/20 10:46, Kees Cook wrote:
> On Wed, Mar 20, 2024 at 10:19:29AM +0800, Jiangfeng Xiao wrote:
>> This is an off-by-one bug which is common in unwinders,
>> due to the fact that the address on the stack points
>> to the return address rather than the call address.
>>
>> So, for example, when the last instruction of a function
>> is a function call (e.g., to a noreturn function), it can
>> cause the unwinder to incorrectly try to unwind from
>> the function after the callee.
>>
>> foo:
>> ...
>> 	bl	bar
>> ... end of function and thus next function ...
>>
>> which results in LR pointing into the next function.
>>
>> Fixed this by subtracting 1 from frmae->pc in the call frame
>> (but not exception frames) like ORC on x86 does.
>>
>> Refer to the unwind_next_frame function in the unwind_orc.c
>>
>> Suggested-by: Josh Poimboeuf <jpoimboe@...nel.org>
>> Link: https://lkml.kernel.org/lkml/20240305175846.qnyiru7uaa7itqba@treble/
>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@...wei.com>
>> ---
>>  arch/arm/include/asm/stacktrace.h |  4 ----
>>  arch/arm/kernel/stacktrace.c      |  2 --
>>  arch/arm/kernel/traps.c           |  4 ++--
>>  arch/arm/kernel/unwind.c          | 18 +++++++++++++++---
>>  4 files changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
>> index 360f0d2..07e4c16 100644
>> --- a/arch/arm/include/asm/stacktrace.h
>> +++ b/arch/arm/include/asm/stacktrace.h
>> @@ -21,9 +21,7 @@ struct stackframe {
>>  	struct llist_node *kr_cur;
>>  	struct task_struct *tsk;
>>  #endif
>> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
>>  	bool ex_frame;
>> -#endif
>>  };
>>  
>>  static __always_inline
>> @@ -37,9 +35,7 @@ void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame)
>>  		frame->kr_cur = NULL;
>>  		frame->tsk = current;
>>  #endif
>> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
>>  		frame->ex_frame = in_entry_text(frame->pc);
>> -#endif
>>  }
>>  
>>  extern int unwind_frame(struct stackframe *frame);
>> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
>> index 620aa82..1abd4f9 100644
>> --- a/arch/arm/kernel/stacktrace.c
>> +++ b/arch/arm/kernel/stacktrace.c
>> @@ -154,9 +154,7 @@ static void start_stack_trace(struct stackframe *frame, struct task_struct *task
>>  	frame->kr_cur = NULL;
>>  	frame->tsk = task;
>>  #endif
>> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
>>  	frame->ex_frame = in_entry_text(frame->pc);
>> -#endif
>>  }
>>  
>>  void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 3bad79d..b64e442 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -84,10 +84,10 @@ void dump_backtrace_entry(unsigned long where, unsigned long from,
>>  	printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
>>  		loglvl, where, from);
>>  #elif defined CONFIG_BACKTRACE_VERBOSE
>> -	printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
>> +	pr_warn("%s[<%08lx>] (%ps) from [<%08lx>] (%pB)\n",
>>  		loglvl, where, (void *)where, from, (void *)from);
> 
> This should stay printk("%s...", loglvl, ...) or loglvl should be
> dropped when converting to pr_warn():
> 
> 	pr_warn([<%08lx>] (%ps) from [<%08lx>] (%pB)\n",
> 		where, (void *)where, from, (void *)from);
> 
> Why did you want to force the "warn" log level?
> 

Thank you for your review. I think I'm wrong.

The checkpatch.pl script reports the "WARNING: printk() should
include KERN_<LEVEL> facility level" warning.

That's why I changed printk to pr_warn.
I should change printk to printk(KERN_DEFAULT).

>>  #else
>> -	printk("%s %ps from %pS\n", loglvl, (void *)where, (void *)from);
>> +	pr_warn("%s %ps from %pB\n", loglvl, (void *)where, (void *)from);
> 
> Ditto.
> 
> -Kees
>