Comments 16
На С++? А как-же "Использование безопасного языка программирования"? Я думал, они на Rust операционку пишут. Это было-бы реально безопасно.
Когда игралось с Singularity, никакого Rust не существовало.
C# с модификациями
Почему C++?
Не, там всё гораздо интереснее... Если я ничего не путаю (за давностью лет, увы, мог что-то и забыть), основной язык там Sing#, который расширяет Spec# для описания тех самых каналов, которые описываются в статье.
А Spec#, в свою очередь, это С# (на момент 2004 года, т.е. это C# v1.1), дополненный элементами контрактного программирования (от привычных уже not-nullable types, до весьма навороченных типа пред-/пост- условий, и т.д.)
Т.е. там получалась цепочка: программа/драйвер/модуль ядра пишется на управляемом языке (C#/Spec#/Sing#/ ... - в зависимости от того, какой уровень верификации требуется), компилятор выдает MSIL код, снабженный всякими доп. атрибутами.
В момент развертывания это всё докомпилируется в нативный код и верифицируется специальным компилятором, благодаря чему мы и получаем безопасный код.
На самом деле там (в Singularity) проделана громадная работа, которая, увы, осталась невостребованной (опять же, на сколько я знаю - но может быть я тут не прав и кто-то сможет дополнить).
Нет, не взлетит. Для того что бы создать что то новое если это касаеться сингулярности, необходимо создавать новые инструменты, новые практики и подходы. К примеру возьмём такой простой пример как станок для выреза по металу. Так вот мы не можем просто так с нуля создать станок который будет резать до одно микрона, это всё этапы, с начало крупные детали а потом всё менее и менее. А SingularityОС использует старые инструменты, на счёт практи и подходов не не скажу.
Для того что бы создать что то новое если это касаеться сингулярности, необходимо создавать новые инструменты, новые практики и подходы
А чем вас не устраивает перечисленное в статье? Там было реально создано новое - управляемый язык, заточенный под нужды системной разработки.
Ну и подходы - уход от аппаратной защиты на уровне отдельных процессов, в сторону верифицируемого кода, исполняющегося в едином адресном пространстве?
Как по мне - вполне.
SIP не может создавать новые указатели — указатели могут быть предоставлены из надежного источника, такого как ядро.
Т.е. byte* data = (byte*)0xDEADBEEF не прокатит? Мне очень интересно, как это вообще в принципе может быть реализовано.
За счет использования промежуточного языка (MSIL), у которого подобная операция (получение произвольного указателя) не реализована.
В принципе, понятие указателя и адресной арифметики в MSIL есть (хоть и очень ограниченное), но их можно контролировать или вовсе запретить.
А виртуальная машина съест весь выигрыш в производительности…
Смотря что вы понимаете под "виртуальной машиной". Например, если взять какой-нибудь классический учебник по архитектуре компьютера или ОС, то там наверняка будет предложено рассматривать ОС как виртуальную машину, изолирующую программы от аппаратуры.
Но я так понимаю вы спрашиваете о том, что ОС занимается интерпретацией инструкций промежуточного языка? Нет, это не так.
Как я писал в соседнем комментарии, базовая идея этого исследовательского проекта (ну или как минимум одна из идей) была в том, чтобы использовать для разработки managed code/managed environment, в котором(ой) одна из составляющих - это компиляция программы не сразу в машинный код, а в некий промежуточный (P-code, байт-код), который:
- имеет ограниченный набор инструкций (в том смысле, что там нет привилегированных команд, типа переключения контекста или записи в порты ввода-вывода)
- не имеет команд прямого обращения к памяти по адресу - вместо этого он везде использует обращения к конкретным структурам: локальным переменным, полям объектов, элементам массива, ...
- использует контролируемые механизмы выделения памяти (т.е., например, по запросу можно создать объект и получить его адрес, к которому можно потом будет применить команду из предыдущего пункта, но нельзя просто "получить простой кусок памяти").
Далее, такой промежуточный код докомпилируется в машинный код конечной платформы (это происходит или в момент выполнения, или в момент развертывания - т.е. мы исключаем вариант "установили готовый бинарник, заявив, что он безопасный, а на деле нет"). Исходно это задумывалось для целей переносимости, но здесь это играет еще и роль механизма безопасности - вы просто физически не можете в терминах промежуточного языка описать небезопасное поведение. А если оно всё же потенциально возможно, есть дополнительные проверки в момент докомпиляции.
Понятно, что когда тот же драйвер должен обращаться непосредственно к оборудованию, он делает это через небольшую прослойку HAL (hardware abstraction layer), которая написана на неуправляемом языке. Но:
- это ооочень маленькая часть кода
- обращение к таким API тоже можно контролировать (в runtime или в момент докомпиляции - это уже надо смотреть).
Ну вот собственно Singularity и должна была дать ответ на вопрос:
- на сколько такая схема жизнеспособно
- можно ли при использовании managed кода (который всё же несколько уступает по скорости unmanaged - там всё не так очевидно, но давайте не будем здесь углубляться), получить сравнимую производительность в достаточно низкоуровневых операциях, за счет убирания механизмов аппаратной защиты и необходимости переключения контекста.
Как бы ответ на оба вопроса - Да.
Ответ на оба вопроса очевидно нет. Поэтому МС и остановила разработку. Дорастовская попытка ограничить возможности программера языком ппрограммирования вместо интеллектуального анализа исходного кода и указания проблемных мест. Раст идёт в тот же тупик.
Ответ на оба вопроса очевидно нет.
Вы можете свое утверждение как-то подтвердить?
Мои аргументы:
- за пару лет небольшой команде исследователей удалось создать ОС с поддержкой приличного набора функционала. Тут и сетевой стек, и файловая система и работа с аппаратурой. При этом, помимо самой ОС (которая разрабатывалась на совсем не традиционных принципах), было сделана еще куча доработок, а также статьи, тесты, ... Так что результат - схема рабочая
- ну а тесты производительности в самой статье.
Дорастовская попытка ограничить возможности программера языком ппрограммирования вместо интеллектуального анализа исходного кода и указания проблемных мест.
А где вы увидели ограничения языка программирования? Я говорил о контроле на уровне промежуточного кода. MSIL это вполне себе высокоуровневый ассемблер. Да, он запрещает прямой доступ к памяти по адресу, но имеет огромные возможности по обращению к известным структурам (т.е. тем, для которых известна вся метаинформация).
Ну а анализ там всё равно присутствует. Даже штатный JIT в .Net делает достаточно много различных (пусть и не очень "интеллектуальных" проверок).
А конкретно в Singularity при компиляции используется Boogie (это язык и среда для верификации программного кода). Как именно и в каких местах, увы, не подскажу, но если посмотреть исходные коды, то там обнаружится куча файлов с расширением .bpl (BoogiePL)
Поэтому МС и остановила разработку.
Разве?
На сколько я помню, формальная причина закрытия проекта звучала как-то очень обтекаемо как раз в стиле "мы сделали всё планировавшееся и переходим к новым проектам".
А то, что конкретно этот проект не продолжил развитие, так это логично - какова ниша этой разработки?
Если бы у MS не было на тот момент собственной ОС, которая её полностью устраивала я бы еще поверил в то, что она может очертя голову броситься в проект разработки новой ОС. Но даже если бы Singularity показала бы какие-то бешенные результаты - сколько еще требуется вложить, чтобы довести её хотя бы до уровня ОС середины 90-х?
Ну а других ниш, интересных MS на тот момент я не вижу (Embedded была занята Windows CE, ОС для микроконтроллеров были практически не распространены или там жило что-то уровня MS DOS, ... что еще?)
Странно, что про https://github.com/CosmosOS/Cosmos никто не пишет.
Это ос на dotnet. Но пока не очень популярна. Отличается от singularity лицензией, для сборки потребуется Windows. Для запуска - VMware
Singularity — экспериментальная ОС от Microsoft