Re[5]: Очередная русская ОС
От: FR  
Дата: 28.07.10 15:00
Оценка:
FR>Можно верифицировать жестко ограниченное подмножество x86 кода и это уже сделано например тут
FR>http://code.google.com/p/native-nt-toolkit/ но боюсь драйверы на таком подмножестве тоже не особо попишешь.

С ссылкой промахнулся http://code.google.com/p/nativeclient/
Re[4]: Очередная русская ОС
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.07.10 15:08
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:


G>>Здравствуйте, okman, Вы писали:


O>>>С другой — трудно представить работоспособную архитектуру, которая не поддерживается

O>>>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и
O>>>вообще системные сервисы типа переключения контекстов или управление виртуальной
O>>>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни.
O>>>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ?
O>>>Разработчики современных архитектур тоже не дураки ведь.

G>>Главное преимущество managed кода знаешь?

G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.


G>>Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).


G>>Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.


G>>Так работает Singularity.


A>Если бы драйвер не делал ничего потенциально криминального, его не надо было бы и компилировать как то отлично от другого кода. Вообще бы не нужно было делать различия на программы и драйверы.

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

A>А если его компилировать статически в нативный код, то верификацию произвести не получится.

Верификация делает перед компиляцией в нативный код.

A>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.

С чего ты взял?

A>Так что по любому в драйвере будут потенциально опасные места.

Не увидел обоснования.
Re[3]: Очередная русская ОС
От: okman Беларусь https://searchinform.ru/
Дата: 28.07.10 15:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Главное преимущество managed кода знаешь?

G>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

Аппаратные средства нужны для поддержки механизмов Фантома, о которых рассказывал Д. Завалишин.
Для таких сакральных вещей, как переключение контекста или сброс страниц памяти в файл подкачки,
в большинстве современных компьютерных архитектур поддержка заложена на уровне железа.
Без этой поддержки все держалось бы на честном слове.
Как-то не верится, что архитектурные решения Фантома можно качественно реализовать
исключительно программно.

А Singularity — это все-таки немного другое.
И, кстати, я не согласен с тем, будто managed-код исключает возможность "отстрелить себе ногу"...
Re[5]: Очередная русская ОС
От: Aleх  
Дата: 28.07.10 15:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Aleх, Вы писали:


A>>Здравствуйте, gandjustas, Вы писали:


G>>>Здравствуйте, okman, Вы писали:


O>>>>С другой — трудно представить работоспособную архитектуру, которая не поддерживается

O>>>>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и
O>>>>вообще системные сервисы типа переключения контекстов или управление виртуальной
O>>>>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни.
O>>>>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ?
O>>>>Разработчики современных архитектур тоже не дураки ведь.

G>>>Главное преимущество managed кода знаешь?

G>>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.


G>>>Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).


G>>>Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.


G>>>Так работает Singularity.


A>>Если бы драйвер не делал ничего потенциально криминального, его не надо было бы и компилировать как то отлично от другого кода. Вообще бы не нужно было делать различия на программы и драйверы.

G>Еще раз: чтобы провести верификацию нужно поднять райнтайм, чтобы поднять рантайм нужен драйвер.
G>Твои предложения?
Драйвер отвечает за верификацию? В общем я эту фразу не понял.
Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения.
Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее.

A>>А если его компилировать статически в нативный код, то верификацию произвести не получится.

G>Верификация делает перед компиляцией в нативный код.
Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов.

A>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.

G>С чего ты взял?
Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать?
Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов.

A>>Так что по любому в драйвере будут потенциально опасные места.

G>Не увидел обоснования.
Re[4]: Очередная русская ОС
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.07.10 17:38
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, gandjustas, Вы писали:


G>>Главное преимущество managed кода знаешь?

G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

O>Аппаратные средства нужны для поддержки механизмов Фантома, о которых рассказывал Д. Завалишин.

O>Для таких сакральных вещей, как переключение контекста или сброс страниц памяти в файл подкачки,
O>в большинстве современных компьютерных архитектур поддержка заложена на уровне железа.
O>Без этой поддержки все держалось бы на честном слове.
O>Как-то не верится, что архитектурные решения Фантома можно качественно реализовать
O>исключительно программно.
Страничная адресация — то что должно поддерживаться железом, желательно чтобы для кода (в том числе изкоуровневого) была иллюзия непрерывного бесконечного адресного пространства.
А вот насчет переключений — сейчас гораздо эффективнее работают планировщики пользовательского режима (см erlang), с управляемым кодом можно такую же парадигму вынести на уровень всей ОС.



O>А Singularity — это все-таки немного другое.

O>И, кстати, я не согласен с тем, будто managed-код исключает возможность "отстрелить себе ногу"...
Он не исключает, об этом никто и не говорит, но очень сильно усложняет эту возможность, особенно случайных ошибок.
Аппаратные механизмы защиты тоже не очень-то защищают от преднамеренных атак.
Re[6]: Очередная русская ОС
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.07.10 17:49
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Драйвер отвечает за верификацию? В общем я эту фразу не понял.

Нет, за верификацию отвечает рантайм (CLR\JVM\еще_что_то).

A>Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения.

A>Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее.
А в Singularity прокатила.
Причем это рабочая ось, которую можно скачать и пощупать.

A>>>А если его компилировать статически в нативный код, то верификацию произвести не получится.

G>>Верификация делает перед компиляцией в нативный код.
A>Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов.
Это ты предполагаешь не подтверждая формальными выкладками или фактами.

A>>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.

G>>С чего ты взял?
A>Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать?
Мда...
Элементарно решается, все опасные вызовы упаковываются в библиотеки, а доступ к ним регулируется специальными правами. Даже сейчас так работает.
Ассемблера в принципе не должно быть в управляемом коде, так как он должен абстрагировать от конкретной физической архитектуры.

A>Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов.

Применение С и ассемблера в особо впечатлительном возрасте видимо дает серьезный эффект.
Re[7]: Очередная русская ОС
От: Aleх  
Дата: 28.07.10 18:04
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Aleх, Вы писали:


A>>Драйвер отвечает за верификацию? В общем я эту фразу не понял.

G>Нет, за верификацию отвечает рантайм (CLR\JVM\еще_что_то).

A>>Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения.

A>>Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее.
G>А в Singularity прокатила.
G>Причем это рабочая ось, которую можно скачать и пощупать.

A>>>>А если его компилировать статически в нативный код, то верификацию произвести не получится.

G>>>Верификация делает перед компиляцией в нативный код.
A>>Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов.
G>Это ты предполагаешь не подтверждая формальными выкладками или фактами.

A>>>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.

G>>>С чего ты взял?
A>>Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать?
G>Мда...
G>Элементарно решается, все опасные вызовы упаковываются в библиотеки, а доступ к ним регулируется специальными правами. Даже сейчас так работает.
G>Ассемблера в принципе не должно быть в управляемом коде, так как он должен абстрагировать от конкретной физической архитектуры.

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

A>>Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов.

G>Применение С и ассемблера в особо впечатлительном возрасте видимо дает серьезный эффект.
Re[8]: Очередная русская ОС
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.07.10 18:07
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Гы, ну я так и думал, что это будет предложено. Только вот проблема в том, на чем ты эти библиотеки напишешь? Тоже на управляемом коде?

Можно на управляемом коде, но тогда вопрос генерации нативного кода ложится на рантайм.
В любом случае часть кода рантайма будет нативной и верифицироваться будет только вручную.
Почитай про Singularity, много интересного узнаешь.
Re[3]: Очередная русская ОС
От: batu Украина  
Дата: 28.07.10 19:09
Оценка:
Здравствуйте, rfq, Вы писали:

rfq>Здравствуйте, batu, Вы писали:


B>>Первое впечатление, что декларируемая задача в императивной парадигме не решаема.

rfq>...
B>>Реально создать такую фишку в функциональной парадигме.
rfq>Поддерживаю 100%.
Я не помню по какому поводу я писал. Здесь недавно и не знаю как восстановить последовательность сообщений. Спасибо за поддержку.


B>>Как быть с языками типа Си, джавы.. они ж императивные..

rfq>ПисАть на них чистые функции. Скажем, компилятор легко оформляется в виде функции текст->код.
"Чистые функции" отличаются из императивных только доступом к внешним объектам. У себя в языке я сделал оператор легализации "With". Синтаксис следующий
"With" Имя Путь_к_внешней переменной [Легализация].
Дальше, очевидно, имеем возможность анализировать. Кстати, этот оператор может использоваться просто для сокращения текста и с внутренними переменными.
rfq>Конечно, мы не сможем сохранять промежуточное состояние в процессе компиляции (точнее сможем с большим трудом и негрантированым результатом — так что лучше и не пытаться). Но зачем, если компиляция одного текста длится миллисекунды, максимум — секунды.
rfq>При перезапуске начнем снова. А утилиту make (или ant) — напишем заново.
rfq>Собственно, этот пример не совсем удачный, так как связка make — компилятор и сейчас обеспечивает сохранение основного объема работы при сбоях. Но эта функциональность базируется на шатком основании — времени модификации файлов. Дело за тем, чтобы найти более прочный фундамент. Можно, например, оттолкнуться от баз данных и встроенных процедур.
Я предложил другой вариант. Создать такой формат, что и после трансляции сохранить прямую связь "оттранслированые объекты"-"Объекты текстовые программы". Если я правильно понял проблему. Вообще я против модификации файлов в результате трансляции. Есть вариант архитектуры машины с дополнительной адресной лентой. Тогда порядок физический размещения объектв остается неизменным, а выполнение происходит в порядке необходимом по результату трансялции. Там еще есть всякие подроности и их много.. Их так много.. что мою идею мало кто понял. Начиная с букв, групп, представлением объекта и т.д..
Re[6]: Очередная русская ОС
От: Nik_1 Россия  
Дата: 30.07.10 10:44
Оценка:
Здравствуйте, Mamut, Вы писали:
M>Потому что 90% этого софта использует код, написаный как раз лет 10-15 тому назад, когда Java только появлялась. Legacy такой legacy.
О, так на твоем любимом айфоне уже появилась жава?
Re[7]: Очередная русская ОС
От: Mamut Швеция http://dmitriid.com
Дата: 30.07.10 10:52
Оценка: -1
M>>Потому что 90% этого софта использует код, написаный как раз лет 10-15 тому назад, когда Java только появлялась. Legacy такой legacy.
N_>О, так на твоем любимом айфоне уже появилась жава?

При чем тут мой айфон к данной подветке?

Тролли такие тролли


dmitriid.comGitHubLinkedIn
Re[3]: Очередная русская ОС
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 30.07.10 18:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Главное преимущество managed кода знаешь?

G>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

А что именно значит "ничего криминального"? Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль? Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы? Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?
Возможности статической верификации настолько ничтожны, что я вообще с трудом представляю, от каких же вещей она способна защитить.
Re[4]: Очередная русская ОС
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.07.10 19:12
Оценка: 6 (1)
Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, gandjustas, Вы писали:


G>>Главное преимущество managed кода знаешь?

G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.

DM>А что именно значит "ничего криминального"?

Я с теорией верифцирования не сильно знаком, но верификация и сейчас производится.

DM>Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль?

Вряд ли, верификатор не будет арифметические ошибки ловить.

DM>Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы?

Это не верификатора работа, а реализации "массива", а верификатор удостоверится что реализация массива гарантирует что не будет обращения к памяти за пределами выделенной.

DM>Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?

А если не надо знать, ему достаточно знать что вызываемая функция тоже ничего "криминального" не делает.

DM>Возможности статической верификации настолько ничтожны, что я вообще с трудом представляю, от каких же вещей она способна защитить.

Это они в твоей голове ничтожны, а люди умудряются даже C_шый код верифицировать.
Смотри nativeclient и vcc.

Верификация не обязана проверять твою программу на соотвествие спецификации (у верификатора чато и нету спецификации), но верификатор может проверить программу на отсутствие нарушений памяти, обращений по невалидным указателям итп.
Причем если две программы гарантировано не будут обращаться к не своей памяти, то они вполне могут работать в одном адресном пространстве, без аппаратных средств защиты.
Re[4]: Очередная русская ОС
От: . Великобритания  
Дата: 30.07.10 23:17
Оценка: 6 (1)
On 30/07/10 21:56, D. Mon wrote:
> А что именно значит "ничего криминального"?
Если вспомнить, что такое защищённый режим процессора, то становится понятно.
В кратце: есть 2 набора инструкций процессора — защищённый набор и общий. В защищённый набор обычно входят всякие плохие вещи, типа управление портами, памятью, ресурсами и т.п., которые необходимы для работы компьютера, но должны строго контролироваться операционкой.
Зачем вообще этот защищённый режим? А чтобы обеспечить защиту, как ни странно. Т.е. обычные приложения запускаются в общем режиме. Если приложению требуется обращение к порту, то оно делает системный вызов, вызов функции операционной системы. А ОС уже может по всяким хитрым условиям проверить легальность вызова.
В итоге получается — можно загрузить произвольную последовательность байт в память и начать его выполнение. Всё нелегальное отлавливается аппаратной защитой CPU (проц тупо отказывается выполнять инструкцию, если её код из защищённого набора), и программно — системным API (операционка проверяет, что юзер правильный, есть права, и т.п.).

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

Так что же такое верифицируемый код. Это когда на выполнение берётся не произвольный набор байт, а программа на некоем низкоуровневом языке типа ассемблера. И этот язык спроектирован таким образом, что его очень легко проверить на наличие плохих вещей. Т.е. это избавляет от необходимости аппаратной защиты. Например, отсутствие адресной арифметики и указателей, даёт контроль над адресным пространством. Это избавляет от необходимости иметь аппаратную защиту. Загружаем байт-код, верифицируем, если всё ок — можно быть уверенным, что непра�
�ильных инструкций нет, никто в порт не залезет.

Вот примерно так, на пальцах.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Очередная русская ОС
От: Mr.Delphist  
Дата: 09.08.10 08:11
Оценка: :)
Здравствуйте, Nik_1, Вы писали:

N_>Ещё один пример — когда лет десять назад появилась Java (как язык программирования), производительность программ на Java была катастрофически хуже, чем производительность программ на C++. Что не помешало Java "вынести" C++ просто с корнями. Можно считать, что C++ сейчас не существует, а Java сегодня — язык номер один.

N_>[/q]

Вау, кул и всё такое. А потом просыпаешься и снова идешь программировать на C++ и C#
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.