OSDev

Задумался о следующем вопросе, касающемся аллокирования страниц.
Начинающие ОС девелоперы часто используют стэк-аллокатор в силу простоты и эффективности в том случае, если не нужно выделять диапазон смежных страниц. Однако, помимо простоты и эффективности необходимо рассматривать и другой аспект - надёжность или защищённость.
Предположим следующую ситуацию. Злоумышленник или программа с ошибкой освобождает страницу, которую на самом деле не аллокировала. Т.е. страница дважды числится в списке свободных. Таким образом, эта страница впоследствии будет дважды выделена, что приведёт к краху программ, аллокировавших её. Очевидно, алгоритм на основе битмапа устойчив к данному вредительству, т.к. процесс освобождения страницы легко сопрягается с проверкой того, что она на самом деле выделена. Вопрос: есть ли эффективная защита в случае стэк-аллокатора?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

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

Лично я использую стек свободных страниц (с двойным дном - в одном и том же стеке раздельно хранятся обнуленные и необнуленные страницы). Для функций, работающих с физическими адресами, использую отдельный пул небольшого размера (под него отдается вся базовая память кроме первой физ. страницы). В стек свободных страниц отдается вся фактическая, доступная для ОС изначально, память между границами 1 мб и 4 гб (часть памяти еще на этапе инициализации забирается из стека по особому алгоритму и больше в него не возвращается, благодаря чему пространство стека может сократиться) - нет фишек типа установки максимальной вершины или максимального количества доступной для использования физ. памяти. Остальные участки физ. памяти могут контролироваться только на уровне менеджера аппаратных ресурсов. Такой контроль имеет чисто декларативный характер и предназначен для того, чтобы модули знали, что они пытаются забрать под свои нужды уже занятые (частично или полностью) ресурсы. Суть в том, что я не пытаюсь защититься от модулей ядра, а лишь делаю все необходимое, чтобы не содержащие ошибок модули могли нормально сосуществовать с ядром и с другими модулями.

Еще один близкий механизм - это работа с разными участками физ. памяти через окно в ВАП. В плане защиты здесь тоже все нормально.

Зачем бегать по каталогам. Когда можно использовать счётчик ссылок?

Зачем нужен счетчик, если страница не разделяемая (shared)? Я к примеру физические адреса монопольно используемых страниц храню только в "каталогах".

Поговорим о выделение страниц.
Общие страницы для простоты запретим.

1. Выделение физической страницы.
2. Освобождение физической страницы.
3. Отображение виртуального адреса на физический. Помещение физического адреса в дерево страниц.
4. Отмена отображения. Замена адреса в дереве на 0. С возвратом физической страницы.
5. Доступ к элементам дерева.
6. Создание нового дерева.
7. Удаление дерева.
8. Выделение виртуального диапазона, непрерывного в физическом адресантом пространстве.
9. Блокировка, разблакировка страниц.

Все ли функции я перечислил?

Не понятно, что означает "доступ к элементам дерева". Речь о синхронизации доступа или о чем-то другом?

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

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

Выделение обнуленных страниц можно сделать системной функцией.

ВАП не интересует. Любые окна это изврат. Блокировку в список добавил.

Это, видимо, было нужно в 32-разрядных системах с большим количеством памяти. С появлением 64-систем это стало не так актуально.

Уточни, что ты имел в виду под "доступ к элементам дерева".

Под доступом я имею ввиду чтение и запись элементов дерева.