Тут вопрос в реализации. И в "ломкости" этой реализации.

Можно написать компилятор, который "не даёт допускать ошибки" - в котором не предусмотрено совершения действий, которые могли бы "подломать" ядро (собственно, как я понимаю, большинство новых языков так и устроены). Но встаёт вопрос - а если хакер написал программу "в машинных кодах", игнорируя компилятор - защитится ли от него ядро?

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

И тут, в общем-то, и возникает вопрос. Эффективность можно поднять, отказавшись от аппаратной защиты, и свалив защиту на компилятор. Но надежно ли это? И насколько эффективней будет другой вариант аппаратной защиты - без "экспешнов", но с невозможностью создать произвольный указатель?...

Трудно сказать - вероятно аппаратная реализация может быть более надежной. Ее конечно можно заменить виртуальной песочницей, она будет достаточно тупой и верифицируемой - в конце концов CPU тоже люди делают, но такое решение не очень производительное.

***

Что касается конкретно Singularity - там используется модификация C# - на нем гарантировано ничего нельзя поломать (если нет ошибок в компиляторе), там есть какие-то дополнительные политики для объявления интерфейсов - это им нужно было для защиты объектов и более гибкой изоляции.

Когда я читал про это - они говорили, что у них на подходе новый вариант MSIL (ассемблер .net), на котором доказано, что нельзя будет написать компромитирующий код. Как они утверждали - это позволит качественно повысить защищенность ядра, т.к. компилятор MSIL имеет высочайшую надежность по сравнению с C# и даст возможность использовать другие языки.

На входе в Singularity программа на MSIL, поэтому поломать не получится таким образом.

Если им удастся полностью изолировать пользователя и реальный код (т.е. ситуация что что-то читается с диска и передаётся на выполнение исключена полностью, на выполнение всегда передаётся "результат компиляции" - то да, задача в основном решена.
Правда, никуда не уходит вопрос об эффективности. Если не используется аппаратная защита, то как я понимаю - используются обычные range checking в нужных местах? Если так - эффективно ли это? Или им удалось придумать что-то, чтобы и аппаратной защитой не пользоваться, и без проверок обойтись?...

Грубо говоря это .net увеличенный до размеров ОС - идея в том, что изнутри нет способа что-то сделать плохое и уж тем более выполнять что попало.

Эффективность такая как сейчас в .net приложениях. Я кстати толковой информации на эту тему не видел. Падение скорости неизбежно и наверное есть задачи в которых весьма заметно.

В качестве отступления насчет range check - из своей работы: у нас есть конфигурации debug, release, gold. gold и release имеют идентичные настройки компиляции за исключением того, что в release все-же работают все проверочные ассерты, чтобы можно было логгировать критические ошибки. Ассертов очень много и конечно контейнеры имеют ассерты по диапазону. Так вот release и debug по производительности отличаютися незначительно - в пределах 10%, ну и конечно быстрее debug в несколько а то и в десять раз.

Т.е. конкретно по range check ситуация не критичная. Может быть сборщик мусора является более серьезной проблемой. Вообще интересно бы посмотреть исследования на тему производительности и узких мест .net.