ПРОЦЕССОР INTEL В ЗАЩИЩЕННОМ РЕЖИМЕ

 

Выпуск №5

__________________________________________________

 

Prelude:

 

Мда... Чето не везет мне с рассылкой. Вот новый дизайн придумали (спасибо Maverick-у), а он почему то ни перед кем не хочет во всей красе предстать... Самое интересное то, что ко мне, как к подписчику, пришел полноценный, рабочий вариант, и даже в архив специально лазил – все прекрасно открывается. Но вот уже у трех человек траблы, поэтому возвращаю рассылке старый, убогий и огромный прикид... (кстати, огромен он оттого, что клепаю я ее в ворде, а он почти к каждой букве лепит шрифт, размер и цвет, поэтому и весит под мамонта). Может кто подскажет что с этми всем беспределом делать? Интересно, есть ли хоть один читатель у которого не было с пятым выпуском никаких проблем?

Кстати, здесь есть 3 важные картинки, поэтому дождитесь их полной загрузки...

 

 

FAQ:

 

- Чето ты с этими лимитами нездорового напорол в спецвыпуске... Какие то «реальные лимиты», «лимиты в натуре» и т.п. Нельзя ли обойтись без подобных медитаций, просто, как есть на самом деле?

Вообще все это напоминает недавний бум с миллениумом: в 1999 году все СМИ как один гудели про то, что новое тысячелетие начнется в 2000 году. Потом посчитали и оказалось, что в 2000 начнется только ПОСЛЕДНИЙ ГОД УХОДЯЩЕГО ТЫСЯЧЕЛЕТИЯ, а новое начнется только в 2001... Вот и я туда же - начал выдумывать какие то "реальные лимиты", к-рые соотвествуют "концу последнего байта в сегменте" и т.п. медитации. Хотел как лучше, получилось как всегда... :(
Вот КАК В ШЕСТИ СТРОЧКАХ ВСЕ ВЫГЛЯДИТ НА САМОМ ДЕЛЕ, без вольных импровизаций и медитаций:


При G=0:

Адрес последнего байта сегмента = Значение поля «База сегмента» + Значение поля «Лимит сегмента»

Размер сегмента = Значение поля «Лимит сегмента» + 1


При G=1:

Адрес последнего байта сегмента = Значение поля «База сегмента» + Значение поля «Лимит сегмента» * 1000h + 0FFFh

Размер сегмента = Значение поля «Лимит сегмента» * 1000h + 1000h



Вообще, ВОТ С ЭТОГО и стоило начинать, и на этом и закончить, ато расписал на 2 выпуска + спецвыпуск какой то мути, всех запутал и напугал новичков... Вообще на этой проблеме не стоит сосредотачиваться, нас ждут вещи поважнее.

 

 

РЕЗУЛЬТАТЫ КОНКУРСА:

 

Правильные ответы:

 

1. Descr_code           db    34h,12h,00h,00h,00h,XXh,0X000000b,00h

; сегмент с базой = 0 и размером = 1235h

 

2. Descr_data           db    0C8h,0Dh,36h,12h,00h,XXh,0X100000b,00h

; сегмент с базой = 1236h и размером = 0DC9h

 

3. Descr_stack          db    0FFh,00h,00h,20h,00h,XXh,1X000000b,00h

; сегмент с базой = 2000h и размером = 100000h

 

4. Descr_code2          db    0DEh,0BCh,01h,20h,10h,XXh,0X001010b,00h

; сегмент с базой = 102001h и размером = 0ABCDFh

 

5. Descr_data2          db    00h,00h,00h,00h,00h,XXh,0X000000b,10h

; сегмент с базой = 10000000h и размером = 1

 

6. Descr_stack2         db    01h,00h,10h,00h,00h,XXh,0X000001b,10h

; сегмент с базой = 10000010h и размером = 10002h

 

7. Descr_LDT            db    04h,00h,00h,00h,00h,XXh,1X000000b,20h

; сегмент с базой = 20000000h и размером = 5000h

 

 

Дополнительные задания:

 

Ошибка во втором дескрипторе: бит 21 во втором двойном слове дескриптора ДОЛЖЕН ВСЕГДА равняться нулю.

 

Те, кто знакомы с компиляторами типа TASM без труда смогут загрузить GDTR так:

 

mov eax,offset GDT

mov dword ptr GDTR+2,eax

lgdt fword ptr GDTR

(но вообще это забегая вперед)

 

 

 

Краткое содержание предыдущих серий…

 

Итак, сначала ты узнал, что программа состоит из сегментов и все они расположены в памяти. Каждый сегмент описывает специальная структура – дескриптор. Дескриптор хранится в специальной таблице. Найти в океане памяти таблицу можно по специальному регистру (GDTR, LDTR). Это как в той сказке: на острове – дуб, на дубе ларец, в ларце – яйцо, в яйце – игла и т.д. Ну и с битом гранулярности вроде разобрались (слава Богу!), теперь пора двигать дальше.

 

 

 

Селектор

 

«Все это хорошо и понятно» - скажешь ты,- «но вот что-то я ничего пока не слыхал про сегментные регистры (ну те самые – CS, DS, SS…). Что-то они себя пока никак не проявили, а мне казалось, что именно ОНИ, как никто другие, должны служить нам при обращении к памяти и все такое…»


Если ты заметил, то мы все это время спускаемся вниз по ступенькам:

сегмент в памяти <---- дескриптор <---- таблица дескрипторов …


Следующей ступенью будет СЕЛЕКТОР. Не правда ли, где-то это слово уже встречалось? Так вот: селектор – это 16-битная структура данных (что??!! ОПЯТЬ??!!!...), которая является идентификатором сегмента.

- Боже ж ты мой! Сколько это будет продолжаться??!! У каждого сегмента есть свой дескриптор, мы уже прекрасно знаем где этот чертов дескриптор расположен, а ты нам подсовываешь еще какой-то «селектор»!!!

… Селектор указывает не на САМ сегмент в памяти, а на его дескриптор, в таблице дескрипторов… СЕЛЕКТОР ЖИВЕТ В СЕГМЕНТНОМ РЕГИСТРЕ (CS, DS…).


-Неужели…?! Ну и хрена с того ?


Спокойно!!!! Вот он:




 

 

Поле ИНДЕКС (биты 3-15): указывает на один из 8192 дескрипторов в таблице дескрипторов (GDT или LDT). Почему 8192? А какое максимальное число по-твоему влезет в «биты 3-15»? Во-во…


-Подожжи, подожжи… не так быстро… Ведь дескриптор же занимает 8 байт так? А если индекс равен двойке? Так что это, значит, селектор указывает на второй байт дескриптора в таблице или что?


ИЛИ ЧТО! ПРОЦЕССОР УМНОЖАЕТ значение поля ИНДЕКС НА 8 И ДОБАВЛЯЕТ к полученному значению АДРЕС БАЗЫ ТАБЛИЦЫ. Т.е. процессор умножит «двойку» на 8, а потом прибавит значение регистра таблицы – и мы благополучно указываем НА НАЧАЛО ДЕСКРИПТОРА, как не крути!!!


-Как же узнать, из КАКОЙ ИМЕННО ТАБЛИЦЫ дескриптор?


Вот для этого нужен флажок TI (table indicator) (второй бит). Если он = 0, то прибавится значение регистра GDTR (т.е. дескриптор расположен в таблице GDT), если же установлен – LDTR.

шо за RPL?


(Requested Privilege Level) Запрашиваемый уровень привилегий… пока его лучше не трогать. Но видишь, пока что, все что нам не знакомо относится к каким то загадочным уровням привилегий…


Теперь внимательно следи: допустим мы ложим в DS число 0000000000110 0 00b. Что это значит? А смотри: сразу разбиваем DS на кусочки (15-3 биты – индекс, 2 – TI, 1-0 – пока лучше не смотрим на них). Индекс равен 6. Значит, шестой по счету дескриптор. А где? В GDT конечно! (TI=0).


Ложим (кладем :) в ES число 0000000001000 1 00b. Восьмой дескриптор! На этот раз в LDT! Разобрались!


-А учитывается ли нулевой дескриптор (null descriptor) при «счете»?

ОБЯЗАТЕЛЬНО! БОЛЕЕ ТОГО! МЫ ДАЖЕ МОЖЕМ ПОЛОЖИТЬ В сегментный регистр (DS, SS…) СЕЛЕКТОР С ПОЛЕМ ИНДЕКС и TI РАВНЫМИ 0!!! Т.е. фактически мы выбираем НУЛЕВОЙ ДЕСКРИПТОР В ТАБЛИЦЕ GDT!!


-Но это же невероятно и невозможно!!!! :)

 

Возможно… Ничего страшного не произойдет до тех пор, пока мы не ОБРАТИМСЯ К ПАМЯТИ, используя ТАКОЙ сегментный регистр… А так он может хоть сто лет там пролежать, но как только мы обратимся к памяти используя такой регистр (с индексом = 0) – ВСЕ! ХАНА! #GP!!!!

 

 

 

Преобразование логического адреса в линейный

 

И вот мы подобрались к самому важному моменту: как же все таки процессор формирует адрес и знает куда обращаться? Для этого нужно собрать все полученные нами знания в кучу. Что для этого нужно сделать? Уважаемый читатель, представь, что ты процессор...

Допустим, сейчас ты выполняешь какой то код в оперативной памяти. И вот как ты размышляешь: о местоположении в памяти инструкции тебе ничего не известно, кроме того, что на нее указывает CS:EIP. По сути - это логический (т.е. некий абстрактный адрес). Как же найти линейный адрес в памяти, руководствуясь только этими двумя значениями: CS и EIP? Теперь мы можем это сделать! Сразу смотрим в CS и ищем в нем поле "Индекс" (см. на селектор выше). Смотрим в поле индекс и тут же узнаем о местоположении нужного дескриптора в таблице дескрипторов. Далее нам нужно узнать АДРЕС БАЗЫ сегмента. Узнали. Что теперь? Теперь осталось только одно: сложить этот адрес базы с EIP - и мы получим линейный адрес инструкции в памяти (к-рый при сегментной организации совпадает с физическим, мы об этом говорили ранее). Еще раз: селектор-->дескриптор-->база... +EIP = ЛИНЕЙНЫЙ адрес.







Сегментный регистр

 

В архитектуре процессоров Intel существуют ШЕСТЬ сегментных регистров:
CS, DS, SS, ES, GS и FS. Каждый из этих регистров отвечает за свой сегмент в памяти (кода, данных или стека). Итак, даже если программа состоит из ТЫСЯЧИ сегментов, ТОЛЬКО 6 из них могут быть доступны В ДАННЫЙ МОМЕНТ ВРЕМЕНИ. Другие сегменты станут доступны ТОЛЬКО ПОСЛЕ ЗАГРУЗКИ СООТВ. селекторов в сегментные регистры.

Помнишь, как в реальном режиме формировались линейные адреса? Значение сегментного регистра умножалось на 10h и прибавлялось смещение. Т.е. никакого селектора явно не существовало, никаких дескрипторов, ничего! Только сегментный регистр и смещение! Один шаг до формирования линейного адреса! В защищеном режиме нужно пройти сквозь огонь, воду и медные трубы (селектор-дескриптор-база...) чтобы докопаться до линейного адреса... Итак, в защищенном режиме сегментный регистр - это 16 битный регистр, содержащий информацию о дескрипторе (а именно - местоположении) и запрашиваемом уровне привилегий. Стоп! Здесь сразу же возникает вопрос: неужели же процессор при каждом обращении к памяти все время повторяет одни и те же действия (ищет дескриптор, потом ищет базу, затем прибавляет к базе смещение...), и так при выполнении фактически каждой команды... КОНЕЧНО ЖЕ НЕТ! НА САМОМ ДЕЛЕ сегментный регистр - это 80-битный регистр (!!! да да !!!), нам же доступны ТОЛЬКО младшие 16 бит, которые и называются СЕЛЕКТОРОМ!!! Остальные 64 бита называются "Теневым регистром" (Shadow register) или "Дескрипторным кэшем" (Descriptor cache), ОНИ И СОДЕРЖИТ ТУ САМУЮ БАЗУ, которую проц по идее должен был бы высчитывать на каждом шаге. Кроме базы этот самый "теневой регистр" содержит еще и лимит, и права доступа. Еще раз: как только мы загружаем в ВИДИМУЮ ЧАСТЬ (в селектор) соответствующее значение, процессор СРАЗУ же по селектору (а конкретно - по полю индекс) выпасает базу, лимит и права доступа из дескриптора и заносит их в "теневую часть" сегмнетного регистра, тем самым облегчая себе жизнь в дальнейшем.

А ТЕПЕРЬ ВНИМАНИЕ!!!

Если мы вдруг решим неожиданно поменять значение базы в дескрипторе для какого-либо сегмента, селектор которого в данный момент УЖЕ находится в сегментном регистре, то мы также должны позаботиться и о ПЕРЕЗАГРУЗКЕ сегментного регистра, т.к. в теневой части остануться СТАРЫЕ ЗНАЧЕНИЯ базы и лимита, и фактически процу абсолютно наплевать на то, что твориться в таблице дескрипторов, он руководствуется только ТЕКУЩИМ ЗНАЧЕНИЕМ БАЗЫ И ЛИМИТА В ТЕНЕВОЙ ЧАСТИ. Короче запомни золотое правило: поменял базу (или лимит) в дескрипторе - перегрузи соотв. сегментный регистр!!!


Загрузить сегментные регистры (явно или неявно) позволяют 16 команд:


ЯВНО:
MOV     - ну это и так ясно

POP     - значение из стека

LDS     - загрузить DS

LES     - загрузить ES

LSS     - загрузить SS

LGS     - загурзить GS

LFS     - загрузить FS


НЕЯВНО:
CALL, JMP, RET, SYSENTER, SYSEXIT, IRET, INTn, INTO, INT3.
Чаще всего "неявные" команды изменяют значение именно CS-регистра, но в некторых случаях и других.

Кстати, как ты понимешь, в реальном режиме архитектура проца никуда не девается, при загрузке селектора в сегм. регистр процессор сам создает соответствующий дескриптор в его сркытой части. Он описывает 16-битный сегмент, начинающийся по указанному адресу с границей 64 Кб.

p.s. если инструкции LCS не существует в документации Интела, это не значит что ее не существует вообще. Я где то читал про это, просто интел в таблицах опкодов оставила для нее рядом с соотв. инструкциями lds, lss... пустой квадратик. Сейчас найти не могу. Кто об этом что то знает - мыльните пожалста.

На сегодня все. Пишите письма... brokensword@mail.ru

 

Hosted by uCoz