Исходное сообщение
"Уязвимость в Bluetooth-стеке BlueZ, позволяющая удалённо вып..." Отправлено Аноним, 16-Окт-20 15:51
> на сколько я знаю на x86 все защиты памяти (сегменты, виртуальная память, nx) сделаны как-то по особому тормознуто и в реальной жизни их использовать невоможно Ложь! Утверждаю что на архитектурах процессоров: alpha, avr32, parisc, sparc, sparc64, x86_64, ia64, i386 и старше с поддержкой инструкции NX (non-executable) постраничная защита памяти будет работать без потери производительности. На ppc потеря производительности минимальна. Есть неаппаратная посегментная защита памяти она не использует инструкции процессора (вдруг вы не верите своему процесору) тормоза очень незначительны но на 32бит x86 процесс ограничен 1.5Gb оперативы. Защита памяти работает на уровне ядра и процессора и абсолютно прозрачна для порядршных програм. Не порядочные проги, которые используют JIT и некорректно работают с памятью - убиваются. > а так - да, на 286 уже был механизм защиты памяти от записи или выполнения и толку то... Intel, под сильным давлением сообщества, защиту памяти процесором реализовала только начиная с i386. Именно наличие дешового процессора с защитой памяти и дало возможность написания ядра Linux. Отметь у себя в блокноте, что ядро Linux изначально строго работало с памятью и поддерживало защиту от переполнения буфера пока Линус Торвальдс не переехал в США. После переезда в США защиту памяти с официального ядра Linux выкинули! В Европе анонимные хакеры поддерживали патчи PAX которые возвращали защиту памяти в ядро Linux.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: