inferno singularity

Ну напиши реализацию. Ах да, смотри в сторону Трансмета. Плюс MMU жрет меньше ресурсов.

Вопрос в другом, разве нельзя залезть в чужую память? И кстати была какято чудна система безопасности для линукса анализировавшая сорцы и на их основе строящая правила,

>> Вопрос в другом, разве нельзя залезть в чужую память?

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

Забавно, так вот чем они занимались. Эльбрус из той же оперы.
А почему MMU жрет меньше ресурсов? Про singularity я читал, что она наоборот экономят ресурсы не используя MMU.

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

переполнения всякие?

>> А почему MMU жрет меньше ресурсов?

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

>> переполнения всякие?

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

Не понимаю. Вот две программы. Одна видит 0-4*2^32 кусок памяти. Вторая видит другой такой-же кусок. И эти куски памяти никак не пересекаются. Это виртуальная память. И при чем тут переполнения?

Я просто предположил.. Выше объяснили, что я не прав..

Ну даже если не полностью отказываться от MMU, а просто использовать одно адресное пространство для запуска всего оттранслированого кода - разве это не будет выгодно. Иначе я просто не понимаю в чем польза этих Software Isolated Processes.

>> Ну даже если не полностью отказываться от MMU, а просто использовать одно адресное пространство для запуска всего оттранслированого кода - разве это не будет выгодно. Иначе я просто не понимаю в чем польза этих Software Isolated Processes.

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

Насколько я знаю, в singularity трансляция может быть и не во время исполнения, т.е. просто скомпилированный бинарник.
Не особо в теме, наверное там нету изменяемых указателей (из программы), т.е. выход за пределы дозволенного просто не возможен, т.к. программисту не доступны такие средства.

ну можно транслировать *ptr в *(base + ptr%size).
и программисту будут не доступны такие средства

так в чем сакральный смысл виртуальной машины?

Спроси у сана)) А если серьезно, то это пуруносимо без бубна и можно своидть всякую фигню под одну крышу. Просто всегда находятся фанатики, которые свой любимый фантик пихают во всякую дырку.

>> и программисту будут не доступны такие средства

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

Ну или распространять в байт коде, который будет компилится перед первым запуском или во время выполнения.

C переносим.
bitC переносим.
libc переносим, ну я не знаю, что еще надо.

Ну да, конечно. Транслированный код отдельно и доступен только ядру.

> Вопрос в другом, разве нельзя залезть в чужую память?

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

Мы про маппинг.
Вообще я что-то долго тупил.
Смысл использования верификатора байткода для защиты памяти в том, чтобы избежать смены контекстов. А это дает возможность эффективно реализовать микроядерную архитектуру. Правда врядли можно странслировать машинный код в эффективный безопасный код. Но ведь идея то неплохая?

>Смысл использования верификатора байткода для защиты памяти в том, чтобы избежать смены контекстов.

это скорее всего не разрешимая проблема, пока вся программа до конца не будет отработана, нужны какие-нибудь дополнительные ограничения

>> C переносим.

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

Ну я не имел в виду полный статический анализ. При верификации байткода он же не производится.

А зачем нужны переносимые бинарники, я не слишком понимаю?

Что если адреса зависят от входных данных (так всегда и бывает) ? придется добавлять рантайм проверки, и скорее всего не оптимальным способом, это дороже по времени выполнения, чем аппаратный MMU. Или как ещё это сделать?

>> А зачем нужны переносимые бинарники

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

>> Что если адреса зависят от входных данных (так всегда и бывает) ? придется добавлять рантайм проверки, и скорее всего не оптимальным способом, это дороже по времени выполнения, чем аппаратный MMU. Или как ещё это сделать?

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

>>> и программисту будут не доступны такие средства

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

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

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

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