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

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

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

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

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