OSDev

Приветствую всех!

Вопрос у меня такой:
Как я понял, во всех современных ОС используется страничный механизм. И один-два дескриптора на всю GDT.
Смысл в этом?
Ведь написать, скажем, шеллкод под страничную систему относительно просто. А при сегментной адресации он принципиально не возможен.
ОСь при сегментной адресации меньше и работает она надежнее.
Организовать свопинг проще чем пейджинг и работать он будет быстрее и аппаратная часть будет проще.
Или я чего-то сильно не понимаю?

_________________
Found a CPU. LAPIC ID: 00

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

Но почему тогда используется только страничная? Из каких соображений?

_________________
Found a CPU. LAPIC ID: 00

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

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

Кстати говоря, к монолитности/микроядерности особенности аппаратуры управления памятью вообще не имеют не малейшего отношения.

Даже без сегментной модели, во всех системах с плоской памятью, перезагрузка сегментных регистров происходит тысячи раз в секунду (из-за смены уровней привилегий во время системных вызовов, исключений и прерываний) - и ни каких проблем. Мне кажется, что "чрезвычайная дороговизна перезагрузки сегментов" несколько преувеличена.

Она может происходить и миллионы раз в секунду, но за аналогичное время процессор успел бы выполнить миллиарды обычных команд. Зачем тратить время на ерунду, если без этого можно обойтись, причём без какого-либо реального ущерба и дополнительных сложностей (скорей, наоборот)? Перезагрузка же сегментных регистров в связи с переключением задач и т.п. -- это неизбежное зло на архитектуре ИА-32, и от этого никуда не деться...

Тут предполагается (смотри первое сообщение), что сегментная модель даёт дополнительную защиту.

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

Сегментация никаких реальных преимуществ не даёт, а вот управление памятью усложняет вполне себе реально. Во всяком случае, я преимуществ у неё не вижу (и, кстати, понятия не имею, что такое шеллкод). Если Вы таковые видите, то я не возражал бы от заслушивания всего списка :)

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

АДД. Относительно первого сообщения. Про шеллкод уже сказал: я не знаю, что это такое; гуглить и читать нагугленное лениво, а посему и прокомментировать не могу.



Оба содержащихся здесь утверждения неверны. Надёжность вообще не зависит от того, какая организация памяти используется, она зависит исключительно от качества проектирования и реализации самой системы. Управление же памятью с сегментацией а-ля ИА-32 сложней, чем управление с помощью страниц -- хотя бы в силу того, что размеры у сегментов могут быть произвольными, а страницы имеют фиксированные размеры (ну или один из нескольких размеров, причём по выбору системы).



Тоже неверно. Обмениваться с диском порциями фиксированного размера проще, чем переменного (не нужно вводить дополнительные проверки и т.д. и т.п.). Скорость в среднем получается выше при страничной организации, и в первую очередь за счёт того, что сегмент приходится выбрасывать из памяти или загружать обратно целиком, а это могут быть гигабайты. Что же касается страниц, то там производится выгрузка/загрузка небольших порций данных, причём именно тех, которые действительно нужны или почти наверняка не нужны. Что немаловажно, такая "оптимизация" получается сама собой, без усилий со стороны программиста-прикладника (он лишь может ещё больше увеличить эффективность, располагая совместно используемые данные поближе друг к другу и так же поступая с кодом), а вот в случае с сегментацией от программиста зависит очень и очень много. В частности, в условиях не слишком большого объёма физической памяти неграмотное разбиение на сегменты может вообще в миллиарды раз уронить производительность (представьте себе подкачку сегмента размером 1 Гбайт через каждые 20-30 машинных команд).

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

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

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