## 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

- Antworten:
  - AW: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen
    - From: Jens Friedrich

- Referenzen:
  - AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen
    - From: Jens Friedrich

- Voriger (Datum): AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Niedermeier Günter
- Nächster (Datum): AW: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Jens Friedrich
- Voriger (Thread): AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Niedermeier Günter
- Nächster (Thread): AW: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Jens Friedrich
- Indizes:
  - Datum
  - Thread