inferno singularity

За такое проц бъет проге по пальцам и не пущает. Если только ты в нулевом кольце, где ядро - тогда пожалуйста.

Не понимаю. Как можно залезть в чужую память, ведь виртуальные адресные пространстве. 

Очень просто. Если ты транслируешь команды в реальном времени, то в железе это сделать нереально дорого, нужен микрокод - это значит, что на трансляцию уходят драгоценные микросекунды, зато проще схемка. В случае с ММУ проц с помощью пары хитрых железяк транслирует виртуальные адреса проги в реальные в памяти, дальше смотри на wasm.ru

только в пределах одного виртуального адресного пространства. Если устроить переполнение в фаерфоксе, то соседу в памяти - емаксу - это ни холодно ни жарко))

А нафиг MMU если все пашет в вирт машине? SIP надо, если тебе свербит пускать надцать максимально безопасных процессов на железе без MMU. Singularity любопытная вещь, но на x86 не имеет ни малейшего смысла.

Тут все упирается в то, что все проги надо проверять и подписывать. Иначе система не имеет смысла.

Есть защита на уровне маппингов -- когда при включенном пейджинге в линейное пространство просто не смаппированы физические страницы других процессов и, соответственно, к ним невозможно получить доступ никак кроме изменения маппинга или смены всего контекста. Есть защита на уровне SU/US битов в пейджинговых структурах, когда к некоторым страницам в линейном пространстве доступ разрешен только в режиме ядра, так защищают ядро от юзер-спейсного процесса. Это всё про х86, как в нормальных архитектурах -- не знаю.

Переносимы только _грамотно_ написаные исходники, я имел в виду бинарники. Плюс переносим только чистый С, разные нестандартные библиотеки не всегда.

Большая фирма делает большой софт для серьезных дядек под закрытой лицензией без предоставления исходников, серьезные дядьки хотят пускать софт на over 9000 разных платформ. Это раз. Два, серьезные дядьки не всегда хотят иметь извращения со сборкой софта из исходников, и даже у больших фирм может не быть ресурсов для того, чтобы собирать весь свой софт под всякую экзотику.

Нет ничего нового под небом и все это реализуется так, как сделано в высокоуровневых языках. Например, проверка границы массива. Ее можно писать ручками в С, она забирает время и место. Можно использовать готовую в питоне/бейсике/подставьте_свой_вариант. Она тоже жрет ресурсы, но больше: проверяется все, что нужно и не нужно проверять. По.другому никак, если только не присобачить туда оптимизирующий JIT или не предусмотреть для байткода комманд типа "а вот тут мы входные данные не проверяем"

> Тут все упирается в то, что все проги надо проверять и подписывать. Иначе система не имеет смысла.

На самом деле -- вовсе нет. Можно реализовать защиту памяти без MMU, так что можно будет безопасно запускать "неопознанный" код, при условии что код -- в байткоде VM, и перед запуском компилируется JIT-ом, т.е. вариант "заранее заготовленного" байткода не рассматривается, т.к. его можно запретить административно.

С учетом вышесказанного, размышления о защите можно перенести в мир виртуальной машины (при условии что в JIT нет багов), тогда защита памяти может быть организована очень примитивно -- процесс при рождении получает в наследство два-три хендла-описателя, по сути, нечто вроде сегментных регистров, и память процесс может адресовать только в пределах регионов, заданных в хендлах. Теоретически, если кто-то процессу передаст хендл другого процесса, то он сможет получить доступ к чужой памяти, но на это должна быть добрая воля другого процесса и поддержка со стороны API системы по пересылке хендлов между процессами.

Вот как-то так...