Процессор Intel в защищенном режиме #5 — Архив WASM.RU

Все статьи

Процессор Intel в защищенном режиме #5 — Архив WASM.RU

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.

2002-2013 (c) wasm.ru