Как сделать дальний прыжок при переключении из 16 битного в 32 битный режим?

Question

[nnGot583]

Я писал бут сектор для ядра и сделал такую функцию для этого:

SWITCH_32:
cli
lgdt [gdt_descriptor]

mov eax, cr0
or eax, 0x1
mov cr0, eax

far_jump_to_kernel:
db 0x66
db 0xEA
dd 0x7777; любой адрес для перехода
dw 0x0008; селектор

У меня не вышло сделать дальний прыжок с изменением cs,
прямое забитие байтов в код не помогло и
не получилось так: jmp 0x8:addr

В отладчике я видел это:

(gdb не определил инструкции только)

то есть примерно после этих инструкций началось исполнение на рандомном адресе.
Я не нашел в интернете ничего про это, что попробовать сделать? может сегментные регистры проверить, таблицу дескрипторов? Прощу прощение если вопрос тупой

Comments

[Aragorn]

Код текстом должен быть

[nnGot583]

Aragorn, Пожалуйста

Answer 1

[jcmvbkbc]

В отладчике я видел это:

gdb здесь ожидает увидеть 64-битный код, чтобы он корректно интерпретировал 32-битный код надо ему скомандовать что-то типа set arch i386:x86-64 перед соединением.

Comments

[nnGot583]

Спасибо за ответ, но отметить решением не могу тк это не по теме вопроса. Где я натупил?

[jcmvbkbc]

Где я натупил?

В настройке дизассемблера и интерпретации его вывода. Потому что с переходом всё ок:

$ cat test.S
.text
far_jump_to_kernel:
.byte 0x66
.byte 0xEA
.word 0x7777
.short 0x0008

$ gcc -c -m32 test.S -o test.o
$ objdump -d test.o 

test.o:     file format elf32-i386


Disassembly of section .text:

00000000 <far_jump_to_kernel>:
   0:   66 ea 77 77 08 00       ljmpw  $0x8,$0x7777

[nnGot583]

jcmvbkbc, Но я поставил точку останова на адрес 0х7777 и перехода туда не произошло. А интерпретация не должна повлиять по идее. В регистре ip после дальнего прыжка адрес 0xe05b оказывается

[jcmvbkbc]

nnGot583, ну хорошо, давай разбираться:
- как именно ты отлаживаешь свою программу?
- в каком режиме находится процессор в момент выполнения этой инструкции?
- что в gdt?

[nnGot583]

jcmvbkbc,
1)

вот мой скрипт запуска отладки

source memr
target remote localhost:1234
define nni
ni
x/4i $pc
end
define ssi
si
x/4i $pc
end
b *0x7c00
c

(memr это просто скрипт для красивого вывода памяти)

далее после этого

открываю дизассемблер чтобы понять куда ставить точки останова, например 0х7с78

2)

состояние до выполнения этой инструкции

состояние после выполнения

3)

gdt

sd_null:
dd 0
dd 0

sd_kcode:
dd 0x0000ffff
db 0x00
db 0x8a
db 0xcf
db 0x00

sd_kdata:
dd 0x0000ffff
dd 0x00cf8200

... остальные сегменты точно не загружаются пока думаю их смотреть не надо

[nnGot583]

jcmvbkbc, я только сейчавс заметил, в cs после выполнения инструкции не 8 а 0xf000 я пока не понимаю как так вышло

[jcmvbkbc]

вот мой скрипт запуска отладки
...
target remote localhost:1234
...

nnGot583, что на другой стороне этого соединения? QEMU?

[nnGot583]

jcmvbkbc, Да, я запускаю это на QEMU, все настройки дефолтные

[jcmvbkbc]

nnGot583, вместо своих дефайнов ssi и nni можно было написать display/4i $pc -- и видеть 4 инструкции на текущем PC после каждой команды.

[jcmvbkbc]

состояние после выполнения

nnGot583, выглядит стрёмно. Слишком много изменений, в частности cr0 совсем не такой каким должен быть.
Я бы предложил вместо развлечений с gdb использовать встроенный логгер qemu. Его можно включить на ходу, но проще всего запускать qemu с ключами -d in_asm,exec,cpu -D logfile, результатом будет лог исполняемых команд процессора в интерпретации qemu и состояния регистров на момент начала выполнения блоков кода. Тебе останется найти в этом логе адрес 0x7c00 чтобы увидеть процесс выполнения своего кода.

[nnGot583]

jcmvbkbc, сделал как вы рекомендовали, вышло это:

первый блок

IN:
0x0000000000007c77: cli
0x0000000000007c78: lgdtw 0x7e48
0x0000000000007c7d: mov %cr0,%eax
0x0000000000007c80: or $0x1,%eax
0x0000000000007c84: mov %eax,%cr0

Linking TBs 0x11ab3e9c0 [0000000000007c1a] index 0 -> 0x11ab3eac0 [0000000000007c77]
Trace 0: 0x11ab3eac0 [0000000000000000/0000000000007c77/00000040/ff000000]
EAX=00000002 EBX=00000000 ECX=00000000 EDX=00000080
ESI=00007c2c EDI=00000000 EBP=00000000 ESP=00006f00
EIP=00007c77 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =0000 00000000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 00000000
IDT= 00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=0000fedc CCO=EFLAGS
EFER=0000000000000000
----------------

следующий за ним

IN:
0x0000000000007c87: ljmpl $0x8,$0x7777

Trace 0: 0x11ab3ecc0 [0000000000000000/0000000000007c87/000000c0/ff000000]
EAX=00000011 EBX=00000000 ECX=00000000 EDX=00000080
ESI=00007c2c EDI=00000000 EBP=00000000 ESP=00006f00
EIP=00007c87 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
CS =0000 00000000 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
DS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
FS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
GS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 00007e00 00000047
IDT= 00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000011 CCO=LOGICL
EFER=0000000000000000
Trace 0: 0x11a9bd100 [00000000ffff0000/00000000fffffff0/00000040/ff000000]
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00060fb1
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS
EFER=0000000000000000

далее

IN:
0x00000000000fe05b: cmpl $0x0,%cs:0x61c8
0x00000000000fe062: jne 0xfd0ef

Trace 0: 0x11ab3edc0 [00000000000f0000/00000000000fe05b/00000040/ff000000]
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00060fb1
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000e05b EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 000f0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS
EFER=0000000000000000

Я не могу увидеть что вызвало проблему. Инструкция интерпретировалась правильно, cr0 перед вызовом имел адекватное значение. База gdt верная и ее размер тоже. Я только понял, что значения появляются не случайные а это начало перезапуска QEMU

самый первый блок в файле выглядит так

IN:
0x00000000fffffff0: ljmp $0xf000,$0xe05b

Trace 0: 0x11a9bd100 [00000000ffff0000/00000000fffffff0/00000040/ff000000]
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00060fb1
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS
EFER=0000000000000000
----------------

[jcmvbkbc]

Я не могу увидеть что вызвало проблему.

мне видится, что дело в содержимом GDT:

sd_kcode:
dd 0x0000ffff
db 0x00
db 0x8a
db 0xcf
db 0x00

Это не дескриптор сегмента кода. Согласно мануалу, том 3A, раздел 6.2, у сегмента кода должна быть 1 в 12м разряде старшего слова, т.е.

dd 0x0000ffff
db 0x00
db 0x9a
db 0xcf
db 0x00

Согласно тому же документу, том 3А, раздел 3.5, 0xa в поле type системного сегмента -- это зарезервированное значение.

[nnGot583]

jcmvbkbc, да уж а у меня еще 6 селекторов буду тогда все перепроверять. спасибо все работает как нужно.