Fehler beim neuen Kernel kompilieren
Hallo, ich habe ein USB-Gerät, das unter SuSE 8.2 nicht funktioniert, von Knoppix aber erkannt wird. Da ich die Knoppix-Module nicht unter SuSE nutzen kann (sie sind anders kopiliert) habe ich mir die Kernel-Quellen 2.4.20 bis 2.4.24 und 2.6.1 von kernel.org heruntergeladen um diese zu kompilieren. Ich habe also die heruntergeladenen Quellen nach z.B. /usr/src/linux-2.4.20 entpackt, meine /proc/config.gz ausgepackt und als .config kopiert, in diesen Verzeichnissen 'make oldconfig' 'make dep' 'make clean' 'make bzImage' 'make modules' und 'make modules_install' ausgeführt Leider klappt das mit keinem Kernel - auch nicht mit 2.4.20 (auf den ja auch die SuSE 8.2 aufbaut) und 2.4.24. Die Probleme sind bei allen Kerneln unterschiedlich: Mal bricht das Kompilieren des Kernels, mal das der Module an unterschiedlichen Stellen ab, mal geht ein make mudules_install schief. Den SuSE-Kernel und die Module hingegen kann ich kompilieren. Ich weiss, dass der SuSE-Kernel viele Patches aufweist, kann mir aber nicht vorstellen, dass dadurch irgendwie das Kompilieren anderer Kernel verhindert wird. Den gcc schliesse ich auch aus, denn die Version 3.3 hat mit den SuSE-Quellen keine Probleme, laut READMEs soll das alles ab gcc Version >= 2.95.3 klappen Hat jemand eine Glaskugel und kann mir sagen, warum meine Versuche nicht auf Anhieb funktionieren? Nein, mal im Ernst: Hat schonmal jemand einen Kernel 2.4.20 oder 2.4.24 von kernel.org kompiliert? Muss man dabei unter SuSE etwas besonderes beachten? Müssen irgendwelche Argumente an 'make' übergeben werden (warum?)? Oder klappt das eigentlich problemlos und ich habe einfach nur Pech, dass es bei mir nicht funktioniert? -- Gruß Bernd PGP Key: 1024/90F8BC35 FP: 9C 1F D1 8B BD D0 FA 62 BA D6 C7 C8 89 7D 5F E8
Hallo, Am Sun, 11 Jan 2004, Bernd Troszynski schrieb:
Leider klappt das mit keinem Kernel - auch nicht mit 2.4.20 (auf den ja auch die SuSE 8.2 aufbaut) und 2.4.24. Die Probleme sind bei allen Kerneln unterschiedlich: Mal bricht das Kompilieren des Kernels, mal das der Module an unterschiedlichen Stellen ab, mal geht ein make mudules_install schief. Den SuSE-Kernel und die Module hingegen kann ich kompilieren.
Leider verraetst du nicht mit _welchen_ Fehler abgebrochen wird... Aber ich rate mal: du bekommst 'signal 11' bzw. 'segmentation fault'? Dann ist aller Wahrscheinlichkeit nach dein RAM defekt. Such mal in der SDB nach 'segfault' oder 'signal 11'. -dnh -- Du willst einen Windows-PC als Gateway für ein NetBSD-System benutzen? Benutzt du auch Nägel, um einen Hammer in die Wand zu schlagen? (Philipp Schulte in de.org.ccc)
David Haller wrote:
[...] Leider verraetst du nicht mit _welchen_ Fehler abgebrochen wird... Aber ich rate mal: du bekommst 'signal 11' bzw. 'segmentation fault'? Dann ist aller Wahrscheinlichkeit nach dein RAM defekt. Such mal in der SDB nach 'segfault' oder 'signal 11'.
Haette ich jetzt auch vermutet. Vielleicht meintest Du auch http://www.bitwizard.nl/sig11/? Das sollte jedenfalls alle noetigen Infos beinhalten. CU, Thomson
am Sonntag, 11. Januar 2004 17:41 schrieb David Haller:
Leider klappt das mit keinem Kernel - auch nicht mit 2.4.20 (auf den ja auch die SuSE 8.2 aufbaut) und 2.4.24. Die Probleme sind bei allen Kerneln unterschiedlich: Mal bricht das Kompilieren des Kernels, mal das der Module an unterschiedlichen Stellen ab, mal geht ein make mudules_install schief. Den SuSE-Kernel und die Module hingegen kann ich kompilieren. Leider verraetst du nicht mit _welchen_ Fehler abgebrochen wird... Aber ich rate mal: du bekommst 'signal 11' bzw. 'segmentation fault'?
Nein, es sieht eigentlich eher nach einem Syntax-, make-Fehler o.ä. aus. Ich habe die .config des SuSE8.2-Kernels genommen und ein make oldconfig aufgerufen. Alle Komponenten, die ein 'm' zuliessen, haben das bekommen, alle anderen die Defaulteinstellung. Beim Kernel 2.4.20 (der von kernel.org) bricht 'make modules' so ab: ------------------------------------------------------------------------------------ horizon.c:2129: warning: comparison between signed and unsigned horizon.c: In function `atm_pcr_check': horizon.c:2147: warning: comparison between signed and unsigned horizon.c:2157: warning: comparison between signed and unsigned horizon.c: In function `hrz_check_args': horizon.c:2923: warning: comparison is always false due to limited range of data type horizon.c: At top level: /usr/src/linux-2.4.20/include/linux/module.h:299: warning: `__module_kernel_version' defined but not used horizon.c:2935: warning: `__module_license' defined but not used gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -g -nostdinc -iwithprefix include -DKBUILD_BASENAME=ambassador -c -o ambassador.o ambassador.c In file included from /usr/src/linux-2.4.20/include/linux/atmdev.h:212, from ambassador.c:31: /usr/src/linux-2.4.20/include/linux/skbuff.h: In function `__pskb_pull': /usr/src/linux-2.4.20/include/linux/skbuff.h:855: warning: comparison between signed and unsigned /usr/src/linux-2.4.20/include/linux/skbuff.h: In function `pskb_may_pull': /usr/src/linux-2.4.20/include/linux/skbuff.h:871: warning: comparison between signed and unsigned In file included from ambassador.c:31: /usr/src/linux-2.4.20/include/linux/atmdev.h: In function `atm_may_send': /usr/src/linux-2.4.20/include/linux/atmdev.h:450: warning: comparison between signed and unsigned ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token ambassador.c:305:23: pasting "." and "regions" does not give a valid preprocessing token ambassador.c:310:20: pasting "." and "data" does not give a valid preprocessing token ambassador.c: At top level: /usr/src/linux-2.4.20/include/linux/module.h:299: warning: `__module_kernel_version' defined but not used ambassador.c:2588: warning: `__module_license' defined but not used make[2]: *** [ambassador.o] Fehler 1 make[2]: Leaving directory `/usr/src/linux-2.4.20/drivers/atm' make[1]: *** [_modsubdir_atm] Fehler 2 make[1]: Leaving directory `/usr/src/linux-2.4.20/drivers' make: *** [_mod_drivers] Fehler 2 tux:/usr/src/linux-2.4.20 # ------------------------------------------------------------------------------------ Für den 2.4.24er Kernel habe ich die .config des obrigen 2.4.20er genommen und ein make oldconfig aufgerufen. Alle Komponenten, die ein 'm' zuliessen, haben das bekommen, alle anderen die Defaulteinstellung. Beim Kernel 2.4.24 (der von kernel.org) bricht das 'make modules' so ab: ------------------------------------------------------------------------------------ /usr/src/linux-2.4.24/include/linux/blkdev.h: In function `blk_queue_bounce': /usr/src/linux-2.4.24/include/linux/blkdev.h:192: warning: comparison between signed and unsigned /usr/src/linux-2.4.24/include/linux/blkdev.h: In function `blk_finished_sectors': /usr/src/linux-2.4.24/include/linux/blkdev.h:333: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_setup_tag_info_global': aic7xxx_osm.c:1614: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_setup_tag_info': aic7xxx_osm.c:1626: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_setup_dv': aic7xxx_osm.c:1639: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `aic7xxx_setup': aic7xxx_osm.c:1691: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_platform_abort_scbs': aic7xxx_osm.c:2168: warning: comparison between signed and unsigned aic7xxx_osm.c:2175: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_user_tagdepth': aic7xxx_osm.c:3560: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_user_dv_setting': aic7xxx_osm.c:3589: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_send_async': aic7xxx_osm.c:4092: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_done': aic7xxx_osm.c:4213: warning: comparison between signed and unsigned aic7xxx_osm.c: In function `ahc_linux_handle_scsi_status': aic7xxx_osm.c:4338: warning: comparison between signed and unsigned aic7xxx_osm.c: At top level: /usr/src/linux-2.4.24/include/linux/module.h:299: warning: `__module_kernel_version' defined but not used aic7xxx_osm.c:451: warning: `__module_license' defined but not used make[3]: *** [aic7xxx_osm.o] Fehler 1 make[3]: Leaving directory `/usr/src/linux-2.4.24/drivers/scsi/aic7xxx' make[2]: *** [_modsubdir_aic7xxx] Fehler 2 make[2]: Leaving directory `/usr/src/linux-2.4.24/drivers/scsi' make[1]: *** [_modsubdir_scsi] Fehler 2 make[1]: Leaving directory `/usr/src/linux-2.4.24/drivers' make: *** [_mod_drivers] Fehler 2 tux:/usr/src/linux-2.4.24 # ------------------------------------------------------------------------------------ Ich bin ein wenig verwundert, denn ich dachte, ein Orginalkernel kann in jedem Fall kompiliert werden wenn die Rahmenbedingungen (u.a. gcc-Version) stimmen. Besonders der Fehler beim 2.4.20 verwundert mich stark, denn darauf baut ja sie SuSE 8.2 auf. Deren Kernel und die Module kann ich hier problemlos erzeugen. -- Gruß Bernd PGP Key: 1024/90F8BC35 FP: 9C 1F D1 8B BD D0 FA 62 BA D6 C7 C8 89 7D 5F E8
Bernd Troszynski wrote:
[...] Nein, es sieht eigentlich eher nach einem Syntax-, make-Fehler o.ä. aus.
Ich habe die .config des SuSE8.2-Kernels genommen und ein make oldconfig aufgerufen. Alle Komponenten, die ein 'm' zuliessen, haben das bekommen, alle anderen die Defaulteinstellung.
Wenn Du einen eigenen Kernel compilierst, dann nimm besser die Sachen raus, die Du (definitiv) nicht brauchst, dann gibt es weniger Stellen, wo Fehler auftreten koennen. Der SuSE-Kernel hat quasi alle Kernel-Features aktiviert, und viele wirst Du davon wirklich nicht brauchen! Dann compiliert der Kernel wesentlich schneller, und potenzielle Konflikte sind eben vermindert. Ausserdem hat SuSE beim 2.4.x Kernel sehr viele Patches, die so manche Stelle im Kernelcode veraendert - wenn also etwas bei SuSE geht und bei Vanilla nicht (oder umgekehrt), dann ist das nicht unbedingt verwunderlich...
Beim Kernel 2.4.20 (der von kernel.org) bricht 'make modules' so ab:
Aktuell ist Kernel 2.4.24 - der 2.4.20 ist doch schon etwas aelter und koennte an Deinem Problem mit Schuld haben!
[...] ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token ambassador.c:305:23: pasting "." and "regions" does not give a valid preprocessing token ambassador.c:310:20: pasting "." and "data" does not give a valid preprocessing token ambassador.c: At top level:
Die anderen Sachen waren hpts. Warnungen, aber hier liegt das Problem. Dazu hat Philipp Thomas (allerdings in anderem Kontext) mal etwas geschrieben(*), ich denke, das koennte hier auch zutreffen: Der Code macht an der Stelle (und ein paar anderen) einfach Sachen, die laut dem ISO C Standard nicht definiert sind. Gcc 3.2 hat die noch mit Warnung akzeptiert, aber seit gcc 3.3 wird solcher Code zurückgewiesen. Verwende 2.4.22, da ist zumindest der Code gefixt oder deaktiviere einfach die ganze ATM Unterstützung, denn die wirst du sicherlich nicht benötigen. (*)http://marc.theaimsgroup.com/?l=suse-linux&m=106404826927837&w=2
Für den 2.4.24er Kernel habe ich die .config des obrigen 2.4.20er genommen und ein make oldconfig aufgerufen. Alle Komponenten, die ein 'm' zuliessen, haben das bekommen, alle anderen die Defaulteinstellung.
Beim Kernel 2.4.24 (der von kernel.org) bricht das 'make modules' so ab: [...]
Da habe ich jetzt nur Warnungen entdecken koennen, da hast Du glaube ich nicht genug Kontext gepostet, insbesondere fehlt der Compilerbefehl vorher. Oder ich habe etwas uebersehen.
Ich bin ein wenig verwundert, denn ich dachte, ein Orginalkernel kann in jedem Fall kompiliert werden wenn die Rahmenbedingungen (u.a. gcc-Version) stimmen. Besonders der Fehler beim 2.4.20 verwundert mich stark, denn darauf baut ja sie SuSE 8.2 auf. Deren Kernel und die Module kann ich hier problemlos erzeugen.
So allgemein kann man das nicht sagen. Der gcc 3.3 akzeptiert vielen unsauberen Code nicht mehr, den der gcc 2.95.3 z.B. noch akzeptierte. In vielen Softwarekomponenten gab es derartige Probleme, manches tritt eben auch beim Kernel zu Tage. Da ist in gewissen Faellen unsauber programmiert worden, und nicht alle derartigen "Bugs" sind bisher behoben. Ferner gilt obiger Hinweis zu den Unterschieden zwischen einem SuSE- und einem Vanilla-Kernel. Ich wuerde Dir raten, die Dinge, die Du definitiv nicht brauchst, bei der Konfiguration zu deaktivieren und dann das Ganze nochmal probieren. Fuer weitere Erklaerungsversuche, siehe auch den ganzen Thread von oben zitierter Email. Gruesse, Thomson
-----BEGIN PGP SIGNED MESSAGE----- am Montag, 12. Januar 2004 23:23 schrieb Thomas Hertweck:
Aktuell ist Kernel 2.4.24 - der 2.4.20 ist doch schon etwas aelter und koennte an Deinem Problem mit Schuld haben! Naja, eigentlich geht es mir ja nur um die USB-Module des 2.4.24 dei ich erstmal unter der SuSE 8.2 ausprobieren will. Da ich die aber nicht kompiliert bekommen habe, habe ich mich auf den 2.4.20 (aus dem SuSE 8.2 entstanden ist) gestürzt. Ich hatte gehofft, dass der ja wenigstens unter SuSE 8.2 kompilierbar sein sollte.
Der Code macht an der Stelle (und ein paar anderen) einfach Sachen, die laut dem ISO C Standard nicht definiert sind. Gcc 3.2 hat die noch mit Warnung akzeptiert, aber seit gcc 3.3 wird solcher Code zurückgewiesen. Verwende 2.4.22, da ist zumindest der Code gefixt oder deaktiviere einfach die ganze ATM Unterstützung, denn die wirst du sicherlich nicht benötigen. Ich denke, ich hole mir einfach den gcc 3.2. Dann sollte es ja wohl gehen, oder?
Ich wuerde Dir raten, die Dinge, die Du definitiv nicht brauchst, bei der Konfiguration zu deaktivieren und dann das Ganze nochmal probieren. Fuer weitere Erklaerungsversuche, siehe auch den ganzen Thread von oben zitierter Email. War aufschlussreich. Danke
Gruß Bernd PGP Key: 1024/90F8BC35 FP: 9C 1F D1 8B BD D0 FA 62 BA D6 C7 C8 89 7D 5F E8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iQCVAwUBQARHbsZ2vdaQ+Lw1AQGLjAP5ASaaOk/1IlWV4ePJGG2GAc6hX7RDI9+C d46Q8EZ/UQIFbCuADy/+bdGtRDEegQrNG7khtOSLOzbv2dKfWfinf3YQV+QxEcWX XNLxBsjUD5OnMAuAyRM/qR/mJsYm9dvZA2BMCsj5h7d1yneuI4DU8TKIfT/rgJiQ DzYk8lx9Usg= =0LsY -----END PGP SIGNATURE-----
Bernd Troszynski wrote:
[...] Ich denke, ich hole mir einfach den gcc 3.2. Dann sollte es ja wohl gehen, oder?
Du kannst nicht einfach den Default-Compiler der Distribution ersetzen. Du muesstest also den Compiler parallel installieren. Und Du muesstest Anpassungen machen am Kernel-Makefile etc. Halte ich generell fuer keine so gute Idee. Wie schon gesagt, ich kann's nur wiederholen: Schalte doch erst einmal saemtliche Features des Kernels ab, die Du nicht brauchst. Vielleicht geht es dann ja schon. Die "gaengigen" Module weisen eigentlich selten Compilierprobleme auf, oft treten diese nur bei etwas exotischeren Sachen auf... CU, Thomson
Am Dienstag, 13. Januar 2004 20:30 schrieb Bernd Troszynski:
am Montag, 12. Januar 2004 23:23 schrieb Thomas Hertweck:
Aktuell ist Kernel 2.4.24 - der 2.4.20 ist doch schon etwas aelter und koennte an Deinem Problem mit Schuld haben!
Naja, eigentlich geht es mir ja nur um die USB-Module des 2.4.24 dei ich erstmal unter der SuSE 8.2 ausprobieren will. Da ich die aber
Geht hier einwandfrei, die Patches, die ich reingepackt habe (alsa 1.0.1, i2c + lm_sensors 2.8.2, /proc/config.gz und die ck1 Patches) gibts wie immer unter ftp://packman.iu-bremen.de/testing/manfreds_kernelpatches
nicht kompiliert bekommen habe, habe ich mich auf den 2.4.20 (aus dem SuSE 8.2 entstanden ist) gestürzt. Ich hatte gehofft, dass der ja wenigstens unter SuSE 8.2 kompilierbar sein sollte.
Du weisst, dass Du Dir mit nem <= 2.4.23er Vanilla Kernel Sicherheitslücken ins Haus holst, mit nem 2.4.20er sogar mehrere.
Ich denke, ich hole mir einfach den gcc 3.2. Dann sollte es ja wohl gehen, oder?
Der 3.3er sollte es einwandfrei tun, schnapp Dir das Update auf 3.3.1 von SuSE: ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/projects/gcc/8.2 -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo, Am Wed, 14 Jan 2004, Manfred Tremmel schrieb:
Du weisst, dass Du Dir mit nem <= 2.4.23er Vanilla Kernel Sicherheitslücken ins Haus holst, mit nem 2.4.20er sogar mehrere.
Welche ausser do_brk() und do_mremap()? Die hab ich mir jetzt naemlich gefixt. Mein Kernel? 2.4.16 :) -dn'*scnr*'h, mit dank an Olaf u.a. -- Top 100 things you don't want the sysadmin to say: 47. Say, What does "Superblock Error" mean, anyhow?
Am Mittwoch, 14. Januar 2004 23:42 schrieb David Haller:
Welche ausser do_brk() und do_mremap()?
Die hab ich mir jetzt naemlich gefixt. Mein Kernel? 2.4.16 :)
Warum verwendest du einen so alten Kernel? Daran, dass du nicht Kernel kompilieren kannst, kann es ja nicht liegen :-) Al
Hallo, Am Thu, 15 Jan 2004, Al Bogner schrieb:
Am Mittwoch, 14. Januar 2004 23:42 schrieb David Haller:
Welche ausser do_brk() und do_mremap()?
Die hab ich mir jetzt naemlich gefixt. Mein Kernel? 2.4.16 :)
Warum verwendest du einen so alten Kernel? Daran, dass du nicht Kernel kompilieren kannst, kann es ja nicht liegen :-)
Keine Lust fuer 2.4.x noch gross was zu machen, und die fuer 2.6.x
noetigen Updates hab ich halt noch nicht fertig...
Da ist's einfacher, mal eben die 2 Dateien[1] zu patchen, und den
Kernel mit der jahrelang bewaehrten .config zu rekompilieren...
dh@slarty[4]: ~ (0)$ uname -r
2.4.16-3
dh@slarty[4]: ~ (0)$ l /boot/bzImage-`uname -r | cut -d- -f1`* | cut -b34-
1030080 Dec 14 2001 /boot/bzImage-2.4.16-1
[..]
1010248 Nov 30 2002 /boot/bzImage-2.4.16-3
918425 Mar 24 2003 /boot/bzImage-2.4.16-4
989788 Jan 11 17:42 /boot/bzImage-2.4.16-5
Den -5er muss ich aber noch testen, neben den sec-fixes hab ich da
auch noch die config gesaeubert (wie man auch an der Dateigroesse
sieht)... Den -4er hab ich nie verwendet, das war eh nur ne
"config-aufraeum"-Version.
Wenn 2.6.x aber nicht komplett mit meiner HW kann (und das ist
durchaus moeglich, z.B. hab ich damals meine Soundkarte nicht mit ALSA
zum Toenen bekommen, und nochwas anderes, das ich brauche faellt IIRC
raus), dann bleibe ich auch langfristig bei 2.4.x, werde mir dann aber
evtl. noch ein Update auf 2.4.<current> goennen.
-dnh
[1] Bis auf die Zeilennummern sollte das meist passen. Die Patches
sind aber nicht verifiziert und ich hab die Logik nicht komplett
nachvollzogen.
==== do_brk_do_mremap_2.4.16-fix.diff ====
--- mm/mmap.c~ Sun Nov 4 19:17:20 2001
+++ mm/mmap.c Sun Jan 11 15:49:51 2004
@@ -1014,6 +1014,13 @@
if (!len)
return addr;
+ /* fix for do_brk() bug http://www.securityfocus.com/bid/9138 */
+ if ((addr + len) > TASK_SIZE || (addr + len) < addr) {
+ printk("caught do_brk exploit!!!\n");
+ return -EINVAL;
+ }
+ /* end fix do_brk() */
+
/*
* mlock MCL_FUTURE?
*/
--- mm/mremap.c~ Fri Sep 21 05:31:26 2001
+++ mm/mremap.c Sun Jan 11 17:10:53 2004
@@ -237,6 +237,16 @@
if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_len)
goto out;
+ /* fix for do_mremap(). From
Am Mittwoch, 14. Januar 2004 23:42 schrieb David Haller:
Hallo,
Am Wed, 14 Jan 2004, Manfred Tremmel schrieb:
Du weisst, dass Du Dir mit nem <= 2.4.23er Vanilla Kernel Sicherheitslücken ins Haus holst, mit nem 2.4.20er sogar mehrere.
Welche ausser do_brk() und do_mremap()?
Na, reichen die beiden nicht? Die Sache ist halt noch die, dass eventuell andere gefixed Fehler auch noch Sicherheitspotential haben könnten, die nur noch nicht erkannt wurden.
Die hab ich mir jetzt naemlich gefixt. Mein Kernel? 2.4.16 :)
Dann ist ja gut ;-) Die Frage ist nur, was macht mehr arbeit, den alten Source zu patchen, oder nen neuen Kernel zu compilieren. Gut, ne DSL-Flat ist letzterer Methode schon förderlich ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo, Am Thu, 15 Jan 2004, Manfred Tremmel schrieb:
Am Mittwoch, 14. Januar 2004 23:42 schrieb David Haller:
Am Wed, 14 Jan 2004, Manfred Tremmel schrieb:
Du weisst, dass Du Dir mit nem <= 2.4.23er Vanilla Kernel Sicherheitslücken ins Haus holst, mit nem 2.4.20er sogar mehrere.
Welche ausser do_brk() und do_mremap()?
Na, reichen die beiden nicht?
Doch klar. Sind aber bei mir nicht wirklich "dringend", da lokale exploits und da ich der einzige lokale user bin... :) Aber klar, man "fixt" sowas so bald wie moeglich :)
Die Sache ist halt noch die, dass eventuell andere gefixed Fehler auch noch Sicherheitspotential haben könnten, die nur noch nicht erkannt wurden.
ACK. Ich empfehle auch _niemanden_, so einen "alten" 2.4.16er Kernel einzusetzen (obwohl der bei mir soo stabil laeuft ;). Aber wenn ich mit ein paar Zeilen (6 Zeilen Code insgesamt) das fixen kann? Dann bau ich das "mal eben" ein. Und _ich_ weiss, was ich damit ggfs. riskiere. Zumal ich sowieso schon selbst mehr an dem Kernel rumgepatcht habe (selbst wenn man patches an den Makefiles ignoriert). Was ich eigentlich sagen wollte, war, dass, falls hier jemand Gruende hat, nen nicht-aktuellen Kernel zu verwenden, dass man auch diesen einfach zumindest gegen diese beiden Exploits patchen kann (siehe auch meine Mail nebenan). Man muss nicht unbedingt gleich 2.4.23 verwenden, um diese beiden Luecken zu stopfen. Nennt man "Backport" sowas, und sowas macht SuSE ja staendig und zu Recht. ;)
Die hab ich mir jetzt naemlich gefixt. Mein Kernel? 2.4.16 :)
Dann ist ja gut ;-) Die Frage ist nur, was macht mehr arbeit, den alten Source zu patchen, oder nen neuen Kernel zu compilieren. Gut, ne DSL-Flat ist letzterer Methode schon förderlich ;-)
Du, ich hab hier sogar schon nen 2.4.23 tarball, aber meinen 2.4.16er zu patchen war dennoch (fuer mich!) deutlich weniger Arbeit :) Diese "Arbeit" will ich mir erst fuer nen 2.6er machen[1], da will ich mir nicht noch extra Arbeit fuer nen 2.4er Update machen[2]... Das Neukompilieren war eh faellig, um unnoetigen Ballast (mit potentiellen Sicherheitsluecken *g*) loszuwerden, und da "mal eben" die beiden Fixes einzubauen, das war _fuer mich_ einfach und schmerzlos. Getestet hab ich den gefixten und abgespeckten Kernel uebrigens immer noch nicht, so wenig "wichtig" ist mir das eigentlich. Mach ich morgen, wenn ich beim Lilo dran denke und nicht einfach auf "Return" druecke bzw. den Timeout abwarte ;) Naja, mein System ist ja sowieso inzwischen in so grossen Teilen "Eigenbau"... Aber ich bilde mir ein zu wissen, was ich da riskiere ;) Zumal da sowieso z.B. noch ein uralter, "bugridden" sendmail-8.9.3 auf Port 25 lauscht... Der ist das viel groessere Risiko, den sollte ich noch eher updaten, was auch geplant ist, aber da vertrau ich z.Z. einfach mal auf meine FW (und meine sendmail-Einstellungen), die nach aussen den Port 25 schlicht dicht macht (bzw. die connects nur von localhost (i.e. fetchmail, mutt, mail usw.) annehmen). *g* Und da ich trotz DSL-flat fast nur so online bin, als haette ich nur ein analog-Modem mit nem teuren Zeittarif, sehe ich die Risiken als kalkulierbar an, zumal meine FW dicht sein muesste ;) Aber vielen Dank fuer deine "Besorgnis"/Anteilnahme :) -dnh PS: wg. mir koennen wir meine FW gerne mal testen ;) Sach mir vorher Bescheid damit ich dir meine IP mailen kann... [1] bin schon dabei, aber z.Z. gibt's wichtigeres. [2] falls sich aber heraustellt, dass z.B. meine Soundkarten unter 2.6 nicht mehr laeuft, und ich dann erstmal bei 2.4 bleibe, dann natuerlich schon. Dann gibt's auch nen 2.4.2x (oder was dann eben aktuell ist). -- / "The way to a man's heart is through his stomach, that way you \ \ don't get your knife caught in his ribs..." -- Peter da Silva / -- stolen off of AdB
participants (5)
-
Al Bogner -
Bernd Troszynski -
David Haller -
Manfred Tremmel -
Thomas Hertweck