2.4.22-rc2-grsec: [shmem.o] Error 1
Welche Kerneloption ist von u.a. Fehler betroffen. Die 2.4.20 Sourcen wurde wie folgt gepatcht: zuerst patch -p1 < /usr/src/packages/SOURCES/kernel/grsecurity-1.9.11-2.4.21.patch dann gunzip -c /usr/src/packages/SOURCES/kernel/patch-2.4.22-rc2.gz | patch -p1 Ist in 2.4.22-rc2 bereits linux-2.4.20_ippp-filter.diff integriert? gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-rc2-grsec/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=numa -c -o numa.o numa.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-rc2-grsec/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=oom_kill -c -o oom_kill.o oom_kill.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-rc2-grsec/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=shmem -DEXPORT_SYMTAB -c shmem.c In file included from shmem.c:27: /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h: In function `fcheck_files': /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h:36: warning: comparison between signed and unsigned /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h: In function `fcheck': /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h:49: warning: comparison between signed and unsigned /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h: In function `__put_unused_fd': /usr/src/linux-2.4.22-rc2-grsec/include/linux/file.h:61: warning: comparison between signed and unsigned shmem.c: In function `shmem_unuse_inode': shmem.c:461: warning: comparison between signed and unsigned shmem.c: In function `shmem_file_write': shmem.c:960: error: `limit' undeclared (first use in this function) shmem.c:960: error: (Each undeclared identifier is reported only once shmem.c:960: error: for each function it appears in.) shmem.c:973: error: `status' undeclared (first use in this function) shmem.c:1005: error: `info' undeclared (first use in this function) shmem.c:1007: error: `page' undeclared (first use in this function) shmem.c:1007: warning: implicit declaration of function `shmem_getpage_locked' shmem.c: In function `shmem_symlink': shmem.c:1334: warning: comparison between signed and unsigned shmem.c:1343: warning: comparison between signed and unsigned shmem.c: In function `shmem_file_setup': shmem.c:1671: warning: comparison between signed and unsigned make[2]: *** [shmem.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.22-rc2-grsec/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.22-rc2-grsec/mm' make: *** [_dir_mm] Error 2
Al Bogner schrieb:
Welche Kerneloption ist von u.a. Fehler betroffen. Die 2.4.20 Sourcen wurde wie folgt gepatcht:
zuerst patch -p1 < /usr/src/packages/SOURCES/kernel/grsecurity-1.9.11-2.4.21.patch dann gunzip -c /usr/src/packages/SOURCES/kernel/patch-2.4.22-rc2.gz | patch -p1 [...]
Lass mich mal zusammenfassen: Du hast die Vanilla-Kernelquellen 2.4.20 mit einem Patch grsecurity-1.9.11, der fuer Vanilla-Kernel 2.4.21 (siehe Name der Datei) erstellt wurde, gepatcht. Das passt schon mal nicht 100%! Anschliessend hast Du die so erhaltenen Kernelquellen mit dem Patch patch-2.4.22-rc2, der eigentlich auf einen Vanilla- Kernel 2.4.21 anzuwenden ist, weiter gepatcht. Das passt wieder nicht 100%! Und ich bin mir sicher, dass es Fehlermeldungen oder zumindest Warnungen gegeben hat oder auch der ein oder andere Patch-Versuch bei einer Datei schief lief - wenn nicht, wuerde mich das schwer wundern, zumindest wenn es tatsaechlich so ist, wie Du hier geschrieben hast. Dass es danach zu Problemen beim Compilieren kommt, ist so gesehen dann nicht verwunderlich, oder? Jedenfalls nicht fuer mich:-) Wenn man solche Patch-Orgien macht und Patches anwendet, die nicht 100% passen, dann muss man schon genau wissen, was man da tut, sonst wird es nicht funktionieren oder man macht sogar mehr kaputt... Lies uebrigens mal das Kernel Changelog, da werden sicher so manche Fragen von Dir beantwortet, ob dies oder jenes schon enthalten ist. Gruesse, Th.
Am Freitag, 15. August 2003 12:14 schrieb Thomas Hertweck:
Du hast die Vanilla-Kernelquellen 2.4.20 mit einem Patch grsecurity-1.9.11, der fuer Vanilla-Kernel 2.4.21 (siehe Name der Datei) erstellt wurde, gepatcht. Das passt schon mal nicht 100%!
Sorry, da habe ich was falsches geschrieben. Wird mal Zeit, dass auf jedem Rechner die gleiche Kernelversion läuft. :-) Es war schon der 2.4.21: linux-2.4.21.tar.gz zu dem offiziell patch-2.4.22-rc2.gz passen soll. Wirkliche Fehlermeldungen gab es beim Patchen nicht. linux-2.4.21.tar.gz mit grsecurity-1.9.11-2.4.21.patch läuft ohne jegliche Probleme und bei patch-2.4.22-rc2.gz gibt es dann nur Meldungen, dass die Zeilen verschoben sind. Patcht man linux-2.4.21.tar.gz -> patch-2.4.22-rc2.gz -> grsecurity-1.9.11-2.4.21.patch dann gibt es schon Fehlermeldungen.
mich das schwer wundern, zumindest wenn es tatsaechlich so ist, wie Du hier geschrieben hast.
Sorry nochmals für die Falschinformation. Bei 2.4.20 sehe ich das voll ein, aber so was würde ich nicht machen, da habe ich von Kernelpatches zu wenig Ahnung. Ich vermute mal, dass der grsec-Patch nichts mit dem [shmem.o] Error 1 zu tun hat. Weisst du welche Kernel-Option betroffen ist?
Lies uebrigens mal das Kernel Changelog, da werden sicher so manche Fragen von Dir beantwortet, ob dies oder jenes schon enthalten ist.
Das lese ich, wobei mir aber nicht immer klar ist, ob das mein System auch wirklich trifft. Der Grund für diesen Patch gegenüber dem 2.4.21-grsec ist, dass es in letzter Zeit doch einige Kernelsicherheitsupdates gab und mir zuwenig klar ist, ob es zwischen 2.4.21 und 2.4.22-rc2 große Sicherheitsunterschiede gibt. Al
Al Bogner schrieb:
[...] Wirkliche Fehlermeldungen gab es beim Patchen nicht. linux-2.4.21.tar.gz mit grsecurity-1.9.11-2.4.21.patch läuft ohne jegliche Probleme und bei patch-2.4.22-rc2.gz gibt es dann nur Meldungen, dass die Zeilen verschoben sind. [...]
Falsch! Ich habe das gerade ausprobiert, weil ich es einfach nicht glauben konnte. Zuerst Vanilla-Kernel 2.4.21 entpackt, dann den Patch grsecurity-1.9.11-2.4.21.patch angewandt (ohne Fehler), dann den Patch patch-2.4.22-rc2.gz angewandt ueber $> gunzip -c patch-2.4.22-rc2.gz | patch -p1 2>&1 | tee patch.log Und siehe da, ein anschliessendes $> grep -i failed patch.log liefert. Hunk #1 FAILED at 1. Hunk #3 FAILED at 128. 2 out of 6 hunks FAILED -- saving rejects to file Makefile.rej Hunk #1 FAILED at 373. 1 out of 1 hunk FAILED -- saving rejects to file arch/i386/kernel/i387.c.rej Hunk #3 FAILED at 181. 1 out of 4 hunks FAILED -- saving rejects to file arch/ppc/kernel/syscalls.c.rej Hunk #1 FAILED at 444. 1 out of 5 hunks FAILED -- saving rejects to file fs/binfmt_elf.c.rej Hunk #2 FAILED at 308. Hunk #3 FAILED at 347. 2 out of 5 hunks FAILED -- saving rejects to file fs/exec.c.rej Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file include/asm-ppc/a.out.h.rej Hunk #1 FAILED at 104. 1 out of 2 hunks FAILED -- saving rejects to file include/linux/mm.h.rej Hunk #1 FAILED at 125. 1 out of 3 hunks FAILED -- saving rejects to file include/linux/sysctl.h.rej Hunk #1 FAILED at 62. 1 out of 9 hunks FAILED -- saving rejects to file ipc/sem.c.rej Hunk #1 FAILED at 48. Hunk #6 FAILED at 593. 2 out of 6 hunks FAILED -- saving rejects to file kernel/ksyms.c.rej Hunk #2 FAILED at 191. 1 out of 2 hunks FAILED -- saving rejects to file mm/mremap.c.rej Hunk #18 FAILED at 938. 1 out of 42 hunks FAILED -- saving rejects to file mm/shmem.c.rej Hunk #3 FAILED at 486. 1 out of 3 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej Ich weiss ja nicht, was Du gemacht hast oder gesehen hast, aber bei mir _sind_ das Fehler und nicht nur Meldungen, dass es Offsets gab beim Patchen... Insbesondere gibt es auch einen Fehler in mm/shmem.c beim Patchen, und da entsteht spaeter bei Dir auch der Fehler beim Compilieren. Ich wuerde sagen, Du bist da etwas arg oberflaechlich an die Sache rangegangen. Mit etwas Glueck und Koennen kann man ver- mutlich die abgelehnten Patches von Hand einpfrimeln, aber manchmal geht das eben auch nicht, haengt davon ab, was der andere Patch schon alles veraendert hat. In solchen Faellen muss man sich dann wirklich auskennen in Sachen Kernel-Programmierung. CU, Th.
Am Freitag, 15. August 2003 23:13 schrieb Thomas Hertweck:
Al Bogner schrieb:
[...] Wirkliche Fehlermeldungen gab es beim Patchen nicht. linux-2.4.21.tar.gz mit grsecurity-1.9.11-2.4.21.patch läuft ohne jegliche Probleme und bei patch-2.4.22-rc2.gz gibt es dann nur Meldungen, dass die Zeilen verschoben sind. [...]
1 out of 3 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej
Ich weiss ja nicht, was Du gemacht hast oder gesehen hast, aber bei mir _sind_ das Fehler und nicht nur Meldungen, dass es Offsets gab beim Patchen...
Mir ist "FAILED" nicht aufgefallen, aber ich schwör lieber nicht darauf, dass es ich es nicht übersehen habe.
Insbesondere gibt es auch einen Fehler in mm/shmem.c beim Patchen, und da entsteht spaeter bei Dir auch der Fehler beim Compilieren.
Danke für deinen Test. Al
Am Freitag, 15. August 2003 23:23 schrieb Al Bogner:
1 out of 3 hunks FAILED -- saving rejects to file net/ipv4/udp.c.rej
Mir ist "FAILED" nicht aufgefallen, aber ich schwör lieber nicht darauf, dass es ich es nicht übersehen habe.
Gibt es eigentlich bei Fehlern immer am _Ende_ eine Meldung, dass eine rej-Datei erstellt wurde? Die war nämlich bei der von mir beschriebenen Vorgansweise sicher nicht am Ende da, allerdings bei der anderen Reihenfolge. Al
Al Bogner schrieb:
[...] Gibt es eigentlich bei Fehlern immer am _Ende_ eine Meldung, dass eine rej-Datei erstellt wurde? Die war nämlich bei der von mir beschriebenen Vorgansweise sicher nicht am Ende da, allerdings bei der anderen Reihenfolge.
Nein, die Fehlermeldung erscheint, wenn versucht wird, die jeweilige Datei zu patchen. Geschieht das gleich zu Beginn des Patchens bei irgendwelchen Dateien und Du hast einen schnellen Rechner, dann scrollt das rasend an Dir vorbei und Du wirst es nicht sehen. Am Ende sieht es dann so aus als haette alles funktioniert, wenn die zuletzt gepatchten Dateien alle erfolgreich waren. Deswegen, siehe auch meine alte Mail, habe ich die Ausgabe des Patchens in eine Log-Datei schreiben lassen. Die kann man dann in aller Ruhe anschauen und analysieren. Das kann man prinzipiell mit jedem Patch- oder Compilierbefehl, der sehr viel Ausgabe produziert, so machen: befehl 2>&1 | tee logfile Gruesse, Thomson
Am Freitag, 15. August 2003 23:57 schrieb Thomas Hertweck:
Nein, die Fehlermeldung erscheint, wenn versucht wird, die jeweilige Datei zu patchen. Geschieht das gleich zu Beginn des Patchens bei irgendwelchen Dateien und Du hast einen schnellen Rechner, dann scrollt das rasend an Dir vorbei und Du wirst es nicht sehen. Am Ende sieht es dann so aus als haette alles funktioniert, wenn die zuletzt gepatchten Dateien alle erfolgreich waren.
Deswegen, siehe auch meine alte Mail, habe ich die Ausgabe des Patchens in eine Log-Datei schreiben lassen. Die kann man dann in aller Ruhe anschauen und analysieren. Das kann man prinzipiell mit jedem Patch- oder Compilierbefehl, der sehr viel Ausgabe produziert, so machen:
befehl 2>&1 | tee logfile
Reicht es auch nach *.rej zu suchen, sozusagen als schnelle Kontrolle? Übrigens, jetzt läuft bei mir 2.4.22-rc2-grsec. Den Patch gibt es bei http://www.grsecurity.net/~spender/grsecurity-1.9.12-2.4.22.patch Al
Al Bogner schrieb:
[...] Reicht es auch nach *.rej zu suchen, sozusagen als schnelle Kontrolle?
Wenn Du das Patchen nicht mitprotokolliert hast, so kannst Du auch via >> find . -type f -iname "*.rej" -print << nach abgelehnten Patches suchen (Eingabe des Befehls im Verzeichnis mit den gepatchten Kernel-Quellen). Ich wuerde Dir aber fuer die Zukunft empfehlen, solche Patch- oder Compilieraktionen mitzuprotokollieren. Wie das geht, hatte ich schon geschrieben, oder aber schau Dir http://www.thomashertweck.de/kernel.html#sonstiges (zweiter Punkt) nochmal an.
Übrigens, jetzt läuft bei mir 2.4.22-rc2-grsec. Den Patch gibt es bei http://www.grsecurity.net/~spender/grsecurity-1.9.12-2.4.22.patch
Schoen. Der Patch scheint dann besser gepasst zu haben. CU, Thomson
participants (2)
-
Al Bogner -
Thomas Hertweck