бред

что значит делать буфер "read-only", если он и нужен, чтобы в него записывать данные ;-)

во-во. бред. а что, сейчас нету сегментов только для чтения или только для исполнения? постят всякую дурь...

Ну вот! Не прошло и 20 лет!

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

Козьма Прутков

Второе пришествие команды BOUND
Кто этим будет пользоваться ?

А в ядро это уже включили?

дык, команда BOUND и сейчас есть. Другое дело, что чтобы её использовать компилятор должен знать размер буфера, что не всегда возможно.

> "Now in current processors, any programs that go into the memory overflow can be executed," he said. "With this, the system only allows read-only in the buffer. It will not execute."

типа сделать произвольный кусок памяти не исполняемым... дык это, вроде, давно уже такое есть, только на страничном уровне (во всяком случае на интелах)....

Здесь кто то когда то говорил, что Х-ам нужен исполняемый стек. Правда ли это
и что в связи с этим нас ждет?

Re:

>типа сделать произвольный кусок памяти не исполняемым... дык это, вроде, давно уже такое есть, только на страничном уровне (во всяком случае на интелах)....

на поделках от Intel и AMD (x86) есть три вида защиты страниц:
1) нет доступа
2) доступ на чтение и выполнение
3) доступ на чтение, выполнение и запись

А то, что они нормальную защиту страниц чуть ли не как революционную подают - так это прямо болезнь.

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

большое подозрение, что это будет очередная "защита от вирусов в бут-секторе". никому особо не нужная фича

А разве права на чтение и на выполнение не различаются в X86 ?

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

В I386 была нормальная сегментная модель, которая всё это делала. Разработчики ОС положили с прибором на механизмы защиты 386-го, сделали везде flat-модель. Когда припёрло, начали делать всякие подпорки - защиту на уровне страниц (хотя по уму нужно её делать на уровне сегментов. Просто перепахивать сегментацию - это пипец, а со страницами нужно лишь косталь поставить). А теперь делают аппаратную реализацию этой подпорки. Прогресс!!!

про сегменты...

> В I386 была нормальная сегментная модель, которая всё это делала.

Защита всего сегмента -- это вроде прав доступа на всю ФС.

> Разработчики ОС положили с прибором на механизмы защиты 386-го, сделали везде flat-модель.

1) А где Вы видели эти самые сегменты на других архитектурах?

2) Есть и для Linux, и для NT реализации неисполняемого стека на основе сегментации.

> Когда припёрло, начали делать всякие подпорки - защиту на уровне страниц (хотя по уму нужно её делать на уровне сегментов.

По уму ее и нужно делать на уровне страниц, а сегменты оставить 80286'-му.

> А теперь делают аппаратную реализацию этой подпорки.

Теперь вместо убожества x86 пытаются сделать что-нибудь человеческое... В добрый путь!

>Защита всего сегмента -- это вроде прав доступа на всю ФС.

Глупости говорите. В программе есть сегмент(ы) данных, сегмент(ы) кода, сегмент(ы) стека. Каждый из сегментов состоит из одинаковых страниц. На кой ляд делать защиту для каждой страницы, если у всех страниц одного сегмента параметры будут одинаковые?

> А где Вы видели эти самые сегменты на других архитектурах? И что это доказывает?

> По уму ее и нужно делать на уровне страниц, а сегменты оставить 80286'-му.

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

Да, почему-то мнения все разработчиков серьезных ОС сошлись в части использования плоской модели памяти. Вот дураки-то. Надо было Eugene_Korobko спросить, он только что книжку по 8086 прочитал и всех бы их научил.

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

Красивые мысли тут - http://www.elbrus.ru/mcst/e2k_arch.shtml:

=====
2.2.1  Память

В настоящее время в популярных языках указатели представлены явно целым числом. Пользователь может присвоить целое число типу данных "указатель". Это нарушает защиту памяти. 

В результате две различных процедуры программ в одном и том же виртуальном пространстве не защищены друг от друга. Это означает: 

- даже внутри одной и той же программы - плохое средство отладки;

- отсутствует защита памяти в одном и том же виртуальном пространстве.

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

Чтобы справиться с проблемой, некоторые языки, такие как Java, вообще исключают указатели из языка. Но это делает язык не универсальным, а программирование - менее эффективным. 

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

Указатель процедуры состоит из ссылки на контекст и кода и используется для вызова процедур. Процедурный механизм (команды вызова/возврата и механизм передачи параметров) поддерживается аппаратно как элемент защиты памяти. Контекст процедуры поддерживается с помощью указателей. 

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

Основную стоимость такой аппаратной защиты составляют два дополнительных разряда на каждые 32 разряда в кристаллах ЦП и кэш-памяти. Это практически не замедляет скорость выполнения операций. 

Опыт Эльбруса показывает, что эта схема:

- существенно уменьшает время отладки (до 10 раз);

- уменьшает вероятность пропуска необнаруженной ошибки в уже поставленном программном обеспечении. 
Мы нашли более 30 ошибок в эталонных тестах SPEC, которые считаются хорошо отлаженными программами;

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

Это обеспечивает хорошую поддержку реализации отличной защиты в файловой системе.

========

Жаль только до реализации не скоро, да и сомнительно, что "простые смертные" получат себе это в комп.

PS Очень долго E2K обсуждают здесь: http://forum.ixbt.com/0008/016642.html 

Мне кажется, Евгений прав. И сегменты в защищенном режиме - это совсем не "тяжелое наследие старого мира", а возможность ... типизации доступа памяти без лишней "мелочности". Я бы сказал, определять доступ на основе страниц - сравнимо с заданием доступа на каждый блок файла. Конечно, я ОС в защищенном режиме не разрабатывал, могу ошибаться...

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

Да эта концепция появилась ещё на 8086/88,адресное пространосто было 1М а регистры 16 битные,для полноты адресации не хватало 4 бита,и поэтому придумали сегменты.Дальше для совместимости пришлось эти костыли дальше тащить,ну модернизировали их начиная с 286 конечно,а толку,костыли и есть костыли.

про сегменты...

2 Eugene_Korobko:

> На кой ляд делать защиту для каждой страницы, если у всех страниц одного сегмента параметры будут одинаковые?

Трудно заранее оценить размер сегментов ( а фиксированное деление a la PaX приводит к уменьшению и без того куцого адресного пространства, доступного из userspace).

> В самой программе разделение памяти по разным видам идёт на уровне сегментов.

В какой программе? ( ткните пальцем, pls).

> Кроме того, защита процессов идёт на уровне виртуальных адресов

Ну и что?

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

Убогий у x86 MMU, убогий TLB, но это не значит, что везде все так плохо.

P.S.

Однако отдел маркетинга Intel ест свой хлеб не даром -- убожество вроде сегментов вполне успешно преподнесли как feature...

про сегменты...

2 svu:

> У меня сложилось впечатление, что отсутствие сегментов на других архитектурах скорее связано со сложностью (невозможностью?) эффективной и быстрой реализации механизма

А у меня сложилось впечатление, что они там просто не нужны.

Вообще-то, обычно я анонимусам не отвечаю. Но тут сделаю исключение...:)

Сегменты в защищенном режиме - СОВСЕМ не то же самое, что убогие сегменты реального режима 86. СОВСЕМ. И если вторые - действительно убожество и костыль для расширения 16-битной моды адресации, то первые - вполне осмысленный (мне кажется) механизм крупноблочного (в сравнении со страничным - мелкоблочным) мапирования памяти.

А вообще - регистрируйтесь, плиз...

Значит, у нас разная впечатлительность:)

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

И, чтобы окончательно добить меня, приведите пример, когда в рамках ОДНОГО сегмента вам нужны разные права на разные страницы - и при этом обоснуйте, почему это обязательно должен быть один сегмент.

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

ЗЫ Насчёт не отвечаете не лукавьте ;-),мне отвечали по поводу prelink'а.А насчёт регистрации даже не знаю,быть анимоусом есть резон,в этом есть свои плюсы,ну и минусы конечно,куда уж без них.

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

Я написал - "обычно не отвечаю". Обычно - потому как слишком много пурги гонит ваш брат анонимус. Но это не означает, что изредка я не могу себе этого позволить:)

А лучше - все-таки зарегистрируйтесь, плиз.

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

Сорри, не понял Вашу мысль. Беседа тут, вроде, о том, на каком уровне правильно задавать правильно доступа - на уровне сегментов или на уровне страниц. Вы же почему-то переводите ее на вопрос о том, как мапируется память:)

Люди, где же вы видели защещённый режим без сегментов? Или вы считаете, что число, которое в указателе, это абсолютный адрес? Тогда я вас разочарую: это смещение :) Если хотите почитать на эту тему, http://www.nondot.org/sabre/os/files/ProtectedMode/PMTUT.txt то, что до "-- TABLES AND DESCRIPTORS AND SELECTORS AND L O T S OF CONFUSING STUFF --" можно пропустить...

PS: не ругайте сильно за грамматику Anonymous from Latvia

> на поделках от Intel и AMD (x86) есть три вида защиты страниц: 

  обалдеть. а на поделках от Murr что есть?

> Беседа тут, вроде, о том, на каком уровне правильно задавать правильно доступа - на уровне сегментов или на уровне страниц.
1. Работать с flat-моделью проще по многим причинам. Например, если
данные фрагментированы, никаких проблем не возникает, а с сегментами -
придётся переключать всё время. Фактически указатель уже должен
будет включать в себя не только смещение, но и сегмент, как это было
в реальном режиме. Это же сколько дополнительной работы компилятору?
2. Никаких преимуществ у защиты на уровне сегментов по сравнению с
защитой на уровне страниц быть не должно. На x86 они есть, но не
должны были быть.

И так, если работать с сегментами сложнее (гораздо, как для ОС, так
и для прикладных прог которые сами хотят памятью управлять в том или
ином объёме), а реальных достоинств нет - вопрос, нафига?
Вот по этому на них и забили. То, что это "логичнее", мало кого
волнует. Реально это одни неудобства.

>И, чтобы окончательно добить меня, приведите пример, когда в рамках ОДНОГО сегмента вам нужны разные права на разные страницы - и при этом обоснуйте, почему это обязательно должен быть один сегмент. привожу пример: /usr/src/linux/mm/memory.c функция break_cow... Идея состоит в том, чтобы процессы которые делают mmap на один и тот-же файл с флагом MAP_PRIVATE реально используют одну и туже физическую память пока не начнут менять данные. Вот тогда то и вызывается вышеуказанная мною функция. А что касается частоты использования этого механизма - посмотрите как динамический компоновщик работает... Я с трудом могу себе представить, как это можно реализовать с помощью сегметов. Хотя можно, но тогда у вас память быстро кончиться, а KDE-шное приложение будет загружаться часов 5-10

Re:

>Механизмов защиты x86 хватает за глаза, только вот разработчики ОСей ими них... не пользуются. :-(

Механизмов трансляции на x86 много, но все недоделанные.

Вроде есть и сегменты и страницы, а PROT_EXEC только через анус, физическая адресация памяти вообще отсутствует, буфер трансляции без тагов, etc.

P.S. Прямо грустно, что такие конторы как DEC уходят в никуда, а такие как Intel и MS остаются... Воистину "средний" потребитель готов хавать говно...

А зачем Вам физическая адресация памяти? Лень страничку на нужный диапазон замапить?

Про процы вообще - я не буду с Вами спорить, Вы, очевидно, знаете больше меня:) Только у меня сложилось смешное ощущение, что г-н Торвальдс почему-то любит именно х86 (со всеми его, как он выразился, charming oddities). Уж его-то невежей в отношении процов назвать никак низзя. Странно, почему же у него такая странная лубов? Единственное объяснение, которое я нахожу этому явлению - то, что архитектура, благодаря массовости, вылизана. Как на стороне проца, так и на стороне компиляторов. И, как часть этой вылизанности, (об этом он, вроде, прямо говорил), компиляторостроение для х86 действительно пытается выжать все соки из этой кривоватой архитектура. А рисковые компилеры, "развращенные" хорошими и "прямыми" процами, слегка ленивы в смысле оптимизации. Повторяю - это не мои слова, это моя интерпретация некоторых высказываний ЛТ.

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

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

Насколько я знаю, указатели большинством нормальных 32-битных компиляторов в подавляющем большинстве случаев генерятся как near, без сегмента. А сегменты уже сидять в соотв. регистрах (DS,SS,CS,...) - поэтому адресация осуществляется достаточно быстро (ведь соотв. данные о страницах уже закешированы). flat, конечно, немного быстрее - но не уверен, что принципиально (или пжлте бенчмарки в студию). А вообще это все - махание руками - все очень сильно зависит от реализации проца, ОС и типичных сценариев.

"Преимущества на 86 есть, но их не должно быть" звучит забавно:)

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

> Насколько я знаю, указатели большинством нормальных 32-битных компиляторов в подавляющем большинстве случаев генерятся как near, без сегмента.
Так правельно, ведь в нормальных системах, под которые они компилируют,
используется flat, и там смещения достаточно. Если используется
сегментация, компилятор уже обязан будет поддерживать и far указатели,
а я думаю это не малые накладные расходы.

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

> "Преимущества на 86 есть, но их не должно быть" звучит забавно:)
Согласен:) Имелось ввиду следующее: на х86 механизм страничной
адресации не доделан, по этому и приходится использовать таки
сегменты иногда. AFAIK exec shield патч использует защиту на уровне
сегментов для своих нужд, другие секьюрити-патчи тоже (на х86). А вот
на других процах, где механизм страничной защиты реализован
в полном объёме, сегментация отсутствует за ненадобностью, так?

> То, что с сегментами работать логичнее, по идее, должно упрощать некоторую часть кода ОС. Или нет?
Чем именно? flat-модель упрощает написание ОС, это я слышал, а вот
чтобы сегментация упрощала - пример приведёте?

Так как ты предлагаешь - неприемлимо тормозно и ни с чем не совместимо.

На самом деле это все как мертвому припарки, Пора уже вводить ACL-и на байты

Это ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ медленно по сравнению с flat моделью. Не надо по 15 умножений делать что бы взять что-то по адресу.

Нет народ, это не бред. Это неграмотные маркетологи придумали как объяснить DRM и всякий прочий Palladium массам. Именно об аппаратной поддержке DRM (Digital Rights Management) неоднократно заявляли и Intel и AMD. Но народ как-то неадекватно реагировал - пугался, в общем. А так - это, понимаешь, защита от взлома.

Мне кажется .gov не очень то выгодно иметь черезчур надежные и взломо устойчивые процессоры на массовом рынке. Так что думаю, несмотря на изменения программы будут ломать и ломать ;-)

Прощу прощения у почтенной публики за пессимизм!

Насколько я знаю, все-таки нынешние компиляторы для 86 поддерживают far - и ничего, никто не умер. Просто в 99% случаев можно обходиться near - и все счастливы - и компилятору просто, и проги быстры. Поэтому сегментная модель может рассматриваться как "почти flat". А уж если припрет обратиться к "чужой" памяти - пжлста грузить сегменты в far.

Я, вообще-то, тоже про простоту использования. Мне казалось, что ОС проще один раз установить атрибуты доступа для сегмента, чем бегать, как безумной, по всем страницам, чтобы сделать то же самое, но много раз.

Мысль про недоделанность страничной адресации в 86 мне не очень понятна. Можно поподробнее?

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

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

> Мысль про недоделанность страничной адресации в 86 мне не очень понятна. Можно поподробнее? Так поясняли уже, нет возможности сделать страницу читаемой, но неисполняемой. Следовательно, либо стек исполняемый, либо надо извращаться с сегментами.

А сегментная адресация - это рудимент 8086. Да и от страниц вы все равно никуда не денетесь.

> На самом деле это все как мертвому припарки, Пора уже вводить ACL-и на байты

Я так понял как раз это и сделали в "Эльбрусе" в своём (надеюсь пока) "бумажном" процессоре E2K.
Правда там не для байт, а для слов: "В Е2К все указатели помечены специальным разрядом, который помогает аппаратуре проверять правильность обработки указателей. Е2К не нужна какая-то специальная система памяти - вместо сохранения этого бита используется некоторые дополнительные комбинации в коде ЕСС."

PS Простите, что в моём прошлом посте плохо с форматированием вышло, наверное из-за этого никто внимания на этот пост не обратил.

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

Вообще, я тут еще немного подумал (пока поставку заказчику делал:)...

Короче, вопрос нижнего уровня заключается в том, должен ли CS быть тот же, что и DS (я опускаю SS/ES, поскольку их можно условно считать тождественными DS). Если мы хотим защиту на уровне сегментов (как я говорил ранее) - действительно, похоже, нужно делать CS != DS, а это приведет к тому, что указатели _по_умолчанию_ придется делать far. Чтобы указатели по умолчанию были near, нужно сделать CS = DS. А это убивает на корню весь механизм защиты, основанный на сегментах.

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