linux-kernel - Re: Fault Injection issues: stacktrace x86

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: <20070421221033.GA30496@one.firstfloor.org>
Date:	Sun, 22 Apr 2007 00:10:33 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Scott Porter <scott@...ngridcomputing.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Akinobu Mita <Akinobu.Mita@...il.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: Fault Injection issues: stacktrace x86_64 and failslab NUMA

> There is no FRAME_POINTER support in the x86_64 code.  Apparently it was
> removed when the unwind code was added but now that has been removed as
> well!

That's because no assembly code in x86-64 knows anything about frame pointers.
You will always get truncated traces if anything assembler is in trace.
That's just dangerous.

> Digging around in the archives it looks like Andi Kleen knew this was an
> issue with the x86_64 fallback stacktrace code.  Now that there is no

No I didn't.

> unwind code to even attempt to avoid the problem what should be done?
> How about:
> 
> (1) Make it clear the Fault Injection with STACKTRACE on x86_64 is at
> best "Russian Roulette" -- maybe a !X86_64 in Kconfig.debug?
> 
> (2) Introduce FRAME_POINTER support back into the x86_64 code.  This is
> what Fault Injection really wants.
> 
> (3) Keep the saved stack address entries array out of sight of the
> fallback save_stack_trace() code.  Lockdep does this by storing it in
> static space but this requires locking which would be ugly for Fault
> Injection.  Another option is to mask the saved addresses so they fail
> the __kernel_text_address() test but fail_stacktrace() uses the same
> mask to make it's comparisons.  There's still the problem of avoiding
> kernel text addresses stored on the stack by other code (that is, other
> than the expected stack chain uses).

Some hack in (3) would be probably best, otherwise (1).
At some point I hope we can get the dwarf2 unwinder back, then
the problem should be also solved. But then you would need to force
the dwarf2 unwinder with fault injection on, but that shouldn't
be a problem.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/