Можно ли запустить «родной» код поверх управляемой ОС?

Question

Я читал об Мидори, и мне стало интересно, возможно ли это.

В управляемой ОС «управляемый код» будет нативным, а «собственный код» будет ... чужим? Можно ли хотя бы теоретически запустить сегодняшний код на управляемой ОС сегодня?

Answer 1

Во-первых, вы должны начать с определения «управляемый» и «нативный». В «управляемой» ОС, такой как Midori, ядро ​​все еще ngen-ed (предварительно скомпилировано в машинный код), а не jit-компилируется из IL. Так что я бы исключил это как различие между «управляемым» и «нативным».

Есть два других различия между «управляемым» и «нативным» кодом, которые приходят мне на ум - способность к защите кода и управление ресурсами.

Большая часть "нативного" кода не поддается проверке, поэтому "управляемый" загрузчик ОС может отказаться даже загружать "нативные" образы. Конечно, можно создавать проверяемый «нативный» код, но это накладывает множество ограничений и по сути ничем не отличается от «управляемого» кода.

Ресурсы в «управляемой» ОС будут управляться ОС, а не приложением. «Нативный» код обычно выделяет и очищает свой ресурс. Что произойдет с ресурсом, который был выделен API-интерфейсом ОС и передан «родному» коду? Или наоборот? Должны быть достаточно четкие правила относительно того, кто и когда будет заниматься управлением и очисткой ресурсов. По соображениям безопасности я не могу представить, чтобы ОС давала непосредственный контроль над «родным» кодом каким-либо ресурсам, кроме виртуальной памяти процесса. Следовательно, единственная причина, по которой стоит переходить на «родной» режим, - это реализовать собственное управление памятью.

Сегодняшний код natve не воспроизводится по любому из приведенных выше правил. Таким образом, «управляемая» ОС должна отказаться от ее непосредственного выполнения. Однако «управляемая» ОС может обеспечивать уровень виртуализации, такой как Hyper-V, и размещать «родной» код на виртуальной машине.

Answer 2

Под управляемым я предполагаю, что вы имеете в виду, что код выполняется в среде, которая выполняет некоторые проверки кода на предмет безопасности типов, безопасного доступа к памяти и т. Д. И собственно, ну, наоборот. Теперь это среда выполнения, которая определяет, можно ли разрешить выполнение собственного кода без проверки. Посмотрите на это следующим образом: ОС и приложению наверху для выполнения требуется среда выполнения. Их единственное отношение состоит в том, что приложение верхнего уровня вызывает базовую ОС для задач более низкого уровня, но при вызове ОС, которое фактически выполняется ENV выполнения (который может / не может поддерживать проверку кода в зависимости, скажем, от параметров, переданных, например, при компиляции кода), и когда управление передается в ОС, ENV выполнения снова отвечает за выполнение кода ОС (эта среда может быть еще одно решение), в этом случае он проверяет код ОС (потому что это управляемая ОС).

Таким образом, теоретически собственный код может / не может работать в управляемой ОС. Все зависит от поведения среды выполнения, в которой он запущен. Независимо от того, является ли ОС управляемой или нет, это не повлияет на то, будет ли она работать на ней или нет. Если приложение верхнего уровня и ОС имеют одинаковое выполнение env (управляемое), то собственный код не будет работать в ОС.

Answer 3

Из статьи MS Research Сингулярность: переосмысление программного стека (p9):

Домен защиты, в принципе, может содержать один процесс содержащий непроверяемый код, написанный на небезопасном языке, таком как C ++. Хотя это очень полезно для запуска устаревшего кода, мы не пока исследовал эту возможность. В настоящее время весь код внутри домен защиты также содержится в SIP, который продолжается для обеспечения границы изоляции и локализации отказа.

Так что кажется, что, хотя на данный момент не исследовано, это вполне вероятная возможность. Неуправляемый код может выполняться в защищенном от аппаратного обеспечения домене, что приведет к снижению производительности из-за необходимости иметь дело с виртуальной памятью, TLB и т. Д., Но система в целом может безопасно поддерживать свои инварианты при выполнении неуправляемого кода.

Answer 4

Технически, эмулятор собственного кода может быть написан в управляемом коде, но он не работает на голом оборудовании.

Я сомневаюсь, что любая управляемая ОС, которая использует проверку программного обеспечения для изоляции доступа к общим ресурсам (например, Singularity), позволяет напрямую запускать неуправляемый код, поскольку она может обойти все средства защиты, предоставляемые программным обеспечением (в отличие от обычных ОС, некоторые управляемые Операционные системы не полагаются на методы защиты, предоставляемые оборудованием).