> если прога им удовлетворяет то работать будет. Но JIT эти критерии
> исключают полностью.JIT не будет работать с W^X. Почему-то. Data2code transform тоже не будет. Эту технику специфичные датакомпрессорщики любят. Включая всяких проприетариев с рекордными параметрами по соотношению плотности сжатия к скорости распаковки. Игроделы всякие и т.п.. А заодно и упаковщики исполняемых файлов. Или программы патчащие себя для скорости. Это правда больше линукскернел так развлекается, но с чего бы программам в памяти себя патчить нельзя - кто ж его знает. Некоторые и патчат.
> Давно туда не ходил. Да и JS отключен для внешнего мира.
Это так то хорошо и правильно. И почтарь так то лучше этого кошмара. Но вон то юзерье вас не поймет и если мы про популярность проца и технологий...
> Google Chromium имеет JS движок без JIT,
А вы им еще и пользоваться пробовали? Логин в те же почтари может пару минут занять, а с JIT почти мгновенно при прочих равных. Кто их знает что они там майнят. И это, у мозилы был движок без JIT, куда дели? Но работал он с еще более позорной скоростью и радости с него такого...
> с DAC, которые запретят запустить бинарь собраный/скачаный пользователем.
...
> Система разрешает запуск только корректно установленного ПО. Но это уже другая история.
Это все прекрасно - кроме того что с одной сторонй DAC достаточно хлипкий и уповать только на него да ну нафиг. Для себя я предпочел иной путь. Вот вы видите меня. Допустим, мы смогли прорубиться. И тут окажется что доступа в систему по сути и нет. Можете в Download браузера орудовать и читать с десяток либ. Браузеру больше и не требовалось. А если вдруг это удастся обойти - то тут окажется что есть еще вопрос: а чей это W^X? Ах, какой-то виртуалки? Ну, а она не так уж и важна в конечном итоге. Может она вообще временно существует и через день перестанет существовать. Так что масштаб урона весьма маргинальный. Ну, ок, хаксор может упереть у меня даунлоады. Но вообще-то это и без меня скачать можно. Нет, никаких ништяков тут вообще совсем нет, system management, "контроль инфраструктуры" и проч - случается в совсем иных местах. Боее того - эта "инфраструктура" из виртуалок и мелких железок достаточно недружественна к левым типам. Так что они врядли много куда попадут, зато триггернут логи.
С другой стороны типовая программа уже содержит более чем достаточно либ и интерфейсов к системе для того чтобы в случае если ее удалось обмануть пожалеть об этом. Вон мозилла как-то лоханулась и позволила внешнему JS встраиваться в контекст браузера. А это доступ во все куда у браузера доступ есть. И даже если там W^X в вашем понимании и нет, это не мешает разбойному коду сканера дисков снять список дир, отстроить список интересных артефактов и утащить их всем скопом. Включая ключи ssh, логин-пароли популярных штук и какой там еще "cool stuff".
Видимо на концептуальном уровне я не доверяю идее Супер Нерушимых систем, предпочитая иметь эффективные запасные планы на случай если "супер нерушимое" окажется не совсем таковым. Как мозильский браузер с его вгрузкой JS в контекст морды браузера и далее шараханием по системе, при этом не так уж важно есть там JIT или нет, важно что JS влез в привилегированый контекст интерфейса браузера и может все то что сам браузер. На более низком уровне всякие ROP и прочие фокусы с неявным контролем дают много опций как сделать что-то вредное легитимному хозяину системы даже без совсем уж записи и выполнения кода. Это один из поводов для запрета явно ненужных сисколов и их параметров. Я стопроцентно уверен что браузеру не надо доступ к ssh, допустим, и у него нет никаких легитимных поводов трогать бинарник ssh вообще, или тем паче ключи пользователя (да, JS-сканер их пер первым делом). У меня это даже при срабатывании упрет только дырку от бублика, тут ничего кроме даунлоадов браузера нет а это все можно в интернете скачать было :)
> Когда-то была возможность работать без JS, ... поищи.
Я так то вообще программами почтарей предпочитаю. Но тем юзерам привычно воооон то.
> делается умышленно чтобы вынудить пользователей использовать JS с JIT и владельци
> сайтов имели возможность запускать вирусный код на компьютерах клиентов.
И на этот случай у меня есть довольно пустая и не информативная виртуалка. Даже если ее разнесут вдрызг я не так уж и расстроюсь, у меня снапшоты и темплейты есть. Хотя я дважды подумаю стоит ли подставлять даже ее.
> Вот мы обошли круг и вернулись к первоначальному вопросу: инструкцию NX для
> реализации корректной работы с памятью без потери производительности в RISC-V сделают?
Как по мне - MMU вообще отдельный от проца компонент. И на концептуальном уровне отличие в том что система может им рулить, а юзер напрямую нет. И если его можно на страничном уровне как W^X запрограмить - не вижу реальных проблем. В конечном итоге система (кернел) свое в такой системе у юзера отспорить чисто технчески может. А захочет ли и почему так - это уже административный вопрос а не технический. Сама железка может обеспечить эффективный и быстрый энфорс W^X на уровне тех же прав памяти.
А конкретно x86-32 был куском дурных проблем. В том числе - потому что в нем нет нормальных режимов относительной адресации. Этот хлам не умеет относительно PC адресоваться! Это значит что программу нельзя просто загрузить в адреса отличные от ее дефолтных. Ее сперва надо жестко пропатчить в куче мест - использовав жуткий костыль известный как relocations. Это by design клещится с идеей полного W^X, это либо патчится, либо не может работать в желаемых адресах. И вот там x86-32 нагородили дурных костылей. Остальные архитектуры просто не имеют этой проблемы, там обычно вокруг PC адресовать можно и то жоское костылестроение не актуально на самом базовом уровне.
> Или при разработки процессора RISC-V корпорашки вкладывают деньги только в аппаратные
> трояны, чтобы иметь возможность изменять память и устанавливать буткиты с виртуализацией
> для запуска в них пользовательских OS.
Скорее, половина вон того было актуально для кривого 32-бит уродца с полутора регистрами без нормальной относительной реализации - и специфична для именно его чудесатых проблем, когда программы вообще не релокатабельны без жутких костылищ.
> 1. Не включают инструкции NX для реализации корректной работы с памятью без
> потерь производительности.
Я вообще не понимаю почему вам мало атрибутов памяти MMU, при обеспечении что их только система крутить может. И это вполне быстро.
> В место этого включают аппаратные трояны в процессоры.
Если что-то этим словом называть, #1 будет ME, #2 - PSP. И это в вон тех x86 так то. SMM mode с нельключаемым хэндлером в проприетарном мусоре блобваре тоже не далеко ушел, система даже вырубить это не может - у оси эффективного контроля над железом вообще НЕТ. Она в гостях.
> И это типа свободный процессор. Просто верх цэнизма.
На мой вкус там все в пределах разумного. И если отбросить перфекционизм, это сильный шаг вперед vs вон те. А знаете, если я из HDL для FPGA собрал core, я могу быть уверен что там нету ME. А для самой FPGA и ее бэкдоров вон то слишком сложно для осознания как ни крути и оно не сможет целенаправленно с эффективно этим воспользоваться даже если и было. А с x86 - опции какие вообще? А, лизать ботинки 2 корпам? Ну, офигеть, круто.
> 2. Умышленно пишут JS код так, чтобы вынудить некоторых пользователей отключить корректно
> работающие с памятью алгоритмы для запуска кода с JIT.
Ну как бы вот именно ЗАСТАВИТЬ меня юзать какой-то сайт - это надо минимум надзирателя с автоматом для эффективного энфорса. А для редких единичных случаев у меня есть чудные виртуалки.
> Linix изначально старался корректно работать с памятью используя NX инструкцию процессора
> i386 и других.
У конкретно i386 большая часть их проблем лезла с того что x86 не умел в относительную адресацию и пришлось делать жуткие костыли. И RELRO на память - из той же области вроде. На нормальной архитектуре в лучшем случае релоки вообще не требуются. И так то если мы про нормальные архитектуры и системы, это одна из вещей к которым стоит стремиться.
> мейнлайн. Формальные отмазки:
> 1. PAX патчи анонимны, а от анонима мы ничего брать не будем.
И тем не менее, половину патчей от оных и GRSec в современные ядра НеАнонимы вполне себе портанули. Ту их часть которая не ломает по жесткому продакшны народу. У тех господ есть и весьма радикальные фичи, много чего в реальном мире ломающие или создающие иные технические проблемы.
> 2. Есть и другие реализации защиты памяти. Вот вы к общему знаменателю
> прийдите сделайте одну и ее включим.
Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64), MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там и что. И я предпочту чтобы секурно было более-менее везде, ага.
> ядра в общем не поняли сути технологий защиты PAX/Grsecurity при их
> реализации в LInux.
Те патчи которые я видел - выглядели вполне разумно. А часть вон тех патчей со всей их сутью может либо основательно якорить систему либо ломать существующий софт. И это как бы проблема.
