linux-kernel - Re: ORC unwinder and 'reliable' flag to printk_stack

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: <20170906222325.wvwb6dauqaxjlw4p@treble>
Date:   Wed, 6 Sep 2017 17:23:25 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: ORC unwinder and 'reliable' flag to printk_stack_address()

On Tue, Sep 05, 2017 at 03:15:12PM +0200, Jiri Kosina wrote:
> Hi Josh,
> 
> I just got the below stack trace with current Linus' tree with ORC 
> unwinder enabled:
> 
> 	[    8.652765] Call Trace:
> 	[    8.652767]  dump_stack+0x7c/0xbf
> 	[    8.652769]  print_circular_bug+0x2d3/0x2e0
> 	[    8.652771]  check_prev_add+0x666/0x700
> 	[    8.652772]  ? print_bfs_bug+0x40/0x40
> 	[    8.652775]  lock_commit_crosslock+0x3f1/0x570
> 	[    8.652777]  complete+0x24/0x60
> 	[    8.652779]  __kthread_parkme+0x42/0x90
> 	[    8.652780]  smpboot_thread_fn+0x92/0x210
> 	[    8.652782]  kthread+0x145/0x180
> 	[    8.652783]  ? sort_range+0x20/0x20
> 	[    8.652785]  ? kthread_create_on_node+0x40/0x40
> 	[    8.652787]  ret_from_fork+0x2a/0x40
> 
> Please note the kthread_create_on_node(), sort_range() and print_bfs_bug() 
> entries ... I believe they actually shouldn't be there at all. All of them 
> are at the last byte belonging to the function. Am I missing something?

The question marks are still supposed to be there.  They show any text
addresses found on the stack that weren't otherwise found by the
unwinder.  99.9% of the time, they're left over from a previous call
chain, and should be ignored.

They can be confusing, but IIRC, Linus wants to keep them because:

a) If the unwinder gets confused, they'll still be printed.

b) For some really sneaky bugs, it can give a few clues about what
   happened *before* the current trace.

Personally I've never seen (b), but (a) is definitely a good reason.

Note that while the "unreliable" addresses are shown for splats, they're
*not* reported by the unwinder for all its other uses like livepatch,
perf, /proc/<pid>/stack, etc.

-- 
Josh