Исходное сообщение
"Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD" Отправлено Дон Ягон, 04-Мрт-20 17:58
>> Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть. > Классика жанра: > В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным. Логика рассуждения мне понятна, спасибо. Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда? Или, например, можно не использовать динамических алокаций вообще, если условия задачи позволяют. А PaX не обязательно убивает процесс, тот же PaX MPROTECT, про который тут шла речь, приводит к тому, что mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы. > В случаях когда работа сервиса имеет приоритет над безопасностью, жесткий контроль за памятью использовать нельзя. Просто журналируются все события некорректного поведения процесса, без каких либо санкций к нему. > Это надо обязательно понимать и помнить. В моём понимании, это не напрямую связанные вещи. Если конструкция в целом умеет переживать смерть отдельного процесса без остановки сервиса, то не вижу проблем даже и в прибивании за нарушение гарантий памяти. Если не умеет, то мы нарвёмся на проблемы и без проблем с безопасностью. Требование-то, на самом деле, к непрерывности предоставления сервиса, а не к модели памяти. От этого, имхо, и нужно рассуждать.