Absender: Peter Siering
Datum: Di, 20.12.2005 22:22:22
In-reply-to:
<000801c60595$a1b864c0$0801a8c0@Nia>
References:
<000801c60595$a1b864c0$0801a8c0@Nia>
Hallo, On Tue, 20 Dec 2005, Jens Friedrich wrote: > Also, Peters Methode innerhalb der ipcop-LFS habe ich jetzt mit > Ipcop-1.4.10 am laufen...(besser gesagt kompiliert, ausprobiert hab ich das > Ding nämlich noch nicht...) > > Allerdings mit den beschriebenen Hack's > (Propolice raus, und -fno-stack-protector-all Option). > > Das mit dem Propolice-Patch wird also nur ausserhalb der LFS-Umgebung > gehen, keine Ahnung wo man da drehen müsste :-( > Mir ist ein weiterer Zusammenhang aufgefallen, den ich hier noch mal explizit erwähnen möchte: Der Fehler beim Übersetzen tritt (nur?) dann auf, wenn der IPCop/UML-Kernel statisch gebunden wird -- das ist beim Aktivieren des tt-Modes der Fall. Den tt-Mode habe ich erst mit 1.4.6 (c't-Server 1.1) aktiviert, um ein statisches Binary des IPCop-UML-Kernel zu bekommen. Die eigentliche dafür vorgesehen UML-Option hatte damals macken, sodass die UML-Entwickler zu tt-Mode rieten. Die Version 1.4.2 kam noch ohne tt-Mode aus und hatte entsprechend den Stack-Protection-Kram drin. > Peter meint ja, das damit der Kernel näher am IPCop-kernel ist. Das ist ein Streit um des Kaisers Bart, wenn ich 180 KByte komprimierten Patch in den Kernel einspiele ;-) > Ich meine das nicht - ich denke das mit der Stack-Protection ein > Firewall-Kernel besser ist, auch wen ich den ausserhalb der LFS > Kompiliere. > Habt Ihr den Hinweis auf den lkml-Thread zu propolice mal verfolgt? (http://www.ussg.iu.edu/hypermail/linux/kernel/0501.1/1789.html wie in http://www.heise.de/ct/ftp/projekte/srv/srcdoc/ipcop.shtml erwähnt) Ich denke, das Firewall-Kernel hier als Argument kaum zählen kann: Wenn ich erst die Stacks auf meiner Firewall schützen muss, hat sie doch schon versagt oder ;-? > Wer bietet mehr? Wichtig ist Reproduzierbarkeit: Die ist bei der Integration in die IPCop-Buildumgebung gegeben. Und: Die Aussicht, dass die IPCop-Entwickler die Änderungen übernehmen, ist größer. Wenn ich den IPCop-UML-Kernel aber im Wirtssystem übersetze, dann ist das für meinen Eindruck kaum reproduzierbar, selbst wenn man Sarge als Basis festschreiben würde, von anderen Distributionen muss man wohl nicht reden ... Könnt Ihr sicher sein, dass der Kernel für den Schutz der Stacks nicht mit einem geeignet gepatchten Compiler zu übersetzen ist? In der LFS-Umgebung läuft - zumindest auf den ersten Blick - ein gepatchter gcc - womöglich bleibt der ganze Schutz beim Übersetzen mit dem Wirts-gcc auf der Strecke? Peter