Kernel 2.6.23.1 und Debian Sarge auf AMD64

[init.d]

Hallo zusammen,

ich habe hier ein Debian Sarge System (derzeit mit selber kompiliertem Kernel 2.6.22.1; AMD64) und möchte den
Kernel Upgraden und bekomme folgenden Fehler:

Code: Alles auswählen

  SYSCALL arch/x86_64/vdso/vdso.so
/usr/bin/ld: section .text [ffffffffff700000 -> ffffffffff7002e3] overlaps section .hash [ffffffffff700120 -> ffffffffff7001d3]
/usr/bin/ld: section .plt [ffffffffff7002e4 -> ffffffffff700303] overlaps section .dynsym [ffffffffff7001d8 -> ffffffffff700447]
collect2: ld returned 1 exit status
make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1
make: *** [arch/x86_64/vdso] Error 2

Ich schätze das hat irgendwas mit den Binutils zu tun (auf dem System binutils 2.15 - sollte laut den Requirements
passen) oder aber Debian Sarge benötigt noch den VDSO COMPAT MODE, jedoch ist diese Option im neuen
Kernel nicht mehr zu finden.

Wenn ich den Offset in arch/x86_64/vdso/voffset.h von #define VDSO_TEXT_OFFSET 0x600 auf #define VDSO_TEXT_OFFSET 0xc00 ändere, lässt sich der Kernel kompilieren.

Auf Debian Etch kann ich die Server derzeit nicht upgraden, das ist also keine Lösung.

Was kann man machen? Ich bin doch sicherlich nicht der einzige mit dem Problem.

Ciao,
init[/b][/code]

[Spasswolf]

Was spricht dagegen beim alten Kernel zu bleiben?

[init.d]

Hi,

dagegen spricht nichts, aber was spricht dagegen auf den neuesten kernel zu aktualisieren ?
Sollte irgendwann wieder ein Securityproblem auftauchen, habe ich gern die Gewissheit, dass
ein Upgrade auf den nächsten Kernel auch funktioniert

Ciao,
init

[gms]

Wenn ich den Offset in arch/x86_64/vdso/voffset.h von #define VDSO_TEXT_OFFSET 0x600 auf #define VDSO_TEXT_OFFSET 0xc00 ändere, lässt sich der Kernel kompilieren.

und wenn du ihn auf 0x500 änderst ?
siehe http://lkml.org/lkml/2007/9/21/368

Gruß
gms

[init.d]

ändert nix:

Code: Alles auswählen

/usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
collect2: ld returned 1 exit status
make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1
make: *** [arch/x86_64/vdso] Error 2

[/code]

[Spasswolf]

Scheint tatsächlich etwas mit der binutils Version zu tun zu haben:
http://lkml.org/lkml/2007/9/21/368
Wie wär's wenn du die etch-binutils auf sarge kompilierst? Oder du bleibst bei deiner Lösung, wobei ich keine Ahnung habe, ob es das irgendwelche unschöne Konsequenzen gibt.

[gms]

Oder du bleibst bei deiner Lösung, wobei ich keine Ahnung habe, ob es das irgendwelche unschöne Konsequenzen gibt.

so gehts mir allerdings auch

ändert nix:

Code: Alles auswählen

/usr/bin/ld: section .text [ffffffffff700500 -> ffffffffff7007e3] overlaps section .gnu.version_d [ffffffffff7004d8 -> ffffffffff70050f]
collect2: ld returned 1 exit status
make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1
make: *** [arch/x86_64/vdso] Error 2

[/code]

zumindest verstehe ich jetzt den Grund für diesen Patch, ich würde noch 0x510 versuchen, damit bewegen wir uns wengistens zwischen dem Wert vor diesem Patch und dem Wert nach diesem Patch, und die Überlappung, welcher dieser Patch versucht zu beheben, sollte mit diesem Wert auch nicht mehr auftreten

Gruß
gms

[Spasswolf]

Ich denke das der Wert von VDSO_TEXT_OFFSET zumindest größer als 0x600 sein sollte, um mit den sarge binutils zu funktionieren, probier mal 0x700 und Versuch dich so an den Minimalwert für den es funktioniert heranzutasten.

[gms]

Ich denke das der Wert von VDSO_TEXT_OFFSET zumindest größer als 0x600 sein sollte, um mit den sarge binutils zu funktionieren.

verstehe ich jetzt nicht, wie du auf die "größer 0x600" kommst
Die Sarge Binutils erzeugen mit 0x500 eine Überlappung von 0xf Bytes
0x500 + 0xf = 0x50f, daher sollte 0x510 genügen
ich vermute allerdings auch, daß die Überlappung mit ".hash" im ersten Beitrag nicht mit dem Wert 0x600 Zustande gekommen ist, sondern von einem anderen Test ( z.B 0x000 ) herrührt. Mit 0x600 müßte eher eine Überlappung mit ".data" Zustande kommen ( edit: meine Spekulation auf ".data" ausgebessert )

Gruß
gms


edit: hier noch die Section Header von meiner generierten 2.6.23er Version

Code: Alles auswählen

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .hash             HASH             ffffffffff700120  00000120
       0000000000000048  0000000000000004   A       2     0     8
  [ 2] .dynsym           DYNSYM           ffffffffff700168  00000168
       0000000000000138  0000000000000018   A       3     6     8
  [ 3] .dynstr           STRTAB           ffffffffff7002a0  000002a0
       0000000000000052  0000000000000000   A       0     0     1
  [ 4] .gnu.version      VERSYM           ffffffffff7002f2  000002f2
       000000000000001a  0000000000000002   A       2     0     2
  [ 5] .gnu.version_d    VERDEF           ffffffffff700310  00000310
       0000000000000038  0000000000000000   A       3     2     8
  [ 6] .text             PROGBITS         ffffffffff700600  00000600
       000000000000027c  0000000000000000  AX       0     0     16
  [ 7] .data             PROGBITS         ffffffffff700900  00000900
       0000000000000018  0000000000000000  WA       0     0     8
  [ 8] .note             NOTE             ffffffffff700918  00000918
       0000000000000018  0000000000000000   A       0     0     4
  [ 9] .eh_frame_hdr     PROGBITS         ffffffffff700930  00000930
       0000000000000034  0000000000000000   A       0     0     4
  [10] .eh_frame         PROGBITS         ffffffffff700968  00000968
       00000000000000a8  0000000000000000   A       0     0     8
  [11] .dynamic          DYNAMIC          ffffffffff700a10  00000a10
       00000000000000f0  0000000000000010  WA       3     0     8
  [12] .useless          PROGBITS         ffffffffff700b00  00000b00
       0000000000000018  0000000000000008  WA       0     0     8
  [13] .comment          PROGBITS         0000000000000000  00000b18
       0000000000000063  0000000000000000           0     0     1
  [14] .shstrtab         STRTAB           0000000000000000  00000b7b
       0000000000000092  0000000000000000           0     0     1
  [15] .symtab           SYMTAB           0000000000000000  00001050
       0000000000000378  0000000000000018          16    30     8
  [16] .strtab           STRTAB           0000000000000000  000013c8
       0000000000000142  0000000000000000           0     0     1

danach klingt es sehr plausibel, daß es mit 0xc00 auch keine Überlappung gibt, nur wie gesagt, weiß ich hier auch nicht, ob das keine Nebeneffekte hervorruft

[Spasswolf]

Du hast recht mit 0x510 funktioniert es, ich hab's in einem sarge chroot ausprobiert.

[gms]

ich hab's in einem sarge chroot ausprobiert.

kannst du, wenn du Zeit und Lust hast, bitte auch die "original Fehlermeldung" ( mit 0x600) versuchen zu eruieren, damit man über Google oder die Forensuche, diesen Thread auch findent. Ich bin momentan leider zu sehr "angehängt" mir ein sarge chroot aufzusetzen.

Gruß
gms

[init.d]

die frage ist halt auf der anderen seite auch, was für nebeneffekte das ggf. haben kann.
ist das wirklich zu empfehlen?

init

[gms]

solange du dich zwischen 0x500 und 0x600 bewegst, ist nichts dagegen einzuwenden.
Im Prinzip machst du das gleiche wie der offizielle Patch, der in den Kernel eingeflossen ist. Dort wurde nach einem Problem mit alten binutils der Offset mehr oder weniger "willkührlich" auf 0x600 raufgesetzt, ein Wert der jetzt allerdings das Problem mit der Überlappung verursacht.

wenn du dir in den Kernelsourcen das vdso.lds.S anschaust, dann findest du dort die zwei Markierungen "VDSO_PRELINK + VDSO_TEXT_OFFSET" ( die also um 0x100 verschoben ) und die Markierung "VDSO_PRELINK + 0x900" die allerdings nicht verschoben wurde.

Code: Alles auswählen

  . = VDSO_PRELINK + VDSO_TEXT_OFFSET;

  .text           : { *(.text) }                :text
  .text.ptr       : { *(.text.ptr) }            :text

  . = VDSO_PRELINK + 0x900;
  .data           : { *(.data) }                :text

Dadurch ist aber auch zwischen dieser Markierung und der Markierung "VDSO_PRELINK+0x900" weniger Platz, wodurch das neuerliche Problem mit der Überlappung zustande kommt.

0xc00 oder höher würde ich keinesfalls verwenden. Nicht nur, daß dadurch die .text Section plötzlich hinter die .data Section wandert ( hier sollte eigentlich zumindest ein Warning bei der Umwandlung ausgegeben werden ), belegt das generierte vdso.so auch später im Speicher mehr Platz.

Gruß
gms

[init.d]

Hi GMS,

ich danke dir für deine ausführliche Erklärung. Ich habe den neuen Kernel nun mit 0x510 übersetzt
und werde beobachten, ob das Teil auf dem Testserver stabil läuft.

cu,
init