|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Nick Gazaloff 2:5020/400 13 Oct 2004 23:07:35 To : Zahar Kiselev Subject : Re: неисполняемый стэк в 2.4 ? --------------------------------------------------------------------------------
Zahar Kiselev wrote:
> Hello Nick!
>
> Oct 13 11:59 04, Nick Gazaloff wrote to Zahar Kiselev:
>
> >> >> странице и читаем: "Дескриптор сегмента может быть помечен правами,
> >> NG> Смотрим на ключевое слово "сегмент" и вспоминаем о flat 32-bit
> >> NG> memory.
> >> А это никак не проблема _аппаратной_ платформы. Платформа поддерживает
> >> все что
> >> нужно, это ОС не пользуется этой поддержкой. Тем более что в той же
> >> книжке читаем:"Вместо защиты сегментов ОС могут защищать страницы. Такая
> >> защита может
> >> быть обеспечена и для отдельных частей больших сегментов.[...] 80386
> >> проверяет
> >> атрибуты страниц после контроля правильности доступа по атрибутам
> >> сегмента." Hичто не мешает использовать и тот и другой механизм защиты
> >> одновременно - было
> >> бы желание у писателей ОСов.
> NG> Значит, openwall дураки писали? Вместо того, чтобы задействовать
> NG> аппаратную защиту (которую дурак LT не смог включить), они ее стали
> NG> эмулировать?
> Значит у них были какие-то свои соображения чтобы не использовать имеющуюся в
> процессоре возможность. Какие именно соображения - могу лишь предполагать.
> Hапример - необходимость слишком существенно переделывать архитектуру ядра и
> потом бороться с возникающими несовместимостями.
> Hо то, что вышеупомянутая возможность в процессоре 80386 есть - это факт,
> который я специально подтвердил ссылкой на книгу.
Сегмент стека (мы ведь о нем говорим) _обязан_ быть сегментом данных (не
кода), и обязательно read-write. При этом код, помещенный в него, может
исполняться. Hикакой аппаратнной защиты нет.
Да и странно было бы, если бы она была, но _ни_одна_ (!) ОС на x86 ее не
использовала.
--
Best regards,
Nick
(GPG Key ID: 4396B2D0, fingerprint: 648E C3FE ACF6 A730 FF52 D717 776D
1CB0 4396 B2D0)
--- ifmail v.2.15dev5.3
* Origin: RTComm.RU (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/9181c1495e94.html, оценка из 5, голосов 10
|