c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

AW: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen

Absender: Jens Friedrich
Datum: Di, 20.12.2005 23:29:21
In-reply-to: <Pine.LNX.4.58.0512202147000.14583@xxxxxxxxxxxxxxxxxxxx>


Mir geht's mehr um die -fstack-protector option des gcc, die ist im LFS ja
extra eingebaut - und wir schalten die aus?
Ich find die Idee dieses Patches / der Option gut...

Den propolice-patch...ok - den könne ma rauslasse... ;-)
Sehe ich auch so.

Zum Thema Stacks schützen + FW hat dann schon versagt: JEIN  ;-)
Wenn die FW nen Stack-Overflow evtl. abfängt (statt zu "halt"en oder
"core"en oder so)
und stattdessen weiterläuft trägt das nicht zur UML-IPCop Stabilität bei?

Und was ist mit den ganzen AddOns, die teilweise installiert werden?
OK - die laufen evtl. im Userspace... Aber nicht alle, oder (QoS?!)
Die würden unter obiger Annahme evtl. auch nicht gleich zu einem Abbruch
führen... (??)

Wenn mein umlipcop1.4.10-vc1.patch läuft, wird ich mal den TT-MODE
rausnehmen, und
schauen was passiert... Oder hat's schon jemand getestet?

Viele Grüsse
Jens
 

> -----Ursprüngliche Nachricht-----
> Von: ctsrvdev-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:ctsrvdev-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von 
> Peter Siering
> Gesendet: Dienstag, 20. Dezember 2005 22:25
> An: Entwicklung rund um den c't Server
> Betreff: Re: AW: AW: [ctsrvdev] Ipcop innerhalb der 
> ipcop-umgebung bauen
> 
> 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.htm
> l 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
> 
> _______________________________________________
> ctsrvdev Mailingliste
> ctsrvdev@xxxxxxxxxxxxxxxxx
> http://www.heise.de/bin/newsletter/listinfo/ctsrvdev
>