linux-kernel - Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

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:   Wed, 12 Jul 2017 10:27:10 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Mike Galbraith <efault@....de>
Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)


* Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> The biggest change is that undwarf was renamed to ORC.  Here's the
> relevant explanation from the docs:
> 
>   Etymology
>   ---------
>   
>   Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural
>   enemies.  Similarly, the ORC unwinder was created in opposition to the
>   complexity and slowness of DWARF.
>   
>   "Although Orcs rarely consider multiple solutions to a problem, they do
>   excel at getting things done because they are creatures of action, not
>   thought." [3]  Similarly, unlike the esoteric DWARF unwinder, the
>   veracious ORC unwinder wastes no time or siloconic effort decoding
>   variable-length zero-extended unsigned-integer byte-coded
>   state-machine-based debug information entries.
>   
>   Similar to how Orcs frequently unravel the well-intentioned plans of
>   their adversaries, the ORC unwinder frequently unravels stacks with
>   brutal, unyielding efficiency.
>   
>   ORC stands for Oops Rewind Capability.

Perfect naming!

(ORC might also stand for "Optimized Rewind Capability".)

> Create a new "ORC" unwinder, enabled by CONFIG_ORC_UNWINDER, and plug it
> into the x86 unwinder framework.  Objtool is used to generate the ORC
> debuginfo.  The ORC debuginfo format is basically a simplified version
> of DWARF CFI.  More details below.

BTW., we should perhaps consolidate our unwinder related Kconfig space, 
hierarchically:

	CONFIG_UNWINDER
	CONFIG_UNWINDER_ORC
	CONFIG_UNWINDER_FRAME_POINTERS

Note that as a side effect it would be a valid small systems build option to have 
no unwinder at all, if CONFIG_EXPERT=y is set and such: !CONFIG_UNWINDER=n would 
be a sibling to !CONFIG_BUG.

CONFIG_FRAME_POINTERS et al would be left for architectures where it has a meaning 
beyond backtrace generation. (Not sure whether there's any such architectures.)

> The unwinder works well in my testing.  It unwinds through interrupts,
> exceptions, and preemption, with and without frame pointers, across
> aligned stacks and dynamically allocated stacks.  If something goes
> wrong during an oops, it successfully falls back to printing the '?'
> entries just like the frame pointer unwinder.

Ok, I'll start applying your patches after -rc1, unless anyone objects.

> The ORC data format does have a few downsides compared to DWARF.  The
> ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.

Could we also write this in percentage, not absolute RAM size - i.e. ORC unwind 
tables take 30% more RAM (+0.7 MB on an x86 defconfig kernel) than DWARF eh_frame 
tables.

Thanks,

	Ingo