Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GDB Adressen werden nicht aufgelöst unter Hardened Gentoo
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
Exagon
n00b
n00b


Joined: 03 Apr 2017
Posts: 3

PostPosted: Tue Apr 04, 2017 9:59 pm    Post subject: GDB Adressen werden nicht aufgelöst unter Hardened Gentoo Reply with quote

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 8O.
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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5623

PostPosted: Wed Apr 05, 2017 4:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
Exagon
n00b
n00b


Joined: 03 Apr 2017
Posts: 3

PostPosted: Wed Apr 05, 2017 6:09 pm    Post subject: Weitere infos Reply with quote

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 :oops:
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5623

PostPosted: Thu Apr 06, 2017 7:26 pm    Post subject: Re: Weitere infos Reply with quote

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
View user's profile Send private message
Exagon
n00b
n00b


Joined: 03 Apr 2017
Posts: 3

PostPosted: Fri Apr 07, 2017 12:31 pm    Post subject: Geschaft Reply with quote

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
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3431
Location: Hamburg

PostPosted: Fri Apr 07, 2017 6:05 pm    Post subject: Reply with quote

Code:
paxctl-ng -v -perms <foo>
is your friend
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum