c't

c't-Projekte - Mailinglisten


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

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

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