> Уверены?Общая идея которая устаканилась у всех более-менее одинакова. Ну как говоря авто я ожидаю увидеть руль, 4 колеса, фары, двигатель и прочие стопсигналы, так говоря MMU я в обещм случае ожидаю увидеть вполне характерный агрегат для работы с страничной памятью, у которого на месте более-менее обычные "руль и 4 колеса" и так далее. Какая-то конкретика разумеется отличается, но общая концепция более-менее устаканилась.
>> Примерно такие же страницы и что там еще.
> Вот-вот. Большинство разрабов процов хватило только на страницы.
Знаете, это интела к их чести хватило выбросить свой геморрой с сегментами и перейти на нормальный MMU. То что было в 80286 - лютый феерический пи...ц. Там даже компилеры не могли массивы адресовывать более чем на 64К без спецкостылей и подпорок. Совершенно кретинская модель памяти. К чести интела они решили похоронить это недоразумение и сделать нормальный MMU и линейную адресацию, как у всех вменяемых архитектур. Правда вот выбросить до конца останки наследия не смогли. И зачем-то оставили совершенно куцые регистры, хотя имели все шансы исправить и это упущение.
>> Все, включая ваш любимый MS на "лишние" кольца
>> дружно забили и ограничились двумя.
> э? Винда на старте поддерживала x86, mips и alpha, потом добавили ppc.
> Какой там mmu в этих других процах можете сами почитать.
Не путайте MMU и кольца защиты. Это разные вещи. На самом деле MMU внедрили в основном для поддержки виртуальной памяти. А до кучи страницная организация памяти дает возможность вешать страницам атрибуты и защищать память всех ото всех, чтоб не шарились почем зря. NX-бит это лишь логичное доразвитие идеи. Никого же не удивляет память отмаркированная как read only например и лютый эксепшн по поводу попытки туда что-то записать.
> А то что Линус не осилил сегментную модель памяти... что можно
> ожидать от эмулятора терминала.
Знаете, сегментная модель памяти юзалась только в 16-бит винде и это было редкостное угробище. Как и вся винда 3.х и 9х - там такая жесть в кернелмоде что линукс на фоне этих куч костылей и нескольких разрозненных кусков ядер разной битности густо подпертых костылями - просто эталон стройности. Не говоря о том что была куча методов испортить память системы из пользовательской программы так что система вставала колом при малейшем сбое программ DOS и т.п.. Linux более-менее на уровне современных ОС как раз потому что его не пытались строить под заведомо дефективную и ограниченную модель памяти и сразу забабахали под именно ту модель памяти которая покорила мир. Кстати современные версии NT-based вы тоже никогда не адаптируете к 80286 и его убогой модели памяти. Они тоже завязаны на страничные методы адресации и ни о каких сегментах и прочих костылях эпохи 286 знать ничего не желают. Потому что в отличие от самопального гумна 3.х/9х это нормальная команда ядерщиков писала, удачно скупленная MSом.
>>> В результате мы имеем такие бонусы как buffer overflow позволяющие
>>> загрузить и выполнить код,
>> Не вижу как лишние кольца помогли бы борьбе с переполнением буфера.
> Потому что о том как устроен PM в 286+ вы читали в
> журнале мурзилка (хотя сомневаюсь что вы этот журнал в глаза видели).
Все эти сегменты в 286 - лютейший маздай. И весь PM - первый блин комом. Нечто вменяемое родили только в i386. И как ни странно, большая часть процессоров (даже всякие ARM и MIPS) используют довольно похожие подходы по части MMU и того что связано с страничной памятью. Сдохло фирменное уе...ство с сегментами - туда и дорога. Flat модель памяти тупо удобнее программить, а атрибуты на страницы вполне можно развесить.
> Для выполнения задачи в PM необходимо LDT, TSS, и три сегмента:
> code, data, stack. Это уровень организации приложения.
А ничего что по хорошему, не все так просто?
Code бывает заведомо readonly, а бывает read-write. И по идее есть 2 разных случая: в идеале хорошо бы readonly, но тогда например в принципе не удастся делать jit компилеры, рантайм оптимизации и прочее. С другой стороны, полная либерастия "пусть код в память пишет кто угодно" чревато невкусными неожиданностями "ой, нас тут внезапно пропатчили без предупреждения и получения на это правов от ОС".
Данные тоже бывают как read-only статичные данные, так и read-write. Но ведь 640 кило хватит всем, правда? :)
> Каждый тип сегмента имеет свои уникальные свойства. Сегмент кода всегда RO,
... и поэтому JIT, трансляцию кода и прочие рантайм оптимизации вообще делать нельзя? Как мило.
> а на сегмент данных или стека нельзя сделать джамп.
Что, и EXE-packers тоже дружно в пролете?
Кстати, теперь примерно то же самое делает NX бит. То что его сразу почему-то не предусмотрели - вот это слегка упущеньице. Но тут стоит вспомнить что в те поры интернет не был так популярен и переполнения буферов всем были до лампочки, а битва шла вокруг защиты ОС от поползновений задач и защиты задач друг от друга. С этим MMU справляется на ура и без NX бита в общем то. Какую задачу решали - ту и решили. А переполнения заткнули когда это стало актуально. Хотя теоретически никто не мешал и раньше это предусмотреть.
> Так вот, для приложения эти три сегмента делаются непересекаемыми, в итоге
> в случае buffer overflow с загрузкой кода и попыткой перехода мы получим банальный GP.
Ну а сейчас получим исключение по поводу NX бита. То же самое, только для страничной модели.
> О том как можно эффективно использовать 4 уровня привелегий подумайте сами.
Что-то ваш любимый майкрософт не захотел на этот счет думать.
>> На самом деле, execute без read - это из разряда "хочу есть,
>> но не ртом". На такие извращения процессоры никто не рассчитывал и
> Я ж таки прав. О PM в 286+ вам явно Рабинович на хинди напел.
> http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm.
Не вижу никакого смысла читать о 80286 и его сегментных моделях. Независимо от того какими хорошими и пушистыми были мамонты - они сдохли. Не вижу смысла тратить мое время на труп.
>> это ограничение наверное можно попробовать обойти окольными путями,
> Обойти? Если влезть на уровень mmu то всё обойти можно, а так
> если сегменты не пересекаются, то никак.
Угу, только вся эта сегментная модель предполагает довольно жесткие ограничения на то как выглядит задача и что она вообще может. Взять вот типичный браузер. Он на ходу перегоняет куски скриптов в машинный код для ускорения. Как это делать если сегмент тотально RO? "Это не нужно"? Спасибо, про то что 640К хватит всем - уже слышали.
