Виртуальное адресное пространство процессора Intel (IA32) в реальном режиме.

Да да! Оказывается, и в реальном режиме существует такое понятие.

Вообщем, все очень просто.

Виртуальный адрес в РЕАЛЬНОМ РЕЖИМЕ тоже состоит из двух частей:

сегмент:смещение

Максимальный виртуальный адрес в реальном режиме равен FFFFh:FFFFh, это очевидно. А сколько их ВСЕГО, этих ВИРТУАЛЬНЫХ АДРЕСОВ?

0000:00000000:00010000:0002...1234:5678...FFFF:FFFFровно FFFFFFFFh штук:)а это есть 4Гб

Т.е. вывод: виртуальное адресное пространство процессора Интел в реальном режиме составляет 4 Гб.

Теперь, вы конечно же слышали про параграфы. Значит, можете совершенно справедливо заметить, что адрес 0000h:0010h и адрес 0001h:0000h преобразуются в ОДИН И ТОТ ЖЕ ЛИНЕЙНЫЙ АДРЕС 00000010h!!! и будете СОВЕРШЕННО ПРАВЫ! В один и тот же ЛИНЕЙНЫЙ АДРЕС! Но фактически, на него указывают ДВА РАЗНЫХ виртуальных адреса.

;****************************************************************ПРАВИЛО ПОЛУЧЕНИЯ ЛИНЕЙНОГО АДРЕСА ИЗ ВИРТУАЛЬНОГО В РЕАЛЬНОМ РЕЖИМЕ:shl сегм.регистр, 4add сегм.регистр, смещениеЕсли кто не знаком с асмом то я поясню: shl - это сдвиг "влево" на 4 бита, add - это прибавление. На примере все станет ясно.Пример 1:1234h:5678hСдвинуть 1234h на 4 бита влево. Получаем 12340h.Прибавляем 5678h. Получается: 12340h+5678h=179B8hТ.е. вирт. адрес 1234h:5678h = лин. адресу 179B8hПример 2:0001h:0000hСдвинуть 0001h на 4 бита влево. Получаем 0010h.Прибавляем 0000h. Получается: 0010h+0000h=0010hТ.е. вирт. адрес 0001h:0000h = лин. адресу 0010h;*****************************************************************

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

Кстати, вот еще вопросец (пусть ответит, кто хочет): приведите пример линейного адреса, который можно получить максимально возможным количеством РАЗЛИЧНЫХ виртуальных адресов.

Ну вот вышеприведенный пример, линейный адрес 00000010h можно получить ТОЛЬКО (!) из двух разных виртуальных адресов. Но ведь, допустим, линейный адрес 00000020h можно получить уже ИЗ ТРЕХ РАЗЛИЧНЫХ ВИРТУАЛЬНЫХ АДРЕСОВ, а именно:

0000h:0020h0001h:0010h0002h:0000h

и все эти три виртуальных адреса - это линейный адрес 00000020h!!

В РЕАЛЬНОМ РЕЖИМЕ ЛИНЕЙНЫЙ АДРЕС ВСЕГДА СОВПАДАЕТ С ФИЗИЧЕСКИМ (ВЫСТАВЛЯЕМЫМ НА АДРЕСНУЮ ШИНУ) (кстати, как и в случае сегментной адресации в защ. режиме).

Вывод: линейный адрес НЕ совпадает с физическим ТОЛЬКО при страничной адресации в защ. режиме.

Процессор INTEL в защищённом режиме #11

Защита

Данный выпуск я бы назвал самым идейным и важным из всего цикла, т.к. он повествует о самой сердцевине защищенного режима и любой современной ОС - о самом механизме защиты. Более того - в аннотации к рассылке можно увидеть слова из небезызвестной книги Зубкова С.В.: "...управление защищенным режимом в современных процессорах Intel - это самый сложный раздел программирования". От себя хочу добавить, что в этом разделе программирования глава "Механизм защиты" является самой сложной (хотя на самом деле все очень просто, сами убедитесь в этом).

Самый (опять это слово:), оно еще не раз встретится в данном выпуске, тема обязывает) главный вопрос, от которого и нужно плясать - так что же от чего все таки нужно защищать?

Для того чтобы понять суть происходящего обязательно нужно взглянуть на дело с high level. Представим картину: на столе стоит компьютер, из колонок льются шедевры самой лучшей mp3-коллекции в мире, на экране открыто несколько окон любимого браузера, где-то в углу досматривается фильм (с выключенным звуком естественно, чтоб не мешать музыке), пара документов свернута в панель задач, тут же на столе остывает чашка кофе... (кофе тут не при чем, просто для полноты картины). И тут возникает вопрос: как все это безобразие может сосуществовать в одном ящике? Как бедный несчастный процессор обрабатывает такой огромный поток данных и успевает все вовремя просчитать и не перепутать ни одного байта? Все это и многое другое обеспечивается благодаря механизму защиты.

Как можно убедиться на практике, связать аппаратные механизмы защиты с программными разработчикам из Microsoft (по крайней мере до Win2000) удавалось крайне плохо: в 99% "синих окон смерти" повинны дыры и недоработки именно в реализации защитных механизмов. Отчасти это вызвано кривыми руками разработчиков ОС, отчасти - кривой реализацией аппаратной защиты (да да! Почему то все любят спорить о глючности той или иной ОС, и никто никогда не скажет: "да этот процессор глючный, в нем много дыр и недоработок". Просто следует иметь ввиду, что аппаратная часть обычно не лишена недостатков программной. Это интересная тема, ее можно развить и дальше, однако в конце концов можно прийти к выводу, что защита в IA-32 реализована настолько слабо и непродуманно (или что ее как-то не очень удобно "связать" с программной частью), что нет никакого смысла вообще о ней говорить. Это не так (во всяком случае, пока я набираю этот текст в Word-е, комп ни разу не завис).

Не нам об этом судить, но придет время, когда все современные методы и аппаратные механизмы вызовут лишь улыбку у гения инженеров будущего…

Итак, давайте не будем о грустном и, наконец, перейдем к делу (уже давно пора). В процессорах с архитектурой IA-32 защитные механизмы реализованы как на сегментном, так и на страничном уровнях (т.е. после включения страничной адресации нам предоставляются некоторые дополнительные возможности защиты, которые, вообще говоря, без страничной адресации не имеет смысла применять). Процессор различает четыре уровня сегментной защиты (3-0) и два - страничной (здесь номеров нет, но условно их два). Чем уровень ниже (численно), тем сегмент круче. Так, весь код ядра ОС, дрова устройств и другие распальцованные сущности помещают в сегменты с НУЛЕВЫМ (самый крутой) уровнем привилегий. Если перенести картину в нашу реальность, то в таких сегментах можно смело размещать код депутатов Госдумы, работников СБУ и всех, кто как говориться "когда идет по улице задевает всё пальцами". Простым смертным сюда вход строго воспрещен (только по пропускам, выданным вышеперечисленными ребятами, хотя "имея связи" в таблице дескрипторов прерываний (все как в жизни) сюда может запросто проникнуть любой директор колхоза "Красные маки" с 3 уровня привилегий (кстати, это не дыра, просто по другому было невозможно реализовать...), но об этом в следующем выпуске).

Механизм защиты обеспечивает проверку КАЖДОГО (!) обращения к памяти (естественно, до цикла чтения/записи). Любое нарушение границ и других законов, предписанных УК IA-32 (все статьи внимательно рассмотрим) - генерация исключения (что может привести к любым последствиям - вплоть до высшей меры наказания - расстрела приложения-нарушителя). Пожизненного заключения УК не предусматривает, т.к. процессор полностью свободен от морально-нравственных и т.п. сомнительных ценностей (последнее можно запросто вырезать цензурой).

Следует отметить, что все проверки производятся ПАРАЛЛЕЛЬНО с процедурой преобразования адресов, поэтому задержка на проверку отсутствует. Условно УК IA-32 можно разделить на 6 разделов:

• Проверка границ
• Проверка типов
• Проверка уровней привилегий
• Ограничения на адресацию
• Ограничения на использование инструкций
• Ограничения на точки входа в процедуры (?)

(название последнего раздела - мой кривой перевод из официального мануала, по ходу разберемся, что именно интеловцы здесь имели ввиду:).

Как уже говорилось ранее, нарушение любой статьи из любого раздела УК IA32 влечет генерацию прерывания и в зависимости от степени нарушения - соответствующие последствия для провинившегося. В ОС типа Win 9x любого нарушителя ждала одна и та же участь - расстрел на месте (поэтому Win 9x больше подходит под определение ОС 30-х годов прошлого века). В Win NT к власти пришли более разборчивые и творческие личности, здесь нарушитель в зависимости от степени нарушения может отделаться "легким испугом" J либо небольшим заключением в местах не столь отдаленных (подождет, когда ему будет "можно"). Этим NT более подходит под определение современной гуманной ОС.

Подводя итог вышеизложенного (по существу было сказано два предложения, однако не всякая мишура лишена смысла...) можно сказать, что процессор - очень напоминает то, что юристы понимают под термином "государство": суверенная, универсальная организация политической власти, призванная обеспечить нормальную жизнедеятельность людей, имеющая свою территорию, аппарат принуждения и взимающая налоги, необходимые для осуществления внутренних и внешних функций (запоминать не нужно). Процессор полностью подходит под это определение (разве что только налоги не взимает:). Как и в любом государстве в процессоре своя вертикаль власти, и самой важной составляющей все же является служба безопасности.

Очень важно понять: государство (читай - процессор) НЕ принимает решения самостоятельно, он просто констатирует уже свершившиеся факты, ПРОЦЕССОР НЕ МОЖЕТ убить программу (насильно завершить ее выполнение) - все решения принимают люди, населяющие данное государство (читай - программная реализация). Мозг власти (Госдума) - это не что иное, как обработчик исключения #GP и смежных с ним ведомств и подведомств (обработчики других исключений типа fault). Все зависит только от их реализации.

Вообще другой вывод (не менее важный) напрашивается сам собой - все сложные системы похожи друг на друга как близнецы.

Глава I ОБЩИЕ ПОЛОЖЕНИЯ (важно прочитать и запомнить!)

В это трудно поверить, но весь механизм защиты процессора Intel обеспечивается 3-мя флагами (+ еще 2 дополнительных при использовании страничной адресации) и 5-тью полями. Казалось бы, какую защиту могут обеспечить эти несчастные 8 (+2 до кучи) ребят? На самом же деле все довольно продумано и все чего надо они обеспечивают.

Флаги, обеспечивающие защитный механизм: (просто запомните их)

• Тип дескриптора (S) - бит 12 во втором двойном слове дескриптора сегмента. Собственно, отвечает за тип сегмента: системный, кода или данных.
• Флаг гранулярности (G) - бит 23 во втором двойном слове дескриптора сегмента. Вместе с полем "Лимит" дескриптора и флагом E (флаг направления роста) определяют размер сегмента.
• Флаг направления роста сегмента (E) - бит 10 во втором двойном слове дескриптора сегмента. Работает на пару с флагом G и полем "Лимит".
• Флаг пользователь/супервизор (U/S) - бит 2 элемента таблицы или каталога страниц. Определяет тип страницы: пользовательская или супервизорная. В прошлом выпуске упоминалось, что при использовании страничной адресации доступны некоторые дополнительные защитные механизмы. Этот флаг - один из них.
• Флаг чтения/записи (R/W) - бит 1 элемента таблицы или каталога страниц. Определяют тип доступа к странице: только для чтения или для чтения/записи. Флаг R/W - второй (он же последний) дополнительный механизм защиты при использовании страничной адресации.

Поля, обеспечивающие защитный механизм: (просто запомните их)

• Поле "Тип" - биты 8-11 во втором двойном слове дескриптора сегмента. Определяет тип сегмента кода, данных или системного сегмента. В принципе, работает на пару с флагом S (см. выше).
• Поле "Лимит" - биты 0-15 первого двойного слова и биты 16-19 второго двойного слова дескриптора сегмента. Вмести с флагом G и E определят размер сегмента. С этим полем все ясно.
• Поле "Уровень привилегий дескриптора" (DPL) - биты 13 и 14 во втором двойном слове дескриптора сегмента. Название поля немного сбивает с толку - на самом деле поле DPL задает уровень привилегий описываемого им сегмента, дескриптору уровень привилегий по сути ни к чему. Чем меньшее значение содержит это поле, тем описываемый сегмент круче (0 - самый крутой, 3 - сегмент-лох). Чем же крутой сегмент круче сегмента-лоха? Да всем. Сегмент с нулевым уровнем привилегий может исполнять ЛЮБЫЕ инструкции, обращаться к ЛЮБЫМ данным. По задумке, в сегментах с 0-ым уровнем должно располагаться ядро ОС, другие части ОС - в сегментах с 1-ым уровнем, драйвера - со 2-ым, пользовательские программы - с 3-им. На деле программисты из Microsoft при проектировании ОС "Винды" решили "упростить" модель до двухуровневой: все что не пользовательские программы - то в 0-ом уровне, пользовательские - в третьем. 1-й и 2-й уровни не используются. По сути, если бы Intel IA32 эксплуатировался только под осью Windows (что и происходит в 90% случаях), то для полей DPL, RPL и CPL с головой хватило бы одного бита вместо двух:) и инженеры Intel-а немного перестарались.
• Поле "Запрашиваемый уровень привилегий" (RPL) - биты 0 и 1 ЛЮБОГО (!) сегментного селектора. Кто у кого чего запрашивает и зачем вообще это поле - это отдельная песня, она будет в следующей главе.
• Поле "Текущий уровень привилегий" (CPL) - биты 0 и 1 сегментного регистра CS (!). Фактически определяет уровень привилегий ТЕКУЩЕЙ исполняемой программы (процедуры), в общем - уровень привилегий исполняемого в данный кода.

THAT'S ALL! (это все!). Вся аппаратная защита такого монстра, как, скажем, Pentium 4, целиком и полностью стоит на описанных выше битиках! (я от нечего делать даже подсчитал - всего 35 бит! Т.е. все аппаратные защитные структуры умещаются (почти) в одно двойное слово! Честно говоря, это немного шокирует...

Если кому-то вздумается взглянуть на картинки - они есть в предыдущих выпусках.

Глава II НАРУШЕНИЕ ГРАНИЦ

Поле "Лимит" дескриптора сегмента призвано уберечь программы (процедуры) от незаконного обращения к памяти за пределами, установленными этим полем. Эффективное (реальное) значение лимита зависит от флага гранулярности G. Для сегментов данных, лимит также зависит от флага E (направление роста) и флага B дескриптора.

Влияние бита G на поле "Лимит" изучено и рассмотрено со всех сторон в предыдущих выпусках, но напомню: если бит G=0, то лимит сегмента совпадает со значением одноименного поля дескриптора; очевидно, что в данном случае сегмент может иметь длину от 0 до FFFFFh (1Мб). Если флаг G=1, то реальный лимит сегмента равен содержимому поля "Лимит" дескриптора, умноженному на 4Кб (FFFh). Очевидно, сегмент в этом случае может занимать от 4Кб до 4Гб.

ВАЖНО! Если бит G=1, то младшие 12 бит адреса НЕ ПРОВЕРЯЮТСЯ НА ПРЕВЫШЕНИЕ ЛИМИТА! Т.е. если создать дескриптор сегмента с G=1, и полем "Лимит" равным 0, то смещения от 0 до FFFh ВСЕ РАВНО ДОСТУПНЫ ДЛЯ ОБРАЩЕНИЯ! Т.е. процессор ИГНОРИРУЕТ младшие 12 бит при проверке на превышение лимита. Вообще, как где-то было верно подмечено, бит гранулярности - это чисто радиолюбительский трюк. Что еще небезынтересно знать - умножение на 4Кб равносильно сдвигу на 12 влево, причем младшие 12 бит при этом заполняются единицами.

Итак, процессор сгенерирует исключение #GP (самое страшное и главное, недаром ему присвоили 13 номер) в следующих случаях:

• Обращение к байту по смещению БОЛЬШЕМУ, чем эффективный лимит
• Обращение к слову по смещению БОЛЬШЕМУ, чем (эффективный лимит-1)
• Обращение к двойному слову по смещению БОЛЬШЕМУ, чем (эффективный лимит-3)
• Обращение к учетверенному слову по смещению БОЛЬШЕМУ, чем (эффективный лимит-7)

Это 4 заповеди данной главы.

Существует еще один размытый момент, который мы сейчас обсудим во всех нюансах. Этот момент - растущие "ВНИЗ" сегменты данных. Тут сразу нужно сказать - сегмент никуда не растет, это образное выражение. Все дело в том, что у растущих "ВНИЗ" сегментов поле "Лимит" в дескрипторе определяет НИЖНЮЮ границу сегмента, а ВЕРХНЯЯ граница ВСЕГДА (!) (подчеркнуть три раза) равна FFFFh (1Мб) если бит B=0 и FFFFFFFFh (4Гб) если бит B=1. Откуда взялся бит B? Вспоминаем структуру дескриптора, помните флаг D/B? Вот это он и есть. Теперь у некоторых возникает вопрос: если у нас определена НИЖНЯЯ граница сегмента (поле "Лимит") и верхняя (1Мб или 4Гб), то нахрена тогда поле БАЗА в дескрипторе? Спокойно! Стоит лишь чуть-чуть подумать и все станет ясно: поле "Лимит" хоть и определяет нижнюю границу, но все равно ОТСЧИТЫВАЕТСЯ ОТ БАЗЫ! Т.е. фактически нижняя граница у растущих ВНИЗ сегментов равна: содержимое поля "Лимит" дескриптора + содержимое поля "База" дескриптора. Вот для того нам база и нужна... (вообще с тем что поле "Лимит" всегда зависит от поля "База" интеловцы imho погорячились, т.к. весь этот механизм в конечном счете выгоден только при использовании 36-разрядного механизма адресации PAE-36. У кого есть какие-нибудь соображения на этот счет - прошу поделиться).

Здесь интересен другой момент (подумайте и вышлите свои соображения на [e-mail]): если у нас есть растущий ВНИЗ сегмент, у которого сброшен бит B, т.е. верхняя граница этого сегмента равна FFFFh, а поле "База" в дескрипторе ПРЕВЫШАЕТ значение 1Мб. Кто может ответить - какие смещения доступны в таком сегменте?

Наконец, позволю себе привести фрагмент из книги тов. Зубкова С.В. по поводу растущих вниз сегментов: "Бит направления роста сегмента (E) обращает смысл лимита сегмента. В сегментах с этим битом, сброшенным в ноль, разрешены абсолютно все смещения от 0 до лимита, а если этот бит 1, то допустимы все смещения, кроме от 0 до лимита. Про такой сегмент говорят, что он растет сверху вниз, так как если лимит, например, равен -100, допустимы смещения от -100 до 0, а если лимит увеличить, станут допустимыми еще меньшие смещения". Здесь уважаемый Зубков запорол страшную ерунду, т.к., во-первых, не "от 0 до лимита", а от "(базы) до (база+лимит)", и в случае растущих вниз сегментов, помимо той же самой ошибки, он рассмотрел только случай когда B=1 (т.е. верхняя граница равна 4Гб), тогда действительно доступны ВСЕ смещения, кроме от база+лимит до 0 ("вниз"). Да и с примером он тоже намудрил. Если кто-то не согласен - пишите, обсудим.

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

Данная глава была бы не полной, если не вспомнить о том, что процессор (помимо проверки лимитов сегментов) проверяет также лимиты таблиц дескрипторов, инфа о которых содержится в регистрах GDTR, IDTR, LDTR и TR. #GP будет сгенерировано, если произойдет попытка обращения к дескриптору, лежащему за пределами таблицы дескрипторов.

Вот теперь по теме "Проверка границ" больше добавить действительно нечего. В следующем выпуске мы рассмотрим следующую главу УК IA-32 под названием "Проверка типов".