фокусы покусы реального режима - что будет если

создать сегмент из FFFF nop'ов и передать на него управление

jmp xxxx:0000

ip пробежит от 0 до ffff это ясно, но что дальше ??? вернется в начало или скорректируется cs ??

 

вернётся в начало

 

поверим, поставим эксперимент

 

добежит до конца и вызовет исключение. А дальше как обработчик на душу положит

 

FatMoon
какое исключение ??? номер исключения и вектор прерывания который нуна хватать

 

это предположение Думаю, что GP. Одно из двух - либо вернется в начало, либо исключение. И склоняюсь все-таки к исключению. Чересчур круто позволять запросто прыгать с 0-го адреса на fff0 к примеру, коротким джампом, или переходить с ffff на 0-й естественным образом. А если это не NOP, а скажем mov ax, 1234? начало инструкции по адресу FFFF, а окончание с нулевого? не, не верю. Будет попытка доступа за пределы сегмента, и GP.

 

Не будет никакого доступа за пределы сегмента, будет обычное закольцовывание IP. Контроль выхода за пределы сегмента возможен только в защищённом режиме, не говоря о том, что он выполняется путём простого сравнения смещения с пределом сегмента; если смещение корректно (а при семгенте полной длины оно всегда корректно), то никаких исключений не возникает. Какая инструкция находится, процессору глубоко плевать -- он просто выбирает байты один за другим в порядке возрастания адреса, причём за максимально возможным идёт нулевое смещение.

 

Хм. Разорванные инструкции. Наверное, возможна хитрая антиотладка. Даже в Windows. Наделать 16-битных дескрипторов и напихать на границы сегментов рваные прыжки. Надо будет попробовать...

 

l_inc
К слову:

 

Похоже, что в Пне Про допустили какую-то ошибку, из-за чего в защищёнке при пересечении границы 4 Гбайт при выборке команды он вёл себя не так, как более ранние процы. Что же касатеся Коре 2, то из этого описания вообще непонятно, что имеется в виду, ведь речь там идёт о превышении предела в 4 Гбайта, чего в 32-разрядном режиме не может быть, поскольку смещение всегда 32-разрядное. Возможно, здесь опять-таки речь об ошибке в некоторых процессорах, из-за которой инкремент адреса мог не "свернуться" (примерно как это имело место в 80286, где из-за ошибки появилась возможность адресовать больше 1 Мбайта в реальном режиме). Но в любом случае, это защищённый, а не реальный режим, #GP там попросту нет.

 

Clerk
Вообще речь не совсем об этом. Имелась в виду работа через границу 0FFFFh в 16-битном кодовом сегменте.

SII
Только что проверил. Такой код нормально бегает по кругу:

Код (Text):

1. macro enum start*,[name]
2. {
3.     common
4.             local cntr
5.             cntr = start
6.     forward
7.             name = cntr
8.             cntr = cntr + 1
9. }
10. BLINKER     = 7
11. BACKGROUND  = 4
12. LETTER      = 0
13.  
14. enum 0, BLACK,BLUE,GREEN,TURQ,RED,VIOL,BROWN,GRAY,\
15.         D_GRAY,L_BLUE,L_GREEN,AZURE,ORANGE,LILAC,YELLOW,WHITE
16. enum 0, NON_BLINKING,BLINKING
17.  
18. USE16
19. org 7C00h
20. jmp 0:start
21. start:
22.     push 800h
23.     pop es
24.    
25.     cld
26.     xor di,di
27.     mov cx,0FFFDh
28.  
29.     mov ax,stoswCode
30.     stosb
31.     mov ax,nopCode
32.     rep stosb
33.     mov ax,movCode
34.     stosw
35.    
36.     push 0B800h
37.     pop es
38.     xor di,di
39.     mov ax,((NON_BLINKING SHL BLINKER) OR \
40.             (BLACK SHL BACKGROUND) OR \
41.             (GRAY SHL LETTER)) SHL 8 OR 'A'
42. jmp 800h:0
43.  
44. rb (512-2-($-7C00h))
45. db 055h,0AAh
46.  
47. virtual at 0
48.     stosw
49.     nop
50.     mov al,'B'
51.     load stoswCode  byte from 0
52.     load nopCode    byte from 1
53.     load movCode    word from 2
54. end virtual

Но стоит 0FFFDh заменить на 0FFFEh, как даже запись слова через границу семента стопорится (т.е. до дальнего прыжка даже дело не доходит). А даже если по кускам записать инструкцию в первый и последний байт (в дальнем прыжке, разумеется, смещение меняем с 0 на 1), то mov al,'B' через границу семента тоже не исполняется (на экран выводится только одна буква А).
Всё вышесказанное проверялось на VMWare.

К сожалению в защищённом режиме не получилось даже достичь циклического пробега без разрыва инструкций. Следующий код (в частности его 16-битный фрагмент) спокойно отрабатывает, считывая данные по cs:eip, а не по cs:ip :

Код (Text):

1. format PE GUI 4.0
2. entry start
3. include 'win32a.inc'
4.  
5. LDT_Entry:
6. dw 0FFFFh    ;Младшие 16 бит лимита
7. .base1:
8. db 0h,0h,0h  ;Младшие 24 бита базы
9. .type:
10. db 11111010b     ;P: 1, DPL: 11 (ring3), S: 1, Type: 1010
11. db 00000001b     ;G: 0 - лимит в байтах, D/B: 0, L: 0, AVL: 0, 16-19 биты лимита: 0001
12. .base2:
13. db 0         ;Cтарший байт базы
14.  
15. start:
16.     invoke VirtualAlloc,NULL,20000h,MEM_COMMIT,PAGE_EXECUTE_READWRITE      
17.         mov dword[mem_ptr],eax
18.  
19.         lea edi,[eax+1000Ah-(remoteCodeEnd-remoteCode)]
20.         mov esi,remoteCode
21.         mov ecx,remoteCodeEnd-remoteCode
22.         rep movsb
23.  
24.         mov edx,eax
25.         and eax,000FFFFFFh
26.         shr edx,24
27.         or dword[LDT_Entry.base1],eax
28.         or dword[LDT_Entry.base2],edx
29.         invoke NtSetLdtEntries,27h,dword[LDT_Entry],dword[LDT_Entry+4],0,0,0
30.         and byte[LDT_Entry.type], not 1000b
31.         invoke NtSetLdtEntries,2Fh,dword[LDT_Entry],dword[LDT_Entry+4],0,0,0
32.         mov bx,2Fh
33.         jmp 27h:1000Ah-(remoteCodeEnd-remoteCode)
34.         beBack:
35.         invoke MessageBox,0,gotBack,gotBack,MB_OK
36.     invoke VirtualFree,dword[mem_ptr],0,MEM_RELEASE
37. invoke ExitProcess,0
38.  
39. data import
40.   library kernel32,'KERNEL32.DLL',\
41.       user32,'USER32.DLL',\
42.       ntdll,'ntdll.dll'
43.   import kernel32,\
44.      VirtualAlloc,'VirtualAlloc',\
45.      VirtualFree,'VirtualFree',\
46.      ExitProcess,'ExitProcess'
47.   import ntdll,\
48.      NtSetLdtEntries,'NtSetLdtEntries'
49.   import user32,\
50.      MessageBox,'MessageBoxA'
51. end data
52.  
53. align 16
54. remoteCode:
55. USE16
56.     push es
57.     mov es,bx
58.     xor bx,bx
59.     mov word[es:bx],'Fu'
60.     mov word[es:bx+2],'ck'
61.     pop es
62. USE32
63.     db 66h
64.     call @F
65.     @@:
66.     db 66h
67.     jmp 1Bh:beBack
68. remoteCodeEnd:
69.  
70. gotBack    db 'Got back',0
71.  
72. align 16
73. mem_ptr      dd ?

Если же старший бит лимит сбросить, то нарываемся на исключение.

 

*лимита

 

l_inc
то есть если код выравнен так что команды влезают целиком до границы все тип топ, но если какаято инструкция "ляжет брюхом" на границу то ласты ???

 

запись стопорится но выполнение на следующую итерацию идет ???
грубо говоря в первом случае у тебя ряд абабабаба
а вовтором аааааааааа
так????

 

l_inc
если записать инструкцию брюхом на границу чтоб до прыжка дело дошло???

 

биос выставляет обработчики исключений. Хотя бы в виде заглушек.
При возникновении исключения в стек убирается адрес следующей инструкции. Для 1-байтовой на адресе FFFF это будет 0000 (сегмент 16-битный). Обработчик просто проверит, что текущая инструкция ок, адрес возврата валидный - и нормально продолжится выполнение. Надо свой обработчик делать и смотреть - будет ли вызван при пересечении границы.

 

l_inc

Прверки ведь обычные выполняются, например лимита сегмента.

 

Кстате 16-битный код в защищенном режиме должен исполняться с взведённым флажком VM(V8086 режим), собственно это и есть вдм. Иначе префиксы просто урезают регистры.

 

Rockphorr
Что-то много слов и половина непонятных.

В общем да, но под "ляжет брюхом на границу" стоит понимать случай, когда первый часть инструкции находится в конце сегмента, а вторая в начале.

Запись стопорится, и соответственно управление дальше не идёт. На момент записи (этап подготовки зацикливающего сегмента) ни о каких итерациях ещё речи нет.

Нет. Если ни одна инструкция не ложится на границу сегмента, то пишется сначала одна A, потом много B. Потом, когда сегмент, начинающийся с видеопамяти, переполняется, поверх старой A записывается B. После этого на экране только B.
Если же mov al,'B' положить на границу сегмента (не одним stosw, а в два этапа, т.к. один stosw через границу прерывает работу кода), то в видеопамять пишется только одна буква A, потом управление доходит до разорванной инструкции и на этом код перестаёт работать.
FatMoon
Позже попробую. На какой там номер обработчик вешать?
Clerk

Они и в реальном режиме такие же должны выполняться. Просто я рассчитывал, что в 16-битном кодовом сегменте инструкции будут считываться по cs:ip, а не по cs:eip. Поэтому выхода за лимит не ожидалось при переполнении ip.

Какие префиксы? Нет никаких префиксов: 16-битный код в 16-битном кодовом сегменте. Не надо никаких префиксов.

 

я иммено это и подразумевал