[Pepin OS] Kernel générant la GDT

Version imprimable

Bonjour,

J'ai un souci en suivant le tuto pepin os, je voulais faire en sorte que la partie du kernel generant la gdt soit en assembleur, et j'ai un pépin :D
J'ai fait ca comme code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
_start:
	call init_screen
 
	mov  eax, loading_msg
	push eax
	call aff_msg
	pop eax
 
	mov ax, gdtend		;on se met à la fin de la gdt
	mov bx, gdt		;on se met au debut de la gdt
	sub ax, bx		;on calcul la difference de taille entre les deux
	mov word[gdtptr], ax	;on stocke cette difference dans gdtptr
 
	xor eax, eax
	xor ebx, ebx
	mov ax, ds
	mov ecx, eax
	shl ecx, 4
	mov bx, gdt
	add ecx, ebx
	mov dword[gdtptr + 2], ecx
 
	lgdt [gdtptr]
 
	;on reinitialise les selecteurs de donnees
	mov  ax, 0x10		;emplacement du datasegment
	mov  ds, ax		;met le datasegment à 0x10
	mov  es, ax		;met l'extra segment à 0x10
	mov  fs, ax		;fs = adresse extra segment en mode protege
	mov  gs, ax		;gs = adresse extra segment en mode protege
	;on reinitialise la stack
	mov  ax, 0x18
	mov  ss, ax		;met la stack à 0x18
	mov  esp, 0x20000	;indique la fin de la stack
	jmp  dword 0x8:next	; on reinitialise le selecteur de code
next:
 
	mov  eax, loaded_msg
	push eax
	call aff_msg
	pop eax
end:
	jmp end
 
loading_msg:	db "Loading GDT", 0xA, 0xD, 0x0
 
loaded_msg:	db "GDT loaded", 0xA, 0xD, 0x0
 
gdt:	db 0, 0, 0, 0, 0, 0, 0, 0                               ;descripteur du segment NULL
gdt_cs:	db 0xFF, 0xFF, 0x0, 0x0, 0x0, 10011011b, 11011111b, 0x0 ;descripteur du segment de code
gdt_ds:	db 0xFF, 0xFF, 0x0, 0x0, 0x0, 10010011b, 11011111b, 0x0 ;descripteur du segment de donnees
gdt_ss:	db 0x0, 0x0, 0x0, 0x0, 0x0, 10010111b, 11010000b, 0x0 ;descripteur du segment de pile
gdtend:								;on a fini de decrire le tableau de descripteurs
 
gdtptr:
	dw 0			;limite de la gdt
	dd 0			;base de la gdt

j'ai utilisé qemu (je n'ai rien compris à bochs) Et quand je teste j'ai un reboot en boucle (je vois le message kernel loading et ensuite ca reboot)

Je pense que sa vient de ma gdt qui n'est pas correct mais je n'arrive pas à savoir ou, ou alors du shl (je sais que c'est un decalage de bits vers la gauche mais je n'ai pas compris à quoi il servait)

Si vous pouviez m'aider ce serait vraiment sympa,

Cordialement,

05/11/2015, 21h25
chrtophe

Je te recommandes d'investir du temps sur Bochs, celui-ci intègre un débogueur. Je ne sais plus si il t’indique les flags pour la gdt, ce qui te permettrait de comprendre ou ça merde.

Citation:

je voulais faire en sorte que la partie du kernel generant la gdt soit en assembleur

ça je comprend pas, car c'est en assembleur.

le décalage de shl vient du fait que ton code en mode réel se situe à une adresse géré par un segment:offset. L'adresse 0x7c0:0000 correspond en fait à l'adresse réelle 0x7c000. En fait pour simplifier tu prends l'adresse réelle divisée par 16, le quotient étant le segment, le reste l'offset. Le décalage de la ligne 18 génère une multiplication par 16 de la valeur du segment ds, auquel est ajouté le contenu de bx (offset de gdt). ce qui donnera donc au niveau de la ligne 21 l'adresse absolue de la gdt
05/11/2015, 22h33
zzzflo

Citation:

Envoyé par chrtophe

Je te recommandes d'investir du temps sur Bochs, celui-ci intègre un débogueur. Je ne sais plus si il t’indique les flags pour la gdt, ce qui te permettrait de comprendre ou ça merde.

ça je comprend pas, car c'est en assembleur.

le décalage de shl vient du fait que ton code en mode réel se situe à une adresse géré par un segment:offset. L'adresse 0x7c0:0000 correspond en fait à l'adresse réelle 0x7c000. En fait pour simplifier tu prends l'adresse réelle divisée par 16, le quotient étant le segment, le reste l'offset. Le décalage de la ligne 18 génère une multiplication par 16 de la valeur du segment ds, auquel est ajouté le contenu de bx (offset de gdt). ce qui donnera donc au niveau de la ligne 21 l'adresse absolue de la gdt

Merci pour l'explication a propos du decalage, je me doutais que c'etait pour l'offset mais je n'avais pas bien compris.

Par rapport a bochs il existe des bons tuto ou alors il faut explorer les documentations officielles?

La boot est fait en assembleur mais le kernel (pour cette partie) la est en C avec des bouts d'asm incruste
06/11/2015, 09h31
chrtophe

Citation:

Par rapport a bochs il existe des bons tuto ou alors il faut explorer les documentations officielles?

La doc officielle pour le debuggeur intégré est abordable, par contre elle ne t'apprendras pas l'assembleur. Il doit y en avoir.

Citation:

La boot est fait en assembleur mais le kernel (pour cette partie) la est en C avec des bouts d'asm incruste

Ben oui, c'est la pratique. Et le boot ne fait pas partie du kernel, c'est le code qui le charge.

Exemple : Si tu veux modifier la GDT depuis le kernel, il faut effectivement intégrer du code assembleur dans le source C (on appelle ça du code inline), car on ne peut pas le faire en C.

Quand j'essaye de lancer bochs j'obtiens toujours une erreur : terminate called after throwingan instance of std::bad_alloc
Voici mon bochsrc :

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 # configuration file generated by Bochs plugin_ctrl: unmapped=1, biosdev=1, speaker=1, extfpuirq=1, parallel=1, serial=1, iodebug=1 config_interface: textconfig display_library: x memory: host=2048, guest=4000 romimage: file="/usr/share/bochs/BIOS-bochs-latest" vgaromimage: file="/usr/share/bochs/VGABIOS-lgpl-latest" boot: floppy floppy_bootsig_check: disabled=0 # no floppya # no floppyb ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata0-master: type=none ata0-slave: type=none ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata1-master: type=none ata1-slave: type=none ata2: enabled=0 ata3: enabled=0 pci: enabled=1, chipset=i440fx vga: extension=vbe, update_freq=5, realtime=1 cpu: count=1:1:1, ips=4000000, quantum=16, model=corei5_lynnfield_750, reset_on_triple_fault=1, cpuid_limit_winnt=0, ignore_bad_msrs=1, mwait_is_nop=0 print_timestamps: enabled=0 debugger_log: /home/videau_f/bochs_log_dbg magic_break: enabled=0 port_e9_hack: enabled=0 private_colormap: enabled=0 clock: sync=none, time0=local, rtc_sync=0 # no cmosimage # no loader log: /home/videau_f/bochs_log logprefix: %t%e%d debug: action=ignore info: action=report error: action=report panic: action=ask keyboard: type=mf, serial_delay=250, paste_delay=100000, user_shortcut=none mouse: type=ps2, enabled=0, toggle=ctrl+mbutton speaker: enabled=1, mode=system parport1: enabled=1, file=none parport2: enabled=0 com1: enabled=1, mode=null com2: enabled=0 com3: enabled=0 com4: enabled=0

Si quelqu'un connait cette erreur, je trouve pas grand chose sur google.

EDIT: J'ai réussi a faire fonctionner bochs, A la base je l'avais installé avec pacman, je l'ai desinstallé, téléchargé les sources, recompilé, pris le fichier de configuration fourni, y ait fait quelques modifications et ca a marché, maintenant il faut que j'étudie le debug sous bochs

Quand j'ouvre le log apres avoir teste ma disquette je triouve ces lignes qui m'ont l'air intéressantes :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
00181037725e[CPU0  ] load_seg_reg(DS, 0x0010): segment not present
00181037725e[CPU0  ] fetch_raw_descriptor: GDT: index (f007) 1e00 > limit (20)
00181037725e[CPU0  ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00181037725i[CPU0  ] CPU is in protected mode (active)
00181037725i[CPU0  ] CS.mode = 32 bit
00181037725i[CPU0  ] SS.mode = 32 bit
00181037725i[CPU0  ] EFER   = 0x00000000
00181037725i[CPU0  ] | EAX=00000010  EBX=00001088  ECX=00001188  EDX=0000107a
00181037725i[CPU0  ] | ESP=0009f000  EBP=00000000  ESI=000e00ae  EDI=0000ffac
00181037725i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af PF cf
00181037725i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00181037725i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] |  FS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] |  GS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00181037725i[CPU0  ] | EIP=00001045 (00001045)
00181037725i[CPU0  ] | CR0=0x60000011 CR2=0x00000000
00181037725i[CPU0  ] | CR3=0x00000000 CR4=0x00000000
00181037725i[CPU0  ] 0x00001045>> mov ds, ax : 8ED8
00181037725e[CPU0  ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
00181037725i[SYS   ] bx_pc_system_c::Reset(HARDWARE) called
00181037725i[CPU0  ] cpu hardware reset

Je vais essayer d'étudier ça

Par rapport à l'intégration d'assembleur dans le c je trouverais ca plus logique de faire en assembleur et d'appeler des fonctions en C si besoin est

Et quant au code du tuto je peux pas le compiler (quand je fais make j'ai des warnings et l'instruction ljmp n'est pas reconnue)

06/11/2015, 14h54
chrtophe

Citation:

Par rapport à l'intégration d'assembleur dans le c je trouverais ca plus logique de faire en assembleur et d'appeler des fonctions en C si besoin

Les deux sont faisable. Il faut respecter les conventions d'appel.
06/11/2015, 15h21
zzzflo

A priori c'est le mov ds, ax apres le lgdt qui fait bugger
06/11/2015, 16h06
chrtophe
A oui, normal, j'avais pas vu.

la fonction lgdt charge la table gdt, mais à ce stade tu n'est pas encore en mode protégé.

Juste après lgdt, il te manque :
Code:

1 2 3 4 5 6 7 8 9 10 mov eax,cr0 or al,1 mov cr0,eax jmp 8:next next: mov ax,0x10 mov ds,ax mov es,ax etc ...
mov eax,cr0 charge le registre cr0 dans eax
or al,1 fixe lke bit de poids faible à 1 qui signifie mode protégé
mov cr0,eax met à jour le registre

C'est l'activation de ce flag qui va activer le mode protégé, on charge ce registre pour modifier 1 seul bit car les autres bits on une valeur significative qu'on ne doit pas toucher n'importe comment. Avant d'activer le mode protégé une table gdt valide doit être chargé
jmp 8:next va servir à mettre à jour les caches CPUs, et ensuite il faut recharger les registres ds,es qui contiennent toujours les valeurs mode réels, invalides en mode protégé.
Code:

1 2 3 4 mov ax, 0x18 mov ss, ax ;met la stack à 0x18 mov esp, 0x20000 ;indique la fin de la stack
va ensuite créer une pile comme l'indique les commentaires.

Tu remarqueras que le registre de segment n'est pas le même pour ds,es et ss. Cela dépend de ta table GDT. l'entrée pour CS doit être un segment avec le flag code, ds,es,ss doivent être flaggé data.
06/11/2015, 16h45
zzzflo
Citation:
Envoyé par chrtophe

A oui, normal, j'avais pas vu.

la fonction lgdt charge la table gdt, mais à ce stade tu n'est pas encore en mode protégé.

Juste après lgdt, il te manque :

Code:

1 2 3 4 5 6 7 8 9 10 mov eax,cr0 or al,1 mov cr0,eax jmp 8:next next: mov ax,0x10 mov ds,ax mov es,ax etc ...

mov eax,cr0 charge le registre cr0 dans eax
or al,1 fixe lke bit de poids faible à 1 qui signifie mode protégé
mov cr0,eax met à jour le registre

C'est l'activation de ce flag qui va activer le mode protégé, on charge ce registre pour modifier 1 seul bit car les autres bits on une valeur significative qu'on ne doit pas toucher n'importe comment. Avant d'activer le mode protégé une table gdt valide doit être chargé
jmp 8:next va servir à mettre à jour les caches CPUs, et ensuite il faut recharger les registres ds,es qui contiennent toujours les valeurs mode réels, invalides en mode protégé.

Code:

1 2 3 4 mov ax, 0x18 mov ss, ax ;met la stack à 0x18 mov esp, 0x20000 ;indique la fin de la stack

va ensuite créer une pile comme l'indique les commentaires.

Tu remarqueras que le registre de segment n'est pas le même pour ds,es et ss. Cela dépend de ta table GDT. l'entrée pour CS doit être un segment avec le flag code, ds,es,ss doivent être flaggé data.
Le passage en mode protege c'est pour le boot non? Ici on est dans le kernel et on est deja en protege (du moins c'est ce que j'ai compris et c'est marque dans le log). Il faut juste que je voie pourquoi ma gdt est trop petite.
Et si je mets juste jump 0x08:next dans les logs j'ai jump_protected: gate type 0 unsupported
06/11/2015, 19h21
chrtophe

Citation:

Le passage en mode protege c'est pour le boot non? Ici on est dans le kernel et on est deja en protege

oui.

En fait quand ta machine démarres, tu es en mode réel. Le CPU execute le code à l'adresse réelle 0xf000:0xfff0, code du BIOS Le BIOS va charger le premier secteur du disque de démarrage à l'adresse 0x7c0:0000. De là tu as 512 K de chargé qui vont dans un premier temps charger du code supplémentaire ( car avec 512 Ko on fait pas grand chose), c'est ce code qui va passer en mode protégé, charger le noyau proprement dit, faire toutes les initialisations nécessaires et lui passer la main (au noyau).

En UEFI qui remplace le BIOS , je pense que tu es en mode protégé beaucoup plus vite, le code UEFI intégré à la carte mère est fait en C, puis compilé, mais le CPU démarre toujours en mode réel. mais le principe reste le même, tu as un code d'amorce qui va charger le noyau et lui passer la main. Ce code est stocké dans un fichier .efi dans la partition EFI du disque. Ce fichier .efi est au format PE donc en 32 bits et déjà je pense en mode protégé. Mais je maitrise pas la programmation UEFI.

Citation:

Et si je mets juste jump 0x08:next dans les logs j'ai jump_protected: gate type 0 unsupported

Ta GDT ne doit pas être bonne.
09/11/2015, 09h41
zzzflo

J'ai passé le week-end a chercher et je n'ai toujours pas trouve, si quelqu'un a une idee elle est la bienvenue.
EDIT : j'ai un debut de solution : si je mets gdt_ds au lieu de 0x10 pour ds, es, fs, gs ca fonctionne mais par contre si je mets gdt_ss pour la stack j'obtiens une erreur : load_seg_reg(SS): rpl != cpl (a priori un probleme de privileges) Si quelqu'un connait cette erreur.

REEDIT : en fait mettre gdt_ds au lieu de 0x10 ca fonctionne que si loading_nsg et loaded_msg sont avant gdt

Je pense que ce qui cloche c'est que je ne fasse pas de memcpy mais je ne sais pas comment faire :(

Je verrais bien quelquechose comme ca :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
%define GDTBASE 0x0
 
%define GDTSIZE 0xFF
 
mov_gdt:
	xor  eax, eax
	mov  ax, WORD[gdt_src]
	mov  WORD[gdt_dest], ax
	inc  WORD[gdt_src]
	inc  WORD[gdt_dest]
	dec  WORD[gdt_cptr]
	jnz mov_gdt
 
gdt_cptr:	dw GDTSIZE * 8
 
gdt_dest:	dw GDTBASE
 
gdt_src:	dw gdt
 
loading_msg:	db "Loading GDT", 0xA, 0xD, 0x0
 
loaded_msg:	db "GDT loaded", 0xA, 0xD, 0x0
 
gdt:	db 0x00, 0x00, 0x00, 0x00, 0x00, 00000000b, 00000000b, 0x00	;descripteur du segment NULL
gdt_cs:	db 0xFF, 0xFF, 0x00, 0x00, 0x00, 10011011b, 11011111b, 0x00	;descripteur du segment de code
gdt_ds:	db 0xFF, 0xFF, 0x00, 0x00, 0x00, 10010011b, 11011111b, 0x00	;descripteur du segment de donnees
gdt_ss:	db 0x00, 0x00, 0x00, 0x00, 0x00, 10010111b, 11010000b, 0x00	;descripteur du segment de pile
gdtend:									;on a fini de decrire le tableau de descripteurs
 
gdtptr:
	dw 0			;limite de la gdt
	dd 0			;base de la gdt

Mais ca nbug toujours

J'ai refait entierement le kernel et il fonctionne, voici le code (apparemment mon ss dans la gdt n'etait pas bon et il ne fallait pas mettre d'offset pour la base de la gdt), voici le code (ca peut toujours servir) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
[BITS 32]
 
	extern scrollup, aff_msg, init_screen
 
	global _start
 
_start:
 
	call init_screen
 
	mov  eax, msg_loading
	push eax
	call aff_msg
	pop  eax
 
	mov  ax, gdt
	mov  bx, gdt_end
	sub  bx, ax
	mov  WORD[gdt_ptr], bx
 
	xor  eax, eax
	mov ax, gdt
	mov  DWORD[gdt_ptr + 2], eax
 
	lgdt [gdt_ptr]
 
	mov  ax, 0x10
	mov  ds, ax
	mov  es, ax
	mov  fs, ax
	mov  gs, ax
 
	mov  ax, 0x18
	mov  ss, ax
	mov  esp, 0x20000
 
	jmp  0x08:next
next:	
	mov  eax, msg_loaded
	push eax
	call aff_msg
	pop  eax
 
end:
	jmp end
 
msg_loading:	db "loading gdt", 0xA, 0xD, 0x0
 
msg_loaded:	db "gdt loaded", 0xA, 0xD, 0x0
 
;;gdt: db limite 0-7, limite 8-15, base 0-7, base 8-15 , base 16-23, type(p dpl s type), flags(g d/b 0 AVL) + limite 16-19, base 31-24
 
gdt:	db 0x00, 0x00, 0x00, 0x00, 0x00, 00000000b, 00000000b, 0x00
gdt_cs:	db 0xFF, 0xFF, 0x00, 0x00, 0x00, 10011011b, 11011111b, 0x00
gdt_ds:	db 0xFF, 0xFF, 0x00, 0x00, 0x00, 10010011b, 11011111b, 0x00
gdt_ss:	db 0x00, 0x00, 0xFF, 0xFF, 0xFF, 10010111b, 11010000b, 0x00
gdt_end:
 
gdt_ptr:
	dw 0			;size
	dd 0			;base

Merci pour ton aide

10/11/2015, 16h51
zzzflo

Je viens de me rendre compte d'un bug avec mon code : ma gdt est de taille 3 et pas de taille 0xFF (du coup je peux pas rajouter d'elements). Le probleme c'est que a part ajouter 250 elements null le ne vois pas comment faire, il y a moyen dans le code de lui dire de laisser 255 cases en total pour la gdt?
EDIT : Je cree ma gdt et la stocke en 0x00 en C et la partie qui suit je la fais en asm (mais pas avec de l'asm inline)