Thema: Kernel an virtuelle Adresse laden

[SSJ7Gohan]

Ich habe im Moment einen C Kernel, den ich mit GRUB an die physikalische Adresse 0x100000 laden lasse. Ich möchte jetzt den Kernel aber an die virtuelle Adresse 0xC0000000 laden lassen. Wie muss ich jetzt vorgehen um den Kernel an die Adresse 0xC0000000 mappen zu lassen? GRUB aktiviert ja soweit ich weiß kein Paging, und wenn ich in der linkfile 0xC0000000 angeben würde, dürfte der Kernel ja eigentlich nichtmehr funktionieren, da er die C-Funktionen die das Paging aktivieren nicht mehr findet, oder?

[sp]

Klingt so ein bisschen nach dem Henne-Ei-Problem .
AFAIK kannst du das aber auch noch machen, nachdem der Kernel im Speicher liegt.
Sonst entweder einen eigenen Bootloader nutzen, oder ein extra Programm zwischen Grub und Kernel packen.

[n3Ro]

Hi,

du musst eigentlich nur 2 Dinge machen: 1. dein Linkfile so umändern, das es die physische Addressen für dein Coding (0x100000) UND die virtuellen Addressen (ab 0xc0000000) angibt,

Hier ein Bsp:

Code: [Auswählen]


ENTRY(start)

g_virt = 0xc0000000;
g_phys = 0x00100000;

SECTIONS
{
    .text g_virt : AT(g_phys)
    {
g_code = .;_g_code = .;
*(.text)
*(.gnu.linkonce.t*)
*(.gnu.linkonce.r*)
*(.rodata*)
. = ALIGN(4096);
    }
    .data : AT(g_phys + (g_data - g_code))
    {
g_data = .;_g_data = .;
*(.data)
*(.gnu.linkonce.d*)
. = ALIGN(4096);
    }
    .bss : AT(g_phys + (g_bss - g_code))
    {
g_bss = .;_g_bss = .;
*(.bss)
*(COMMON)
*(.gnu.linkonce.b*)
. = ALIGN(4096);
g_end = .;_g_end = .;
    }
}


Als zweites musst du dafür sorgen, das dein Kernel als erstes das Paging hochfährt, sprich eine PageDirectory aufsetzen und Paging anschalten. Am besten du machst das im Assembler Coding, da weis man noch am besten was am ende rauskommt. Immer von Vorteil ist es dabei 4MB Pages zu verwenden, da du dir dadurch die PageTables ersparst.

[SSJ7Gohan]

Woher weiß der Prozessor denn dann ob die Addressen auf 0x10000 oder auf 0xc0000000 verweisen?

[n3Ro]

Der Prozessor nimmt die Addressen die reincompiliert sind, welche bei 0xc0000000 liegen, die physische Addresse ist nur im elf-binary vermerkt, damit GRUB weis, wo es das elf-binary hinladen soll; dort wird es auch ausgeführt! Das Problem ist nur, dass der Code bei 0x100000 läuft und alle Referenzen im Code auf 0xc0000000 zeigen, deswegen muss man auch in dieser Zeit auf alle Variablenzugriffe achten und die Addressen wenn nötig per Hand umrechnen lassen. Für Near-Jumps und -Calls ist das kein Problem, weil deren Sprungaddressen relative Werte sind und demnach unabhängig vom momentanen Instruction Pointer sind. D.h. kannst du beruhigt irgendwelche Funktionen aufrufen, solange alle Variablenzugriffe in diesen angepasst sind.

[Roshl]

Nicht ganz korrekt Near-Jumps sind keine relativen angaben, dass ist nur bei Short jumps so;) near jump heisst, dass kein Selektor mit dazu angegeben wird. Near calls sind auch nicht relativ, short calls gibt es leider nicht.
Man müsste halt alles, ausser den shortjumps selbst umrechnen

[n3Ro]

erwischt Da hat doch jemand die Specs nicht richtig gelesen. Near Calls (Opcode 0xe8) und Near Jumps (Opcodes 0xeb und 0xe9) nehmen nur relative Angaben an! Es gibt noch absolute Angabemöglichkeiten (Opcode 0xff), nur da wird die Zieladdresse aus einem angegebenen Register oder einer angegebenen Speicherstelle geladen, sprich indirekt.
Wo immer absolute Addressen angegeben werden sind Far Jumps und Calls, sprich wenn noch der Segment Selector angegeben wird. Short Jumps sind ja nur eine Kurzform der NearJumps, die allerdings auch nur 127 bytes vor oder zurück im code springen können.

Aber das mit den nicht existenten ShortCalls stimmt

[Roshl]

Ich hab die schon gelesen *grins*
Ist nur ne Bezeichnungsfrage hehe. Alles was relative Angaben annimmt bezeichne ich als short, was absolut annimmt aber kein Selektor/Segment als near und was absolut und selektor/segment nimmt als far.
Habs nur anders bezeichnet für mich (Und finde meine Einteilung auch logischer)

[n3Ro]

ist aber nicht die "offizielle" bezeichnung, sprich die die in den instruction set references steht

[Roshl]

Da steht auch nicht drin, dass man lea zum rechnen benutzen kann, man machts aber trotzdem;)

[n3Ro]

naja, zumindest steht bei lea das man es zum berechnen von speicheraddressen benutzt, alles andere ist ja eigentlich nur zweckentfremdung
genauso gibt es ja auch kein kapitel wie man seinen rechner am besten freezt ( cli hlt )

[Roshl]

cli;jmp $; ist lustiger da hat der prozessor wenigstens was zu tun;)

[Legend]

Generell kann man zumindestens beim GCC C-Code ohne globalen Variablen nehmen. Der ist PIC (Position Independant Code).

[Roshl]

Eigentlich nicht, da bei C ja Call benutzt wird und das gibt es soweit ich weiss nicht mit relativen Adressen

[DDR-RAM]

Eigentlich nicht, da bei C ja Call benutzt wird und das gibt es soweit ich weiss nicht mit relativen Adressen

near calls sind eip-relativ, genauso wie near jumps.

MfG
DDR-RAM

[Roshl]

Ja die Calls vielleicht, aber wenn ich die Intel Doku richtig lese, dann wird auch beim relative near call die Rücksprungaddi absolut gespeichert. Und das könnte letzlich doch Probleme beim ret geben oder?

[DDR-RAM]

nein, es wird eip gespeichert.
Dieser ist absolut ja.
Wenn man den Speicher an diesem EIP verändert bzw. paging einschaltet und da was falsch macht, dann hat man Probleme, sonst nicht.

MfG
DDR-RAM

[Legend]

Genau. Den Wert den man da dann absolut auf den Stack gelegt bekommt, der stimmt ja auch!

[Svenska]

Man könnte natuerlich auch den Kernel an eine gewisse Adresse laden, Paging einschalten und ihn dann an die gewünschte virtuelle Adresse kopieren
Dann hüpft man einfach rein und das Problem ist gelöst.

Kann GRUB den Kernel nicht irgendwoandershin laden?

Svenska

[Legend]

GRUB aktiviert Paging nicht, d.h. solange du nicht mehr als 3GB RAM hast, wirst du deinen Kernel wohl nicht an per GRUB an 0xC0000000 laden können!