WolfHound wrote:
> C>И для этой песочницы придется делать свою ОС (так как песочница должна
> быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян?
> А вот это уже не факт. Все что нужно это обеспечить поддержку
> типизированных каналов.
Для кода в песочнице надо обеспечить:
1. Виртуальную память.
2. Сервисы ОС (ФС, сеть, звук и т.п.)
То есть, фактически надо написать еще одну ОС, причем с полной защитой
памяти.

Спрашивается, а зачем тогда Fully Managed OS, если можно приложения на
C# запускать внутри одной разделяемой VM, работающей как приложение в
Unmanaged OS?

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

C>F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR вообще нельзя эффективно делать динамические языки (например, если JITить код из динамического языка в CLR, то можно очень быстро занять всю память — так как код не собирается GC).
Во втором фреймворке это не так. См System.Reflection.Emit.DynamicMethod.

К томуже как на основе косяков CLR можно делать выводы об управляемых ОС вобще?

WolfHound wrote:
> C>Делаем Code Access Security с гранулярностью равной процессу, и пусть
> оно себе переполняет что хочет.
> Ну оно и в современных ос так только вто что-то вирусам на это начхать.
Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды

CAS, кстати, в современных консумерских ОСах нет.

Lazy Cjow Rhrr,

LCR>>Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме.
WH>С этим спорить также глупо как спорить с тем что при плохом рантайме система будет стремится к неуправляемому состоянию гораздо быстрее.
Быстрее, да. Вот только "гораздость" под вопросом... Ладно, неважно.

WH>Ксати что за магия:N(LE)/N(RE)?
N — некоторая функция измеряющая ошибки. Пропорциональна количеству, но также и зависит от вида ошибок, LE — множество логических ошибок, RE — множество рантайм ошибок.

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

C>Для кода в песочнице надо обеспечить:
C>1. Виртуальную память.
На современном железе ее по любому обеспечивать придется.
C>2. Сервисы ОС (ФС, сеть, звук и т.п.)
Нет. Нужно только обеспечить работу каналов. Прочитай еще раз про сингулярити... там ФС, сеть, звук и вобщемто все остальное доступно исключительно через типизированные каналы. Следовательно если обеспечить работу каналов все это становится доступно.

C>То есть, фактически надо написать еще одну ОС, причем с полной защитой памяти.
Не придется.

C>Спрашивается, а зачем тогда Fully Managed OS, если можно приложения на C# запускать внутри одной разделяемой VM, работающей как приложение в Unmanaged OS?
За тем что как я показал выше писать вторую ОС не нужно. А приложения которым действительно нужен нативный код являются очень редким видом. Болие того разумным сценарием будет написание всего что можно на управляемом коде и вынос числодробилок в дочерний процесс.

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

WH>Можно. Только ОС должна быть управляемая. Например Singularity очень близка к идеалу. Там таких ошибок быть не может по тому что их не может быть в принципе. Ибо в это ОС большей части ядра и всем драйверам запрещено использовать неверфифицируемый код.
WH>Те ошибка может быть только в маленькой части ядра или в кодогенераторе. И то и другое реально отладить ибо это относительно небольшой объем кода.

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

Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте. Но эту возможность порой используют вполне нормальные программы

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

C>Андрей Хропов wrote:
>>> > Можно как в C# сделать safe/unsafe mode, если люди захотят.
>> C>Ты не понял. Singularity *ВООБЩЕ* запрещает unsafe. В любом его виде.
>> Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать
>> на Managed OS, достаточно будет переписать только unsafe кусок
>> (который, если грамотно делать, будет небольшим).
>> Что видимо и будет происходить с C# приложениями при возможном переходе
>> на fully managed OS.
C>А что будет с С++-приложениями?
Да, с этим тяжело.

C> Или с вполне безопасными Python и
C>Ruby-приложениями, для которых нет нормальных интерпретаторов под .NET?
Я думаю IronPython доделают. Не зря ж MS их нанял .
Ну и с Ruby принципиальных проблем быть не должно
(хотя я с ним вообще не знаком, так что мне трудно судить).

>> Для примера можешь привести реализацию того примера на boost.python
>> с временными характеристиками, было бы интересно.
C>А зачем?
А затем, что в том случае Влад показал, что взасчет того, что было легко сгенерировать код по описанию функции был достигнут значительный прирост в скорости.
Я не увидел, как с помощью boost.python можно сделать аналогично.

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

C>Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды
По тому что винды очень много и под нее выгодно писать вирусы.
В прочем меня они не беспокоят... правда исключительно из-за того что outpost и касперский работают не выключаясь.

C>CAS, кстати, в современных консумерских ОСах нет.
Хм... винда например очень не плохо следит за правами приложений. Ну и что что права вешают на пользователя. Кто мешает завести по пользователю на приложение?

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


MS>Ну хорошо. Вот у нас все-все сэйфее некуда. Что я делаю — беру динамический конртейнер и начинаю память кушать тоннами, пока система не окажется в глубокой свопе.

...

ЭЭэээ... Простите, а как Ваша программа попадет на удаленный компьютер? А если даже и попадет кто ей передаст управление? Ошибки переполнения буфера как раз таки позволяют это сделать. Вот когда научитесь исполнять свой код на удаленном компе тогда и память кушайте и руткиты устанавливайте и все на что фантазии и прав хватит.

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

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

D>Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте.
И как защитится от исправления идреса возврата в стеке? Код не выполняется вот только легче от этого не становится.
D>Но эту возможность порой используют вполне нормальные программы
За это авторов нужно от программирования отлучать. Навсегда.

Считается правильным использовать функции StringCchPrintf, или StringCbPrintf, остальные функции считаются depricated и на них MSVC2005 не двусмысленно ругается

WolfHound wrote:
> D>Кстати, частично (опять таки!) проблему можно решить запретив ОС
> исполнять код в стековом сегменте.
> И как защитится от исправления идреса возврата в стеке?
Есть такая замечательная штука — NX-bit.

WolfHound wrote:
> D>Кстати, частично (опять таки!) проблему можно решить запретив ОС
> исполнять код в стековом сегменте.
> И как защитится от исправления идреса возврата в стеке?
Есть такая замечательная штука — NX-bit.

> Код не выполняется вот только легче от этого не становится.
> D>Но эту возможность порой используют вполне нормальные программы
> За это авторов нужно от программирования отлучать. Навсегда.
Точно! Мааачить программистов CLR VM! (там это тоже используется).

WolfHound wrote:
> C>Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды
> По тому что винды очень много и под нее выгодно писать вирусы.
> В прочем меня они не беспокоят... правда исключительно из-за того что
> outpost и касперский работают не выключаясь.
А вот у меня вообще нет (не было и не будет) никаких резидентных
антивирусов. Так как это мастдай.

> C>CAS, кстати, в современных консумерских ОСах нет.
> Хм... винда например очень не плохо следит за правами приложений. Ну и
> что что права вешают на пользователя. Кто мешает завести по пользователю
> на приложение?
CAS означает ограничение доступа по определенным путям в коде. Например,
текстовый редактор может иметь полный доступ ко всем файлам (с учетом
прав, естественно), но получать новые handle'ы может только через диалог
открытия файлов.

WolfHound wrote:
> Во втором фреймворке это не так. См System.Reflection.Emit.DynamicMethod.
Только для отдельнных методов. Сборки так до сих пор и не собираются.

> К томуже как на основе косяков CLR можно делать выводы об управляемых ОС
> вобще?
Ладно, ладно. Тут я не прав.

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

C>А вот у меня вообще нет (не было и не будет) никаких резидентных антивирусов. Так как это мастдай.
Это уже религия пошла.

C>CAS означает ограничение доступа по определенным путям в коде. Например,
C>текстовый редактор может иметь полный доступ ко всем файлам (с учетом
C>прав, естественно), но получать новые handle'ы может только через диалог
C>открытия файлов.
Либо хендлы только через диалог открытия файла либо выделеное.

Делаем Code Access Security с гранулярностью равной процессу, и пусть оно себе переполняет что хочет.

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

C>Есть такая замечательная штука — NX-bit.
Как это спасает от изменения адреса возврата?

C>Точно! Мааачить программистов CLR VM! (там это тоже используется).
А где я говорил что CLR идеальна?

WolfHound wrote:
> C>Для кода в песочнице надо обеспечить:
> C>1. Виртуальную память.
> На современном железе ее по любому обеспечивать придется.
А тогда пропадут многие преимущества Fully Managed OS, работающей в
плоской памяти.

> C>2. Сервисы ОС (ФС, сеть, звук и т.п.)
> Нет. Нужно только обеспечить работу каналов. Прочитай еще раз про
> сингулярити... там ФС, сеть, звук и вобщемто все остальное доступно
> исключительно через типизированные каналы. Следовательно если обеспечить
> работу каналов все это становится доступно.
Ну так по сути драйвера современных ОС — это просто драйвера для
"каналов". Но только это не делает их проще.

Подумай, например, как ты будешь реализовывать каналы для показа
HDTV-видео или передачи информации в видеокарту из Doom3.

> За тем что как я показал выше писать вторую ОС не нужно.
Нужно. Например, что произойдет, если одно виртуальное приложение решит
запустить другое? А как насчет динамической подгрузки модулей?

> А приложения
> которым действительно нужен нативный код являются очень редким видом.
Сейчас это 99% (если не больше) всех приложений. Чтобы произошел переход
на Managed OS это число должно быть близко к 0.

Спрашивается, а нафига кому-то надо с ноля переписывать работающие
системы, чтобы в светлом будущем можно было сделать не особо нужную
Managed OS?

Вот сейчас реально есть IPv6, который уже используется в backbone-сетях
Интернета и поддерживается практически во всех OS (плевать, что в
некоторых ОСях только через командную строку). Почему все еще не перешли
на правильный и красивый IPv6?

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

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

D>>К сожалению подобная верификация кода проблемы не решает. Так как вообще никакого исполняемого кода на машину не принимается.
D>>Все представляется так, как будто принимается обычное сообщение по некоторому прикладному протоколу (например текстовому SMTP). Обработка этого сообщения приводит к неестественному поведению самого сервера. С точки зрения ОС все в норме: приняли запрос сохранили файлик, приняли другой запрос, опять таки сохранили. ОС и знать не знает, что это "приполз" черьвь, подгрузил свой "хвост" и уже свои копии сохраняет. После чего он безпрепятственно будет работать от имени этого сервера.
WH>ОС управляемая. Процессы запечатанные. SMTP не может запускать новые процессы.

SMTP — запускать процессы не может, он вообще протокол. А вот SMTP сервер может (это относится к подавляющему большенству распространненых SMTP серверов).

WH>И что и куда подгрузил червь?
В первом запросе свою небольшую часть. А после передачи ей управления подгрузил остальную. Они все так делают.

D>>Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте.
WH>И как защитится от исправления идреса возврата в стеке? Код не выполняется вот только легче от этого не становится.
D>>Но эту возможность порой используют вполне нормальные программы
WH>За это авторов нужно от программирования отлучать. Навсегда.

Этой возможностью пользуются все современные оптимизирующие компиляторы во время "агресивной оптимизации".

WolfHound wrote:
> C>А вот у меня вообще нет (не было и не будет) никаких резидентных
> антивирусов. Так как это мастдай.
> Это уже религия пошла.
Думаешь я скажу, что у меня Линукс?

> C>CAS означает ограничение доступа по определенным путям в коде. Например,
> C>текстовый редактор может иметь полный доступ ко всем файлам (с учетом
> C>прав, естественно), но получать новые handle'ы может только через диалог
> C>открытия файлов.
> Либо хендлы только через диалог открытия файла либо выделеное.
С чего бы? Скажем, в микроядерных ОС это делается элементарно — просто
ставится фильтр на сообщения в сервер файловой системы так, чтобы
сообщения могли отсылаться только из сервера стандартных диалогов.

В монолитных ОС это уже сложнее, но все равно возможно.

> Делаем Code Access Security с *гранулярностью равной процессу*, и пусть
> оно себе переполняет что хочет.
Это означает, что фильтры в CAS работают с гранулярностью равной
процессу (а не потоку, например).