История изменений
Исправление 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 более медленном проце сложно представить.