| View previous topic :: View next topic |
| Author |
Message |
Exagon
n00b
Joined: 03 Apr 2017
Posts: 8
|
 Posted: Tue Apr 04, 2017 9:59 pm Post subject: GDB Adressen werden nicht aufgelöst unter Hardened Gentoo |
 |
|
Ich habe ein selbstgeschriebenes C++ Programm, welches nur unter meinem Hardened Gentoo crasht.
Entweder mit einem segmentation fault oder | Code: | | *** Error in `./Kyle': double free or corruption (fasttop): 0x00000000045a7b10 *** |
wenn ich das genau selbe Programm unter z.b. Arch Linux oder Ubuntu laufen lasse funktioniert alles wie es soll.
Auch Valgrind und scan-build finden nichts.
Soweit so schlecht  .
Wenn ich jetzt jedoch versuche das ganze zu debuggen mit gdb unter meinem Hardened Gentoo, bekomme ich nur folgendes Ergebniss bei einem backtrace:
| Code: |
(gdb) bt
#0 0x000003b3bca94e17 in ?? ()
#1 0x000003b3bca9636a in ?? ()
#2 0x0000000000000020 in ?? ()
#3 0x0000000000000000 in ?? ()
|
liegt das jetzt am hardened gentoo? Wie bekomme ich die debug-info in meinen gdb backtrace?
EDIT: Da ich das Programm nicht unter einem anderen Kernel zum Crash bekomme wäre es nett wenn Ihr mir helft das Programm irgendwie gedebuggt zu bekommen unter meinem Hardened Gentoo
Grüße Exagon
Last edited by Exagon on Wed Apr 05, 2017 7:43 pm; edited 1 time in total |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 05, 2017 4:52 pm Post subject: |
|
|
Die Frage ist sehr allgemein gehalten. Z.B. fehlen Informationen, wie das Program kompiliert wurde: Manuell lokal, unter Portage, mit welchen CFLAGS usw.
Mit Portage bekommst Du die debug-Informationen normalerweise durch | Code: | | FEATURES=nostrip CXXFLAGS="-O2 -g -ggdb3" LDFLAGS="" emerge -1O <package> |
Wenn der pax kernel etwas abschießt (z.B. Versuch in einen schreibgeschützten Bereich zu schreiben, falsches Leeren von Stack), sieht man den Grund dafür normalerweise in den System-Logs (dmesg).
valgrind und einige --sanitizer-Optionen laufen nicht (oder entdecken grundsätzlich nichts) unter einem pax Kernel, weil die dazu benötigten Überwachungs-Feature auch von bösartigen Programmen missbraucht werden könnten. Ganz konkret betrifft dies die Kernel-Optionen PAX_MPROTECT, PAX_KERNEXEC, PAX_RANDMMAP, PAX_RANDUSTACK, PAX_RAND_THREADSTACK, MEMORY_UDEREF, PAX_CONSTIFY_PLUGIN.
Dass Code mit einem Kernel läuft und nur mit einem anderen abstürzt ist durchaus normal und liegt i.d.R. an fehlerhaftem Code und nicht am Kernel: Es ist ja geradezu der Zweck des Pax-Kernels durch Randomisierung u.ä. den Code möglichst abstürzen zu lassen und eben nicht fehlerhaften Code "zufällig" funktionieren zu lassen.
Bei der beschriebenen Fehlermeldung würde ich auf einen falsche Behandlung von STL-Funktionen tippen: Vielleicht hast Du irgendwo übersehen, dass z.B. ein Hash oder Vector ev. automatisch neu allokiert und verschoben werden kann (Geraffel mit auto_ptr und/oder nicht korrekt überladene oder nicht gesperrte copy/move-Assignments/Constructors sind da beliebte Kandidaten.) Oder es wird ein STL-Container modifiziert ohne dabei zu beachten, dass irgendwelche Iteratoren dadurch invalide werden (möglicherweise ein aktueller impliziter Schleifen-Iterator). Die Zahl der Möglichkeiten ist natürlich nahezu unbegrenzt. |
|
| Back to top |
|
|
Exagon
n00b
Joined: 03 Apr 2017
Posts: 8
|
| Posted: Wed Apr 05, 2017 6:09 pm Post subject: Weitere infos |
|
|
Also das programm wurde lokal compilet mit Clang und der -g Option damit die Debug Symbole erhalten bleiben. Das der Absturz nicht am Kernel liegt sondern an meinem Programm ist mir klar, doch ich würde es gerne Debuggen um die Quelle zu finden.
Hch habs auch schon versucht mit mit
| Code: |
paxctl -c binary
paxctl -r binary
|
um die Debug Symbole in gdb zu erhalten.
Hat jedoch nicht zum Erfolg geführt.
Valgrind etc entdeckt auch nichts wenn ich es unter einem nicht gehärteten kernel ausführe.
Kann mir jemand helfen wie ich das Binary unter Hardened Gentoo debuggen kann?
EDIT: meine compile flags sind gerade: -std=c++1z -ferror-limit=2 -Wall -g
EDIT II: dmesg gibt nach dem Crash folgendes aus:
| Code: | denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /home/--ZENSIERT--/Projects/KyleBison/build/Kyle[Kyle:21747] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:6008] uid/euid:1000/1000 gid/egid:100/100
|
Ich denke mal dass das anzeigt das das Programm einen Core Dump schreiben wollte, grsec das aber nicht zugelassen hat. Ist die Annahme richtig?
EDIT III: Wenn ihr noch irgendwelche infos braucht dann liefer ich gerne alles einfach danach fragen, ich weis nicht was alles benötigt wird  |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Apr 06, 2017 7:26 pm Post subject: Re: Weitere infos |
|
|
| Exagon wrote: | | Also das programm wurde lokal compilet mit Clang und der -g Option damit die Debug Symbole erhalten bleiben. |
Das ist merkwürdig. Bei mir sind dann die Debug-Symbole da.
Es gab mal Versionen von gdb, die nicht mit Hardened-Kerneln oder bestimmten hardened-Optionen (war es -fstack-protector oder zurechtgekommen sind, aber das Problem wurde bereits vor etlichen Jahren entweder von Gentoo lokal oder gdb upstream gepatcht. Und clang setzt ja - anders als gcc mit USE=hardened - nicht per Default irgendwelche hardened-Optionen.
Es könnte natürlich sein, dass der Segfault irgendwo in der glibc auftritt und auf dem Stack zu diesem Zeitpunkt bereits nur Blödsinn steht: Die glibc hat vermutlich kein Debug-Symbole. |
|
| Back to top |
|
|
Exagon
n00b
Joined: 03 Apr 2017
Posts: 8
|
| Posted: Fri Apr 07, 2017 12:31 pm Post subject: Geschaft |
|
|
Also ich habs jetzt geschafft. Nach viel gegoogle habe ich in irgendeinem ArchLinux Forum den Hinweis gefunden, das ich folgendes auf das Binary ausführen sollte:
| Code: | | setfattr -n user.pax.flags -v "emr" binary |
Nachdem ich das gemacht habe, konnte ich das Programm ganz einfach mit gdb debuggen und die Symbole wurden auch angezeigt.
Wenn jemand weis woran das jetzt lag dann wäre es nett wenn er mir das erklären könnte.
Grüße Exagon |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3922
Location: Hamburg
|
| Posted: Fri Apr 07, 2017 6:05 pm Post subject: |
|
|
| Code: | | paxctl-ng -v -perms <foo> |
is your friend |
|
| Back to top |
|
|
|
Deutsches Forum (German)
