linux-kernel - [PATCH 0/2] microblaze: add stack unwinder

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>] [day] [month] [year] [list]

Date:	Tue, 13 Apr 2010 23:53:46 -0500
From:	"Steven J. Magnani" <steve@...idescorp.com>
To:	microblaze-uclinux@...e.uq.edu.au, Michal Simek <monstr@...str.eu>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] microblaze: add stack unwinder

This has been baking for awhile, I think it's ready for prime time. I've
beat on it in a noMMU kernel for awhile - backtracetest module,
kmemleak, dump_stack() in a number of different situations - all look
good. Thanks to Paul Mundt for initial advice on this feature.

I don't have MMU hardware or the ability to build a MMU kernel, so all
I've done there is check for gross compile errors. The MMU kernel
handles kernel stacks differently, which isn't an issue except in the
trap handlers (interrupt, syscall, etc.). This patch should work for MMU
kernels, but they won't trace back beyond a system trap. The intent is
to provide hooks for someone to add that capability later.

The key feature of the design is a search backwards from each return
address for the instruction that creates a stack frame.
CONFIG_FRAME_POINTER causes Microblaze gcc to use r19 as a frame
pointer, but because previous frame pointers are not stored in a
consistent location within each frame, it's not possible to avoid some
sort of search to determine frame size. (Side note, since
-fno-omit-frame-pointer isn't useful for Microblaze, it would be nice if
Microblaze could "opt-out" of FRAME_POINTER when selecting
FUNCTION_TRACER).

A brute-force search was chosen over a kallsyms-assisted search (as used
in the sh architecture) to avoid going off the rails in cases where
kallsyms chooses the closest global address instead of the true (local)
function address. Obviously there's an accuracy/speed tradeoff, but
under an assumption that most functions are reasonably-sized and most
backtraces are not performed in time-critical paths, this should be OK.

Happy unwinding,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>

--
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/