LINUX.ORG.RU

История изменений

Исправление firkax, (текущая версия) :

Простите - но наглая ложь. Возможно гранулярность другая (4k), но всё есть.

Дело не в гранулярности. Я же привёл ссылку на CVE даже. Есть кусок памяти - стек, есть кусок памяти, выделенный приложением через mmap(). На вид их никак друг от друга не отличить, и то и то - страница данных, с правом на чтение. И единственное, что мешает стеку расползтись в страницу от mmap-а - это костыльная невалидная страница между ними, с расчётом что больше 4кб за 1 раз из указателя стека не вычтут (иначе он её перепрыгнет). Ну и не вычитают, это очередное проявление костыльности - если надо выделить в стеке больше 4к, делают это по шагам. В случае же с сегментной защитой всё намного лучше: есть сегмент стека, у него чётко прописана нижняя граница (вот прямо у проца в скрытом регистре записано число-ограничитель в явном виде), а блок от mmap-а будет в другом сегменте, и никак они не пересекутся.

Возможно я что-то пропустил.

Сегменты в защищённом режиме 286 - это не сдвинутые на 4 бита базовые адреса, а записи в таблицах, где указан их полный базовый адрес, размер и права доступа, которые проц автоматически читает при изменении сегментного регистра. И одна из двух таблиц меняется при переключении процесса, таким образом переключая половину всего адресного пространства (всего 1ГБ, 512М из них переключается). Хотя на самом деле и без этих переключений ОС может просто менять записи в этих таблицах, меняя соответствие определённых логических адресов процесса физическим.

Нет. Он еще был и 16ти-битным, в отличие от.

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

Закат 286 связан исключительно с отсутствием MMU, imho.

Да нет, 386 появился за 10 лет до вин95, и даже пентиумы уже были. Они просто дропнули поддержку неактуального проца 3 огромных поколений назад и снятого к тому времени с производства. А сама вин95 даже на 386DX-40 очень тормозила, как бы она работала на ещё раз в 10 более медленном проце сложно представить.

Исправление firkax, :

Простите - но наглая ложь. Возможно гранулярность другая (4k), но всё есть.

Дело не в гранулярности. Я же привёл ссылку на CVE даже. Есть кусок памяти - стек, есть кусок памяти, выделенный приложением через mmap(). На вид их никак друг от друга не отличить, и то и то - страница данных, с правом на чтение. И единственное, что мешает стеку расползтись в страницу от mmap-а - это костыльная невалидная страница между ними, с расчётом что больше 4кб за 1 раз из указателя стека не вычтут (иначе он её перепрыгнет). Ну и не вычитают, это очередное проявление костыльности - если надо выделить в стеке больше 4к, делают это по шагам. В случае же с сегментной защитой всё намного лучше: есть сегмент стека, у него чётко прописана нижняя граница, а блок от mmap-а будет в другом сегменте, и никак они не пересекутся.

Возможно я что-то пропустил.

Сегменты в защищённом режиме 286 - это не сдвинутые на 4 бита базовые адреса, а записи в таблицах, где указан их полный базовый адрес, размер и права доступа, которые проц автоматически читает при изменении сегментного регистра. И одна из двух таблиц меняется при переключении процесса, таким образом переключая половину всего адресного пространства (всего 1ГБ, 512М из них переключается). Хотя на самом деле и без этих переключений ОС может просто менять записи в этих таблицах, меняя соответствие определённых логических адресов процесса физическим.

Нет. Он еще был и 16ти-битным, в отличие от.

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

Закат 286 связан исключительно с отсутствием MMU, imho.

Да нет, 386 появился за 10 лет до вин95, и даже пентиумы уже были. Они просто дропнули поддержку неактуального проца 3 огромных поколений назад и снятого к тому времени с производства. А сама вин95 даже на 386DX-40 очень тормозила, как бы она работала на ещё раз в 10 более медленном проце сложно представить.

Исходная версия firkax, :

Простите - но наглая ложь. Возможно гранулярность другая (4k), но всё есть.

Дело не в гранулярности. Я же привёл ссылку на CVE даже. Есть кусок памяти - стек, есть кусок памяти, выделенный приложением через mmap(). На вид их никак друг от друга не отличить, и то и то - страница данных, с правом на чтение. И единственное, что мешает стеку расползтись в страницу от mmap-а - это костыльная невалидная страница между ними, с расчётом что больше 4кб за 1 раз из указателя стека не вычтут (иначе он её перепрыгнет). Ну и не вычитают, это очередное проявление костыльности - если надо выделить в стеке больше 4к, делают это по шагам. В случае же с сегментной защитой всё намного лучше: есть сегмент стека, у него чётко прописана нижняя граница, а блок от mmap-а будет в другом сегменте, и никак они не пересекутся.

Возможно я что-то пропустил.

Сегменты в защищённом режиме 286 - это не сдвинутые на 4 бита базовые адреса, а записи в таблицах, где указан их полный базовый адрес, размер и права доступа, которые проц автоматически читает при изменении сегментного регистра. И одна из двух таблиц меняется при переключении процесса, таким образом переключая половину всего адресного пространства (всего 1ГБ, 512М из них переключается). Хотя на самом деле и без этих переключений ОС может просто менять записи в этих таблицах, меняя соответствие определённых логических адресов процесса физическим.

Закат 286 связан исключительно с отсутствием MMU, imho.

Да нет, 386 появился за 10 лет до вин95, и даже пентиумы уже были. Они просто дропнули поддержку неактуального проца 3 огромных поколений назад и снятого к тому времени с производства. А сама вин95 даже на 386DX-40 очень тормозила, как бы она работала на ещё раз в 10 более медленном проце сложно представить.