Как Windows блокирует обращение к памяти, инструкциям?

[Иришка-кодер]

Здравствуйте! Мне не понятен принцип блокировки обращения к памяти в Windows. Я знаю что система работает на уровне ядра (Kernel mode) и имеет полный доступ к адресному пространству и инструкциям процессора. Прикладные программы работают в пользовательском режиме (User-mode), и для них уже отсутствует поддержка привелегированных инструкций, и для обращения к памяти ее надо резервировать и выделять. Собственно вопрос. Как система блокирует запись в память и выполнение инструкций. На ум приходит только то, что либо процессор при обращении к привелигированным инструкциям генерирует прерывание, а система (ядро) его обрабатывает и выдает ошибку, либо программа каждую инструкцию выполняет через виртуальную машину и каждая инструкция проверяется (но это же очень медленно!!!). Помогите!

[Хакер]

Как система блокирует запись в память и выполнение инструкций.

Это не заслуга системы, это возможность процессора, вложенная в него «на уровне транзисторов». Создатели процессора сделали в нём поддержку защищённого режима, суть которого, помимо всего прочего, сводится к тому, что для каждой страницы памяти программа (в нашем случае этим пользуется ОС) может указать, можно ли эту страницу памяти читать/выполнять, и можно ли в неё писать.

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

А если нельзя, тогда процессор инициирует исключение. Что делает обработчик исключения — процессору пофигу. Что хочет, пусть то и делает. Тот обработчик, который назначила Windows, делает то, что мы знаем.

А разервирование/выделение памяти не имеет к этому (к контролю доступа) никого отношения.

[Иришка-кодер]

Спасибо!

[Qwertiy]

А можешь подробнее рассказать? Например, где хранится информация о том, что можно делать, как она изменяется и т. д.

[Хакер]

Есть регистр CR0. Это флаговый регистр, флаги которого влияют на то, какие фичи процессора включены. То есть просто бит 1 — значит фича включена, бит 0 — фича не включена.

0-ой бит например называется PE (Protected Enabled) и определяет, включен ли защищённый режиме или нет.
31-ый бит называется PG (PaGing Enabled) и определяет, используется ли в добавок к сегментной (которая используется абсолютно всегда) ещё и страничная организация памяти.

Если используется, то есть регистр CR3. Естественно, что доступ к нему тоже только привилегированным кодом.

Часть регистра CR3, а если конкретнее, старшие 20 битов, считаются субрегистром PDBR. Расшифровывается как Page-Directory-Base Register. Регистр базы директории страниц. Правда в русском языке директорию страниц принято звать каталогом страниц.

Собственно каталог страниц — вещь элементарнейшая. Это просто обыкновенный массив структур, одинаковых повторяющихся элементов.
А база каталога страниц — это просто адрес начала этого массива, то есть адрес первого элемента этого массива, первой структурки.

Элемент этого массива (то есть каталога страниц) называется PDE. Page Directory Entry. Размер одного элемента (то есть размер PDE) — всего лишь 4 байта, то есть DWORD, как Long-переменная. Так что структурой с точки зрения VB-программиста это назвать сложно. Однако это всё-таки структура, ибо это 32-битное поле состоит из одного большого 20-битного поля и 12 однобитных флаговых полей.

Самое главное здесь это 20 битное поле в составе PDE. Это поле — адрес начала другой таблицы.

Эта другая таблица — Page Table — то есть таблица страниц. Практически такой же массив, как Page Directory (каталог страниц).
Элемент такого массива называется PTE (Page Table Entry). И он тоже 4-байтный, то есть 32-битный. И он тоже (как и PDE), состоит из одного большого 20-битового поля и 12 однобитных флаговых полей.

Смысл PTE-шки в том, что она описывает отдельно взятую страницу виртуального адресного пространства и ставит ему в соответствие конкретную отдельную страницу физической памяти. Самой что ни на есть физической — то есть непосредствнно RAM-а.

Большое 20-битное поле в составе PTE-шки — это физический адрес физической страницы в физической памяти. А оставшиеся однобитовые флаги как раз и определяют: можно ли читать страницу, можно ли писать в страницу, присутствует ли страница в физической памяти (или она в своп-файле), и была ли она изменена с момента последнего сброса в файл подкачки (процессор просто устанавливает этот бит при каждой записи в страницу, но он никогда не сбрасывает этот бит, ибо сбрасывать его — право (или обязанность?) операционной системы, ибо именно она заведует вопросами подкачки, которой может и вообще не быть в какой-нибудь ОС).

Собственно, ещё раз кратко:
CR3, он же, грубо говоря, PDBR указывает на PageDirectory.
PageDirectory это массив PDE-шек.
PageDirectory всего одна.
PDE-шки указывают на PageTable-ы.
Поскольку PDE-шек много, то и PageTable-ов много (но не обязательно столько же, сколько PDE-шек).
PageTable это массив PTE-шек.
PTE-шки — это описатели страниц. Указывают на страницу в физической памяти и хранят её атрибуты.

Допустим, мы обращаемся к памяти по некоторому адресу? Как ОС находит для этого адреса нужную PDE-шку, а оттуда оттуда адрес массива PTE-шек и находит в нём нужную PTE-шку?
На самом деле, ОС никак не находит, этим занимаются электроника процессора, то есть это делается аппаратно, а не программно.

Когда вы обращаетесь по определённому адресу, этот адрес дробится на три куска:
(картинка из википедии)


Процессор находит начало массива PDE-шек (узнаёт из регистра PDBR (CR3)).
Старшую часть линейного адреса, по которому осуществляется обращение, процессор используется как индекс PDE-шки в массиве PDE-шек. Берёт эту PDE-шек и получает из неё 20-битный адрес начала массива PTE-шек (массивов PTE-шек много).
Среднюю часть линейного адреса, по которому осуществляется обращение, процессор используется как индекс PTE-шки в массиве PTE-шек. Так он находит PTE-шку описывающую страницу, у которой происходит обращение. Из PTE-шки процессор узнаёт физический адрес страницы в физ. памяти.
Оставшуюся младшую часть линейного адреса процессор использует как смещение относительно начала физической страницы.
То есть диапазон оставшегося 12-битного младшего куска адреса — он как раз равен размеру страницы, и означает смещение байта/слова/дворда в адресуемой странице.

Весь этот процесс называется преобразованием адреса, а блок логический блок процессора, который этим занимается, называется MMU.

Собственно, это только часть дела, причём последняя часть дела.

Ибо есть три адресных пространства (причём надо эти пространства рассматривать не более чем математические абстракции).

Виртуальное адресное пространство. Это именно то адресное пространство, которое видят все приложения, и само ядро ОС. Обычные привычные вам адреса — это всё виртуальные адреса. Причём это адресное пространство 48-битное, ибо указатель состоит из двух частей: 16-битного селектора сегмента и 32-битного смещения в сегменте. Но это полный (far) адрес, а из-за с натяжкой так называемой flat-организации, все обычно применяют не полные 48-битные адрес, а краткие (near) 32-битные — при этом недостающая 16-битная часть виртуального адреса берётся из сегментного регистра, который соответствует выполняемому действю (CS — если вы вызываете что-то, DS — если читаете/пишите, SS — если работаете со стеком).
Итак, если вы Windows или nix-программист, то вы используете виртуальные адреса, которые обычно для вас 32-битные, но вы можете использовать и 48-битные адреса, и более того, в Windows вы их часто используете, например записывая что-нибудь по адресу FS:[0].

Линейное адресное пространство.
Линейное пространство имеет размер 4 гб. Линейные адреса — 32-битные. Вы никогда не используете линейные адреса. Вы не моежет просто взять и обратиться в линейному адресному пространству по имеющемуся у вас линейному адресу.

Физическое адресное пространство
Собственно, та самая физическая память. Физический адрес — тот самый адрес, который появляется на «ножках» микросхему процессора.

Собственно, полностью процесс преобразования адреса выглядит так.

1. Вы обращаетесь (всегда) по виртуальному адресу СЕЛЕКТОРСЕГМЕНТА:СМЕЩЕНИЕ.
2. Ваш виртуальный адрес преобразовывается в линейный адрес (я не описывал здесь механизм преобразования, но он простой — по селектору сегмента находится дескриптор сегмента, из дескриптора берётся значение поля «база сегмента», база сегмента суммируется с 32-битным смещением, взятым из виртуального адреса, и получается 32-битный линейный адрес.
3. 32-битный линейный адрес дробится на используется чтобы найти PDE/PTE и преобразовать этот самый линейный адрес в 32-битный физический адрес.
   
   3-ий пункт выполняется только в случае включенного страничного режима, то есть взведённого флага PG в регистре CR0.

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

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

Поэтому в Windows виртуальный адрес практически всегда численно равен линейному адресу. Исключение: при обращении к FS:[aabbccdd]. В этом случае линейный адрес не будет равен aabbccdd. Он будет равен сумме aabbccdd и базового адреса сегмента FS. Собственно, он всегда равен сумме, но в случае других сегметов база всегда нулевая.

То есть:
Виртуальный 48-битный адрес → Линейный 32-битный адрес → Физический 32-битный адрес.

При этом:

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

Преобразование виртуального адреса в линейный выглядит примерно так:


И ещё одна аналогичная картинка, иллюстрирующая преобразование адреса из линейного в физический:

(Две стрелки, приходящие в кружочек с крестом обозначают просто суммирование адресов)


На всём этапе преобразования адреса выполняются проверки битов-флагов (сначала в дескрипторе сегмента, к которому идёт обращение, потому в PDE-шке, потом в PTE-шке). Если с флагами что-то не так, возникает исключение, и ОС его обрабатывает. В 99 процентов случаев — без последствий для программы (то есть просто своппинг), но бывает, что и обращение к невыделенной странице или нарушение доступа к странице. Тогда, если обращение было из usermode, в UM-процессе генерируется исключение, которое может быть обработано SEH-хендлером, а если оно было в kernelmode — генерируется BSOD

Все эти преобразования и проверки флагов делаются при каждом обращении к флагом. Хотя, конечно, в современном процессоре всё кешируется, в том числе и результаты проверок и результаты преобразований — если с момента последнего преобразования адреса никто не правил PDE-шки PTE-шки, преобразование не делается заново, а берётся закешированный результат из TLB (это не та TLB, о которой вы подумали).

Фух.
Всё это относится к обычному режиму (не используется PAE и AWE)

Я всё хочу написать в википедию статью на эту тему, с хорошими картинками, но никак нет времени.

[ger_kar]

Это именно то адресное пространство, которое видят все приложения, и само ядро ОС.

Получается, что для ядра адресное пространство выглядит точно так же как и для процесса. И процесс ядра от другого процесса отличается только привелегированностью?

Итак, если вы Windows или nix-программист, то вы используете виртуальные адреса

Организация памяти в nix от Windows отличается?

[Хакер]

Кстати, забыл отметить.
Линейный адрес дробится на три куска. Старший 10-битный блок, средний 10-битный блок и младший 12-битный блок.
Как я уже писал, значение старшего блока используется как индекс PDE-шки в PageDirectory, а значение среднего 10-битного блока используется как индекс PTE-шки в PageTable.

Диапазон значений, который может быть описан 10-битовым числом: 0...1023.
То есть PageDirectory имеет 1024 элемента (PDE-шек), и PageTable имеет 1024 элемента (PTE-шек). Ибо к именно такому количеству позволяет обращаться 10-битный индекс.

Так вот, поскольку размер PDE равен 4 байтам, и размер PTE тоже равен 4 байтам, получается, что PageDirectory целиком и полностью укладывается в одну 4кбайт-ную страницу, и PageTable тоже указывается в одну 4-кбайтную страницу.

И, разумеется, они должны быть выравненными по границе страницы. В этом случае младшие 12-бит адреса PageDirectory (или PageTable) становятся равными нулю.

Именно поэтому PDBR — 20 битное, и в составе PDE и PTE тоже 20-битные поля. Все эти 20 битные поля хранят старшие 20 бит адреса каталога страниц / таблицы страниц / страницы. Ибо поскольку каталог страниц и таблица страниц сама выравненна по границе страниц, нет нужды хранить младшие 12 бит адреса, которые всегда ноль. К тому же, если пронумеровать страницы по порядку, то получится, что старшие 20 бит адреса, то есть те самые 20 бит регистра PDBR или 20 бит из PDE или 20 бит из PDE — численно равны порядковому номеру страницы, в котором хранится каталог страниц, таблица страниц или сама страница.

[Хакер]

Получается, что для ядра адресное пространство выглядит точно так же как и для процесса. И процесс ядра от другого процесса отличается только привелегированностью?

Ну конечно. Более того, все обычные процессы переходят в режим ядра. То есть это не только аналогичным образом выглядящее АП, как у обычного процесса, это ещё и то же самое АП, что и у обычного процесса, инициирующего переход в режим ядра.

[Хакер]

Кстати, собственно, как реализовано то, что каждый процесс имеет своё изолированное от других процессов адресное пространство.
Для каждого процесса ОС создаёт свой каталог страниц (Page Directory).
Когда происходит переключение между потоками двух разных процессов, система просто меняет значение регистра CR3/PDBR — был адрес одного каталоге страниц, стал адрес другого каталога страниц. И опа — выполняющийся процессором код с этих пор «видит» уже совершенно другое адресное пространство, по одни и тем адресам лежат уже совершенно другие данные, нежели в другом процессе.

[Qwertiy]

система просто меняет значение регистра CR3/PDBR — был адрес одного каталоге страниц, стал адрес другого каталога страниц

А что мешает программе самой изменить это значение? Или изменить записи в таблицах?

[Хакер]

Привилегии мешают. Не получится у usermode-кода перезаписать этот регистр.
А таблицы к тому же ещё не попадают в видимые пользовательскому коду нижние 2 Gb (или 3 Gb в спец. режиме) виртуального АП процесса.

Так что напрямую ваш код не может этого сделать. Зато косвенно вы можете это сделать, например при вызове ReadProcessMemory/WriteProcessMemory, происходит сначала переход в режим ядра, то есть повышение привилегий текущего потока, а потом и переключение с АП вашего процесса на АП чужого процесса, чтение/запись, а потом переключение АП обратно на свой процесс.

Хотя, конечно, дело не ограничивается одной только перезаписью PDBR. Там очень много кода. Код, выполняющийся в режиме ядра, может пользоваться функцией KeAttachProcess (или «более современную» KeStackAttachProcess) и присоединиться к АП любого процесса. Она делает кучу работы, а непосредственно замену значения CR3 делает вызываемая ею KiSwapProcess.

[iGrok]

Большое 20-битное поле в составе PDE-шки — это физический адрес физической страницы в физической памяти. А оставшиеся однобитовые флаги

PTE-шки, видимо?

А 12 бит флагов PDE-шки что определяют? Такие же атрибуты, как и у PTE, просто "общие" для всего блока, или что-то иное?

[Хакер]

PTE-шки, видимо?

Да, исправил.

А 12 бит флагов PDE-шки что определяют? Такие же атрибуты, как и у PTE, просто "общие" для всего блока, или что-то иное?

Частично общие, частичное — иное.

На васме нашёл готовые картинки.

PDE:


PTE:

[ger_kar]

Тема интересная, уже возникла куча вопросов, но не буду их пока задавать, хочу все то что уже написано очень хорошо осмыслить и переварить, упорядочить мысли, а уж потом...
А собственно я это к чему, может эту тему в мануалл перенести, как мне кажется там ей будет самое место. И легко найдется и пополнится со временем, потому что сама тема и довольна сложная для восприятия, так как имеет кучу нюансов, так и сама по себе достаточно обширная.

[Хакер]

А собственно я это к чему, может эту тему в мануалл перенести, как мне кажется там ей будет самое место.

Там нравоучительные статьи, а эта — просто информационная.
И для перемещения туда она слишком низко-качественная — она писалась в дикой спешке, и я даже не уверен, что не написал одно и то же в двух абзацах подряд. Или что не забыл чего-то.

[burik]

Хакер, спасибо за описание - очень интересно.
Возник небольшой вопрос по поводу преобразования виртуального адреса к линейному:

Виртуальный 48-битный адрес → Линейный 32-битный адрес → Физический 32-битный адрес.

ведь 48 бит охватывает значительно больший диапазон значений, чем 32 бита. Получается размер сегмента меньше 2^32, что же тогда произойдет при обращении к адресам, которых в сегменте нет? Зачем же виртуальный адрес на 16 бит больше необходимого?

[Хакер]

ведь 48 бит охватывает значительно больший диапазон значений, чем 32 бита. Получается размер сегмента меньше 2^32, что же тогда произойдет при обращении к адресам, которых в сегменте нет? Зачем же виртуальный адрес на 16 бит больше необходимого?

48 бит виртуального адреса — это не просто плоское число. Младшие 32 бита виртуального адреса — это смещение (отсчитываемое в байтах от начала сегмента) в пределах сегмента, и это плоское число. Оставшиеся старшие 16 бит — это селектор сегмента, и это не плоское число, это структура, которая состоит из порядкового номера дескриптора сегмента в одной из сегментных таблиц (коих у каждой выполняющейся задачи две — одна глобальная, общая для всех задач, и одна локальная, специфичная каждая для своей задачи).

что же тогда произойдет при обращении к адресам, которых в сегменте нет?

А как обратиться к адресам, которых в сегменте нет? Допустим, у нас есть сегмент максимально возможного размера (4 Гб).
Мы обращаемся к нему по адресу XXXX:FFFFFFFF, где XXXX — идентификатор сегмента, к которому мы обращаемся, а FFFFFFFF — максимально возможное 32-битное число, то есть максимально возможное смещение к сегменту.

Ну и где адрес, «которого в сегменте нет»?

Сегментную систему памяти можно с файловой системой.
Если считать, что 16-битный селектор сегмента — это имя файла хендл файла,
а 32-битное смещение — это смещение каких-то данных в каком-то файле.

И вот вам дают 4 ГБайтный жесткий диск. Вам говорят: можете иметь на нём сколько угодно файлов, произвольного размера (от 0 до 4 Гб), и иметь открытыми одновременно около 16 тысяч файлов. Удобно и круто? Бесспорно.

И вот вы пишите программу и у вас есть два варианта, как распоряжаться данными: пользоваться предложенной вам системой файлов и хранить разнородные данные в разных файлах разного размера. Или не пользоваться предложенной вам системой, а вместо этого создать на вашем 4 ГБайтном жестком диске один 4 ГБайтный файл и хранить все ваши разнородные данные в этом файле.

Вот разработчики ОС выбрали второй способ, из соображений совместимости с другими аппаратными платформами, где никаких сегментов нет. Дожили до того, что в x86-64 сегменты убрали, потому за все годы существования этой замечательной системой безопасности и упорядочивания так никто и не воспользовался.

Ну, наша аналогия с файлами немного отличается от реальных сегментах тем, что данные данные в файлах не могут частично перекрываться, а в сегментах — могут.

Когда проводят хирургические операции, обычно закрывают тканью всё лишнее, и оставляют очень небольшой, минимально необходимый открытый участок тела, над которым будет проводиться операция:

Сегменты x86 нужно воспринимать именно в точности как вот такое рабочее окошко. А линейное адресное пространство — как всё тело целиком.

А так называемая flat-организация, которую мы видим во всех распространённых ОС, это как если бы по периметру операционного стола проложили бы верёвку, оставив всё тело пациента открытым для операции.