Про CLR security

[wizzard0]

...aka "что удерживает меня от перехода с Microsoft'овского стэка на что-то другое"

Пост родился из продолжительной дискуссии с _sorcerer на тему "а чем NaCl хуже?", которая продолжилась в духе "но лучше ведь сделать нельзя", а чтобы не шерстить свои заметки по второму кругу - решил вынести ссылки из коммента в пост

Comments

[soonts]

Интересно, зачем WinPhone8 использует NT ядро, вместо чудесной Singularity/Midori/Verve?
Не говорит ли это о том, что есть какие-то фундаментальные недостатки у этого подхода, про которые я не знаю?
Или тупо из-за возможности компилировать C++ библиотеки?

[nponeccop]

Причина, думаю, в том, что это прототипы, а ядро NT - продукт. Разный уровень качества.

Я бы на месте МС начал с того, что выпустил бы как отдельный продукт аппликейшен сервер на основе Singularity/Midori/Verve

[wizzard0]

вот кстати да

[soonts]

>выпустил бы как отдельный продукт аппликейшен сервер на основе Singularity/Midori/Verve
Думаю не взлетит.
1. Тупо из-за возможности компилировать C++ библиотеки. Например и MSSQL, и MS Office вряд ли в обозримом будущем портируют на managed code.
2. На серверах попадаются HASP ключи, tape drives, сторонние коммерческие software компоненты, странное hardware (система контроля доступа например), и т.п.

А вот для windows phone не вижу особых препятствий.

[sleepy_drago]

я не понимаю как это можно обсуждать снаружи мс так как все что они пытались наружу так и не ушло.

[soonts]

http://singularity.codeplex.com/

[wizzard0]

опа! а я и не знал. охуеть. пошел качать.

[soonts]

Основной минус - Non-Commercial Academic Use Only

а можно пояснить в двух словах?

[ext_1601618]

> понятно, что можно руками нарисовать на методе formatDisk, что его могут вызывать все, но это можно статически обнаружить, что в Джаве невозможно

Насколько я понимаю, при наличии рефрексии вообще статически ничего обнаружить невозможно. Потому что как только мы имеем Class.forName, так весь статический анализ пошел лесом, потому что ни классов, ни методов мы больше не знаем.

Ну то есть, в каком-то смысле и получается "но лучше ведь сделать нельзя". Если не запретить рефлексию как минимум.

Re: а можно пояснить в двух словах?

[wizzard0]

Ты можешь получить ссылку на метод. Можешь динамически сконструировать код метода.

Но при *вызове* метода он пойдет через верификатор.

Можешь сделать интерпретатор и проинтерпретировать. Но, опять же, FFI пойдет через верификатор.

Re: а можно пояснить в двух словах?

[ext_1601618]

> Ты можешь получить ссылку на метод.
Я для начала имел в виду вот этот случай.

О каком _статическом_ анализе может идти речь, если мы не знаем, какие именно методы каких классов могут быть вызваны? Динамическое конструирование байткода и т.п. - история отдельная, но это и не нужно (в JVM), чтобы получить ссылку на метод и вызвать его с произвольными параметрами. Все что мы при статическом анализе можем узнать - это то, что код будет пользоваться рефлексией.

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

> Но при *вызове* метода он пойдет через верификатор.
Ну и из этого как бы следует, что верификация не статическая.

Я это к чему - я недостаточно внимательно пока читал ссылки (потому и спрашиваю), но никакой принципиальной разницы описанного для .Net 4 с JVM вот так вот с первого взгляда не вижу. И почему это должно быть безопаснее в целом - не очень пока понятно.

Re: а можно пояснить в двух словах?

[wizzard0]

> Ну и из этого как бы следует, что верификация не статическая.
Почему? Декларативная, во