linux-kernel - Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC

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]

Date:   Sun, 17 Dec 2017 21:37:49 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     mingo@...hat.com, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for
 ORC

On Thu, Dec 14, 2017 at 10:58:35PM +0100, Jiri Slaby wrote:
> On 11/30/2017, 08:57 PM, Josh Poimboeuf wrote:
> > So with those changes in mind, how about something like this (plus
> > comments)?
> > 
> > 	for (unwind_start(&state, task, NULL, NULL); !unwind_done(&state);
> > 	     unwind_next_frame(&state)) {
> > 
> > 		regs = unwind_get_entry_regs(&state);
> > 		if (regs) {
> > 			if (user_mode(regs))
> > 				goto success;
> > 
> > 			if (IS_ENABLED(CONFIG_FRAME_POINTER))
> > 				return -EINVAL;
> > 		}
> > 
> > 		addr = unwind_get_return_address(&state);
> > 		if (!addr)
> > 			return -EINVAL;
> > 
> > 		if (save_stack_address(trace, addr, false))
> > 			return -EINVAL;
> > 	}
> > 
> > 	return -EINVAL;
> 
> Kthreads and idle tasks hit this error as they have no user regs on the
> stack obviously :).

Doh, sorry, I forgot about that.

> 
> So making it:
>         if (!(task->flags & (PF_KTHREAD | PF_IDLE)))
>                 return -EINVAL;
> 
> works, but is not reliable now. So I believe, we cannot live without
> unwind->error to differentiate between "unwind_done() == true" because:
> * full stack unwound and the stack type is set to UNKNOWN
> * unwinding failed and the stack type is set to UNKNOWN
> 
> Or perhaps introduce stack type BOTTOM, NONE, or NOMORE meaning the
> bottom of the stacks reached?

Yeah, we'll need something... I need to think about it a little more.

-- 
Josh