Проект Singularity: обзор
От: Михаил Купаев (перевод) Россия www.rsdn.ru
Дата: 02.03.06 15:34
Оценка: 711 (20) +1 :)
Статья:
Проект Singularity: обзор
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


Авторы:
Михаил Купаев (перевод)

Аннотация:
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?
Re[2]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 06.06.06 06:53
Оценка: 15 (3) +1 -1
MS>

MS>...а остальная часть системы, исполняемая в SIP, состоит только из проверяемого безопасного (verifiably safe) кода, включая все драйверы устройств, системные процессы и приложения.


MS>Чисто из любопытства. Драйверы устройств, если это не банальный USB, требуют плотного взаимодействия с аппаратурой, что является небезопасным по определению. Например, с видеокартой можно такого наворотить, что наступит полный систем-кирдык. Так или иначе, прямой доступ к железу обеспечить необходимо. А что тогда мешает видеодрайверу залезть в хард-драйв и все порушить? В чем же заключается безопасность и проверяемость драйверов?


Поддерживаю. Вообще, после прочитанного, остается ощущение, что, собственно, никакой безопасностью тут и не пахнет. Переложить на компилятор + верифайер все — нереально (опять же, что мешает ровно так же анализировать и неуправляемый код, а? Что, верифаер будет сильно сложнее? Отнюдь.) И. Дырки все равно будут — из-за ошибок в компиляторе, верифайере и т.п. Но вот только последствия от пользования такой дырой, когда атакующему коду будет доступно сразу вообще ВСЕ, довольно плачевны. В общем, возникает очень много вопросов, а кроме того, мнение, что все это — просто реклама C# и управляемого кода. В общем, мое мнение — люди, писавшие это, либо не очень представляют проблемы безопасности и методы их решений, либо намеренно умалчивают об этом. Я не являюсь специалистом в разработке систем, отнюдь, и наверняка не вижу всех проблем с безопасностью в предлагаемом решении. Но у меня стойкое ощущение, что они есть (поэтому, собственно, и нет исследований по безопасности предлагаемого подхода).
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[3]: Проект Singularity: обзор
От: mrozov  
Дата: 10.06.06 20:56
Оценка: 6 (1) +2
Здравствуйте, Andrew S, Вы писали:

AS> что мешает ровно так же анализировать и неуправляемый код, а? Что, верифаер будет сильно сложнее? Отнюдь.)

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

AS>И. Дырки все равно будут — из-за ошибок в компиляторе, верифайере и т.п. Но вот только последствия от пользования такой дырой, когда атакующему коду будет доступно сразу вообще ВСЕ, довольно плачевны.


Я предпочитаю иметь дело с конечным числом ошибок в виртуальной машине или верификаторе, чем с бесконечным потоком ошибок в драйверах и службах. По-моему — самоочевидно.

AS>Я не являюсь специалистом в разработке систем, отнюдь, и наверняка не вижу всех проблем с безопасностью в предлагаемом решении.

Да оно в общем-то и так ясно. Но у меня есть смутное подозрение, что эти товарищи как раз специалистами и являются. Может им в чем-то таки виднее? Пускай даже и не во всем
Re[14]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 18:07
Оценка: 9 (2)
AS>>>>Назови примеры успешных управляемых сред, используемых достаточно широко?
WH>>>.NET, Java. Достаточно? На этих технологиях наколбасили кода я так думаю побольше чем на С++. При том что С++ намного старше.
AS>>В данном случае мы говорим про операционные системы, а не меряем пенисы в виде количества кода С++ и Джава. Давай не отклоняться от темы, ок?
WH>Вобщето ты начал про успешние управляемые среды...

Вот твоя цитата

Гранулярность защиты в x86'ой архитектуре очень низкая. Также она очень низкая и во всех других системах о которых я читал. Именно по этому я не верю в чисто аппаратное решение. В тоже время защита в управляемой системе работает хоть с точностью до бита. Причем статический анализ подавляющие большинство этих проверок способен убрать.


Еще раз. Я прощу тебя привести пример успешных ОС, построенных на управляемых средах, то, что имеет свойство называться управляемые системы. По крайней мере, я понял тебя именно так, думаю, все, кто это прочитает, поймут так же.

AS>>Ровно как и для неуправляемого кода. Пример уже приводили.

WH>Где?

Driver Verifier tools. Но похоже ты все, что говорят по этой теме, просто пропускаешь

AS>>Подписывать их будет компилятор, который сгенерил данный бинарник. Ведь никто не отменяет _текущие_ ограничения, это лишь вспомогательная информация.

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

Пусть подписывает. На этот код в любом случае будет накладываться все то же ограничение, что и сейчас. Дополнительная информация нужна для определения "безопасности" нативного кода и решения, можно ли его загружать в текущем контектсе. Загрузка на исполнение — ничего страшного не случится. А вот если убитый IL загрузить в сингулярити — будет большой бабах. Ага?

AS>>И что? Ровно так же драйвер в NT общается с HAL — просто вызовы функций. О чем это говорит? А ни о чем. Хотя, нет. NT хал будет как минимум не медленнее (а с учетом оптимизации — наверняка быстрее).

WH>У тебя какоето сильно предвзятое мнение. Кто мешает сделать все теже оптимизации компилятору IL'а?

Дополнительный лейер в виде IL. Если ты сможешь в IL задавать различные опции, влияющие на генерацию нативного кода, то ты потеряешь переносимость, да и смысл самого IL. Ну как мне еще это объяснить кроме как попросить тебя почитать про внутреннее устройство той же вин2к? Посмотри, как там это сделано, сколько оптимизировано просто _руками_. Прочитай, например, про префетч у Свена Шрайбера.

AS>>Разделяемая заблокированная память, секции. IOCTL (аж 2 разных типа) + MDL. В общем, способов получить _максимальное_ быстродействие взаимодействия с пользователем много. Единственно — большое время смена контекста, о чем все давно пинают m$. Но это может и _должно_ решаться аппаратно — я не могу понять, _почему_ процессоры содержат аппаратную поддержку тасков, но при это в целях повышения производительности используется программный вариант. Нонсенс? А ведь должно быть наоборот и пинать нужно производителей процессоров за подобное хамство. Ты посмотри, просто для интереса, какие извращения приходится делать, чтобы обеспечить приемлемую производительность на х86... Это проблемы аппаратные, а не программные, и почему их не решают — право, я не знаю. Наверняка, были регрессивные тесты, по которым было понятно где узкое место и наверняка переключения контекстов и потоков это не то, где надо искать производительность.

WH>Я вобщем не спорю с тем что x86 уродливый монстр. А менять архитектуру на право и на лево не дает какраз привязка всего софта к этому самому x86.
WH>Я вот попробовал поставить WinXP64 так полдовина софта не встало.

Если новая система будет поддерживать виртуализацию — это не проблема. Поставь на xp64 wmware и наслаждайся старыми приложениями почти с той же производительностью. А если поддержка виртуализации будет аппаратной? Ведь то, как это сделано сейчас — просто магия. Я для интереса пробовал разобраться — там СТОЛЬКО всего...

AS>>Опять же, сравни приведенную статистику памяти. Надеюсь, ты не будешь спорить с тем, что чем меньше воркинг сет для процесса, тем быстрее и манаджер памяти, и сам исполняемый код, который лучше помещаяется в T-кеш?

WH>Гм... меньше получилось только у FreeBSD. Болие того большую часть памяти которую сожрал процесс можно спокойно расшарить между разными процессами.
WH>Кстати они сами сказали что не гонялись за производительностью. Так что там скорей всего можно еще будь здоров как все разогнать.

В Singularity код компонуется с полной runtime-системой (включая GC), и размер замеряется после Bartok-оптимизации, удаляющей неиспользуемый код и данные.


А вот про то, каким образом под виндой они замеряли? Я полагаю, что это воркинг сет (который вообще не отражает статистику использования памяти). Если это так, тогда все эти замеры — БРЕД, ничего не имеющий общего с действительностью.
Сейчас я это покажу.
Итак. VC6, статическая линковка, все опции по умолчанию, релиз. Система вин2к, не загружена, все по умолчанию (аналогичные результаты в винхр на виртуальной машине):
// hw.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
int main(int argc, char* argv[])
{
    printf("Hello World!\n");
    Sleep(10000);
    return 0;
}


В результате — рабочий сет — 604 кб, бинарник — 40 кб (ага, вот и то, что в статье получилось, верно?)
Делаем магические пассы:
// hw.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
int main(int argc, char* argv[])
{
    SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1);
    printf("Hello World!\n");
    Sleep(10000);
    return 0;
}

Рабочий сет — 176 кб, бинарник — 40кб. Аналогичный эффект дает _опция_ линкера /WS:AGGRESSIVE.

/WS:AGGRESSIVE

In Windows NT 4.0 and later, the loader recognizes this attribute and aggressively trims the working set of the process when the process is inactive. This has the same effect as using the following call throughout your application.

SetProcessWorkingSetSize(hThisProcess, -1, -1)

Т.е.,при подходе данных товарищей, можно вообще замолчать использование опции и потом удивляться результатам.
Кстати, добавляем линкеру /OPT:NOWIN98 (что и дОлжно делать всегда), получаем бинарник размером 32 кб с тем же рабочим сетом.

Заметь, и это с использованием crt. Но нифига, нас это не остановит. Мы же смотрим на систему, а не на язык. Их тулза позволяет удалять неиспользуемый код, наши средства разработки не такие умные, зато умные мы. Нафиг crt, меняем его на свой (аналогичный _уже готовый_ есть в ntdll.dll, но в данном случае мне просто лень):

#include "stdafx.h"
#include <windows.h>
#pragma comment(linker, "/Entry:MyMain /OPT:NOWIN98")

int printf(char *szText)
{
    DWORD dwWritten;
    return WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), szText, lstrlen(szText), &dwWritten, NULL);
}

int MyMain()
{
    SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1);
    printf("Hello World!\n");
    Sleep(10000);
    return 0;
}


Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело.

AS>>Это верно. Но. Разве мы не можем сделать мод компилятора, который скажет, что придет одно, а на самом деле отправит другое? И что тогда будет в этом случае? С учетом, что обмануть верифайер тоже будет, думаю, можно. Что тогда? Писать верифайер, почти такой же, как и для нативного кода? А смысл тогда?

WH>Мод компилятора сделать не возможно. Ибо компиляторы ЯВУ генерирую IL и метаинформацию, а машинный код генерирует компилятор вшитый в систему.
WH>Так вот если компилятор ЯВУ сгенерирует не верный IL то этот IL просто пошлют куда подальше.

Ты готов подписаться под этими словами? Один известный товарищ уже говорил, что перейти в ринг 0 под winnt невозможно без драйвера. Возможно, и способов уже известно несколько.

AS>>Заметь, я не говорю, что идея плоха или еще что (хотя я и считаю, что это слишком панковско, когда все в одном кольце + не верю в производительность IL кода как на основании объективных тестов и субъективных ощущений,

WH>Ну субъективные ощущения можно сразу послать куда подальше. А вот мои тесты говорят что IL с каждой версией .НЕТ работает все шустрей. Те дело лишь в развитии оптимизаторов.

Твои тесты настолько же субъективны, как и мои.

WH>Те ничто не мешает IL'у работать с тойже скоростью что и С++, а то и большей ибо доступны болие злые оптимизации из-за того что IL ограничен.


Ты готов под этим подписаться?

AS>>так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае.

WH>А именно? Только ты учти что эта система совсем не НТ.

Я уже про часть из них говорил.

AS>>Современные х86 — это очень тонкая штука. Тот же префетч позволяет повысить производительность в разы.). Я лишь говорю, что не все проблемы показаны, о некоторых вообще ничего не сказано, а приведенные тесты производительности никуда не годяться. Или ты считаешь, что приведенные результаты объективны? Извини, но тогда объясни мне,

WH>Скажем так я не думаю что они сильно искажены ибо если так то рано или позно будет скандал.

Значит, он уже есть. То, что они искажены, я вроде доказал, не так ли?

AS>>Разница по операциям в 8 раз — неслабо?

WH>Ты не забывай что там еще Web сервер не понятного происхождения под ногами путается.

И зачем тогда такую статистику приводить, а? Нет, я определенно чего то не понимаю в этой жизни.
AS>>А что насчет стека TCP. 48 МБит? Извини, но даже на моем дохлом PII-366 на winnt4 я насыщал 100 мегабитную сетку на 100% обычными сокетами. А с учетом того, что гигабитные скорости сейчас совсем не редкость, а данность, то что это — демонстрация скорости каналов? Производительность диского теста я даже прокомментировать не могу — кто-нибудь вообще понял, что там и как тестировалось? Вот я смотрю соответствующие тесты на ф-центре и там все понятно — даны паттеры и прочее, видно, что где и как. Главное, доступны исходные коды тестов (f-test) и паттерны. Что же тут такое, а? Объясни мне, а то спать спокойно не смогу
WH>А у меня ты чего спрашиваешь? Я чтоли эти тесты проводил.
Ты утверждаешь, что эти тесты валидны. Будь добр обосновывать свои утверждения. Иначе смысл разговора, согласись?
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[4]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 11.06.06 14:55
Оценка: +1 :)
AS>> что мешает ровно так же анализировать и неуправляемый код, а? Что, верифаер будет сильно сложнее? Отнюдь.)
M>Ага. Особенно ежели вспомнить о различиях в системах с указателями и без оных. Практически никакой разницы в верификаторах...

Отлично. Перечислите разницу, если user mode коду доступны лишь системные функции (я не говорю про кривую архитектуру х86 или виндовс. В целом — в чем отличие неуправляемого кода, исполняемого на нормальном процессоре, где нет проблем с lgdt и т.п. и управляемого, исполняемого на _ровно_ таком же, но на виртуальном, процессоре? Введением дополнительного уровня косвенности? И что?). Вперед, а мы покритикуем Ровно так же, как и при реализации системных функций в той же винде (посмотрите на callggate, как там проверяются параметры, чтобы понимать, о чем речь), используется _очень_ ограниченный набор системного апи, ответственного за проверку параметров.

AS>>И. Дырки все равно будут — из-за ошибок в компиляторе, верифайере и т.п. Но вот только последствия от пользования такой дырой, когда атакующему коду будет доступно сразу вообще ВСЕ, довольно плачевны.


M>Я предпочитаю иметь дело с конечным числом ошибок в виртуальной машине или верификаторе, чем с бесконечным потоком ошибок в драйверах и службах. По-моему — самоочевидно.


А по-моему — нет. Проблемы безопасности не заканчиваются на ограничении возможности исполнения кода. Напротив — они тут только начинаются. Число ошибок в любой реализации бесконечно. И решить _все_ проблемы исполняемого кода, пусть и на виртуальной машине, при помощи верифайера — нереально, на мой взгляд. Это NP-полная задача поиска в бесконечном (в общем то случае) пространстве состояний. Мы его можем искуственно ограничить (введением той самой виртуальной машины). Вопрос в том, _насколько_. Все дело как раз в том верифайере. Вот в статье _ничего_ про него не сказано, а он, на мой взгляд, самое главное в этом подходе. Сделать кривой драйвер или сервис возможно в любой системе, как бы мы ее не ограничивали. Всегда найдутся дятлы, которые смогут расширить даже самую маленькую дырочку. И тут важен баланс между безопасностью и производительностью. Переключение контекста — это просто _бредовый_ параметр, который на производительность влияет така же, как цены на участки грунта Луны.
И. Сделав подобный верифайер, можно _существенно_ снизить вероятность атаки и на неуправляемый код. Что мешает его сделать? А то, что сейчас политика сместилась на управляемый код.

AS>>Я не являюсь специалистом в разработке систем, отнюдь, и наверняка не вижу всех проблем с безопасностью в предлагаемом решении.

M>Да оно в общем-то и так ясно. Но у меня есть смутное подозрение, что эти товарищи как раз специалистами и являются. Может им в чем-то таки виднее? Пускай даже и не во всем

Тогда где нормальное тестирование безопасности? Думаю, было бы желание — они бы это показали, хотя бы на элементарном примере уязвимостей системных сервисов. Может, просто показывать нечего? Тогда это и есть — просто реклама.

PS Я не хочу тут устраивать религиозные споры. Но, на мой взгляд, кроме рекламы, в статье _ничего_ нет. Уж извините. Сам подход интересный, но то, что представлено — анюзабле.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[5]: Проект Singularity: обзор
От: WolfHound  
Дата: 12.06.06 21:03
Оценка: +2
Здравствуйте, Andrew S, Вы писали:

AS>Отлично. Перечислите разницу,

Покажи мне декомпилятор из бинраника в С++. Декомпилятор из IL в C# я могу показать легко... и не один... Это я к тому сколько информации доступно виртуальной машине и современным процессорам.

AS>А по-моему — нет. Проблемы безопасности не заканчиваются на ограничении возможности исполнения кода. Напротив — они тут только начинаются. Число ошибок в любой реализации бесконечно. И решить _все_ проблемы исполняемого кода, пусть и на виртуальной машине, при помощи верифайера — нереально, на мой взгляд.

Нам не нужно решить все проблемы. Нам нужно создать sandbox, а это не тоже самое что решить все проблемы.
AS>Это NP-полная задача поиска в бесконечном (в общем то случае) пространстве состояний. Мы его можем искуственно ограничить (введением той самой виртуальной машины). Вопрос в том, _насколько_. Все дело как раз в том верифайере.
Нам не нужно проверять все множество состояний. Достаточно гарантировать что ни при каких условиях не будет нарушения типизации, выхода за приделы массива или использован невалидный указатель. При наличии метаинформации и типизированного ассемблера это решается элементарными проверками.
Попробуй используя только safe код сделать что-то криминальное типа переполнения буфера на .НЕТ.

AS>И. Сделав подобный верифайер, можно _существенно_ снизить вероятность атаки и на неуправляемый код. Что мешает его сделать? А то, что сейчас политика сместилась на управляемый код.

Думаешь политика? Если да то попробуй...

AS>Тогда где нормальное тестирование безопасности? Думаю, было бы желание — они бы это показали, хотя бы на элементарном примере уязвимостей системных сервисов. Может, просто показывать нечего? Тогда это и есть — просто реклама.

На самом примитивном уровне там нет переполнения буфера. У меня нет статистики но что-то мне подсказывает что это основная дырка для программного взлома систем.
Единственный кто может напакостить это драйвер работающий с DMA

An IoPort provides an interface to a device’s I/O port registers. It verifies that register references are in bounds and a driver does not write to read-only memory. An IoDma provides access to the built-in DMA controller for legacy hardware. IoIrqs notify a driver when a hardware interrupt arrives. IoMemory provides a bounds checked access to a fixed region of memory containing memory-mapped registers or pinned for use in DMA.

The only unsafe aspect of the driver-device interface is DMA. Existing DMA architectures provide no memory protection, so a misbehaving or malicious driver can program a DMAcapable device to overwrite any part of memory. Because of the diversity of DMA interfaces, we have not found a good abstraction to encapsulating them. We anticipate that future hardware will provide memory protection for DMA transfers.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 13.06.06 22:48
Оценка: +1 -1
AS>>Любая видеокарта. Да, решается. Выходит очередная виндовс-виста, и все пользователи дружно покупают новое железо, где эта проблема решена аппаратно, например, введением аутентицированного доступа к регистрам управления. Потом 3 года пользователи ждут драйвера для новой железки, потом недоумевают, как это очередной квейк 10 при наличии графики а-ля дюк нюкем бегает примерно с такими же тормозами, как и оный на 486 dx4-100.
WH>Ну это явные передергивания и демагогия.
WH>К тому же я говорил не о железе, а о драйверах. Те когда контора выпускает новый драйвер для небезопасной железки она отправляет этот драйвер на сертификацию и если он ее проходит то этому драйверу выписывают цифровую подпись и система принимает только драйверы с такими подписями.

Только вот недавно написал инсталлятор, который это дело обходит на винхр. Использую _только_ разрешенные системные сервисы и средства. Что будет мне мешать сделать ровно то же и там? Думаю, риторически, верно?

AS>>Не такой уж и монстр. Но что уродец — это точно. Дык вот надо уродца править, вводить режима совместимости х86 в виде виртуализации (ведь внутри тот же к8 — это совсем не х86), а не изобретать очередной велосипед.

AS>>И. Под всем этим все равно будет х86, со всеми ляпсусами. И в любом случае, низкоуровневые драйвера будут вынуждены использовать ассемблер\С, например, для доступа к портам. Т.е. опять же организовывается некий HAL. Позвольте, товарищи, но ведь тот же самый HAL и сейчас уже есть на NT.
WH>От HAL никто никуда не денется. Вот только HAL HAL'у рознь.

Ну это явные передергивания и демагогия. (с)


AS>>И что? Аналогично сейчас и под NT — 99 процентов правильно написаных драйверов просто перекомпилируются под нужную платформу — все делается через HAL.

WH>Я говорил не только и не столько про драйверы... драйверы это вобще кот наплакал... я говорил про софт вобще.

Эээ, нет, дорогой. Основной упор сингулярити — это внутреняя безопасность, когда некорректно написанного драйвера быть просто не может (ура, все программисты наконец то станут писать идеальный код и наступит Великое Завтра).

AS>>Трудней будет найти первый вариант. А потом — все пойдет по уже обкатанной на вин32 схеме

WH>С тотальным CAS вирусам развернутся просто негде будет. Даже если юзер сидит под админом.



AS>>И что? Это повод переходить на управляемый код, и терять в производительности? Сомнительно... Тем более что нормальных тестов производительности\безопасности так и не приведено

WH>Потери производительности? Это только от качества оптимизатора зависит, а они постоянно совершенствуются.

Введение любого промежуточного представления (того же IL) — это потери. Если ты посмотришь, сколько времени в процентном соотношении занимают системные вызовы в среднестатистическом сервере, ты поймешь, что это, собственно, не камень преткновения на вин нт (там фактически доли процента получаются). Ты можешь гарантировать, что оптимизатор с довольно ограниченного IL сможет обеспечить нормальный код? Я бы не стал на это ставить больше одной копейки

AS>>Системные сервисы — имеются в виду функции, предоставляемые ядром — натив апи и другие, те же вин32. User mode коду на самом деле доступно _очень_ мало даже сейчас, и отрубить ему вообще все варианты нагадить — очень просто. Вот только и даже более. Основная проблема сейчас, не внутренняя, а внешняя безопасность. А даже не ошибки, вызванные багами системных сервисов\приложения, а ... пользователи, работающие под администратором. Всегда. Т.е. установить драйвер и запустить его — относительно просто. Аналогичная ситуация будет и под любой другой системой — это проблема мышления пользователей, которые по 1,3.14здяйски (сорри, но другого термина просто тут не подобрать) относятся к секурити, а не безопасности системы...

WH>Вот именно по тому что пользователи сидят под админом и нужен тотальный CAS.

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

AS>>Подумай сам, ведь для реализации ремотинга (ведь надо же как то организовывать взаимодействие) все равно придется разрешать исполнение удаленного кода. И как только это будет позволено — все, внешней безопасности больше нет, как сейчас произошло с RPС на виндах...

WH>Ответ не верный. Если у внешнего кода будут права только на то чтобы что-то сделать с потоком байт то никуда вломится он не сможет ибо CAS.

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

AS>>Но ведь для этого не обязательно пользоваться IL. Достаточно написать качественные фреймворки для разработки и тестирования. Почему бы не тратить силы и время на это, а не на написание абстрактной ОС?

WH>Попыток было много. И всем им далеко до успехов управляемых сред.

Назови примеры успешных управляемых сред, используемых достаточно широко?

AS>>Что то мне это ситуация Оберон больно напоминает. Теоретически все хорошо, а вот практически С++, созданный практиками и промышленностью, фактически убил все паскалеподобные языки.

WH>Теоритически ни Оберон ни Оберон ОС ничего не стоят. Оберон примитивнеший язык с совершенно дурацким синтаксисом. Оберон ОС однопользовательские, без CAS, без изоляции процессов, с одним мусорщиком на всех...

Заметь, это не я сказал.

AS>>Это должно делаться на программно-_аппаратном уровне_ — см. виртуализацию.

WH>А по мне это должно решаться на уровне VM. Те просто выкидываем x86'ой камень и ставим какуюнибудь альфу.
AS>>Сейчас ее сделать очень муторно, это связано с убогостью х86. Но даже мелкие правки _значительно_ повысят производительность виртуальных машин. А что это значит — ну ты и сам понимаешь. Попробуй убить хост систему из-под вмваре? Вот и сандбокс для начальной проверки приложений\драйверов.
WH>Начальной проверки абсолютно не достаточно. Проверка должна быть постоянной.

Ответ не верный. Постоянная проверка — гарантия тормозов.

AS>> Нет. Исходники, преобразованные в нужный вид, пригодный для анализа — этакий псевдокод, но отображающийся на нативный. Не IL. Как я уже говорил, большинство драйверов\приложений, написанных правильно, являются платформенно-независимыми в рамках NT.

WH>Угу... а как ты будешь защищаться от рассинхронизации этого псевдокода и машинного кода?

Введением подписи. Уж синхронизировать их (а тем более в одном бинарнике) проблемы не будет, а?

AS>>Например, какие системы имеются в виду? Например, если вспомнить вин нт 3.5, там многие драйвера были user-mode. В NT4 от этого отказались. Почему? Правильно — из-за низкой производительности. Причина — большое время вызова системных сервисов. Решение — тот же SYSCALL, но в нормальном вариант. Все-таки 200 тактов для callgate — это слишком.

WH>Я имел в виду аппаратные решения по защите памяти с точностью до страници памяти и с контролем кто куда пишет.

Например? Конкретные платформы. А то как то получается беспредметно.

AS>>Почему ты считаешь, что тот же user mode драйвер (а это именно то, что предлагает сингулярити), но только еще более ограниченный в способах взаимодействия с аппаратурой, будет способен обеспечить хоть сколько приемлемую производительность той же видеоподсистемы?


WH>А в чем проблема? В сингулярити все в одном кольце.

WH>Если ты про контроль того куда можно писать, а куда нет то это пара тактов даже если оптимизатор не сможет устранить проверку что вряд ли.

Ты действительно так думаешь? Ну... мне тогда нечего сказать. Ну во-первых, тут ты видишь, что вводится парадигма обмена по каналам.

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

Это сильно! В отдельных процессах. Даже если учесть, что процессы тут очень легкие, все равно. Иы хоть представляешь, какова производительность этого? Пусть даже драйвер как trustee общается c hal при помощи прямых вызовов. Но это все фигня — основное назначение драйвера обеспечивать интерфейс вовне. Представь себе производительность обмена по каналам в случае gdi драйвера, тем более тот исполняет в контексте отдельного процесса, а значит, каждый обмен — это шедулинг? Просто в качестве интереса — есть практический опыт написания драйверов? У меня небольшой есть — и даже тут уже приходится задумываться о том, как лучше организовать взаимодействие с user. И это при том, что в моем распоряжении все же не каналы, а гораздо более мощные и быстродействующие механизмы...

А во-вторых. Сколько ты думаешь времени занимает контроль правильности параметров при системном вызове виннт? С учетом, что вызов занимает около 500-2000 тактов (в зависимости от системы), а смена контекста user\kernel — 100-200 (тоже в зависимости от системы).
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[20]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 21:44
Оценка: +1 -1
WH>Кстати в сингулярити можно делать любые ГЦ в том числе и полное отсутствие ГД для какого либо процесса в случае если память можно распределить один раз и навсегда.
AS>>Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем...
WH>В сингулярити компиляция происходит во время установки программы. Дальше ОС поднимает уже скомпилированный код.

И опять таки упремся в проблему надежности компилятора в IL, верифайера и компилятора из IL в нативный код. Я так понял, что гарантировать достоверность результатов работы такой связки ты таки не сможешь, и что все-же возможны варианты обмана верифайера, при котором компилятор из IL в нативный код понаделает такой гадости, что сам застрелится? Если это так, тогда все "красивые" логические построения будут смыты в dev\null простой модификацией компилятора в IL. Отмазки типа "сейчас этого нет, и может быть это вообще не откомпилится", думается, в системе, где других способов защиты нет, не прокатят... Ведь сейчас просто незачем этим народу заниматься, а если будет такой лакомый кусок в виде верифайера, думаю, его быстро разломают... Ведь если математически доказать корректность не представляется возможным, то и все возможные состояния проверить тоже не удастся. В общем, очень много вопросов. И в статье, согласись, они вообще не освещены никак. И заметь, мы с тобой (по крайней мере я, поскольку не являюсь специалистом по .net), вообще говоря, не представляем всех возможных проблем надежности такого подхода. Наверняка найдутся люди, которые накидают совершенно других соображений, нежели смог придумать я, базируясь уже на конкретных знаниях технологий компиляции в\из IL, а также самого IL.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[4]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 10.06.06 23:19
Оценка: +1
Здравствуйте, mrozov, Вы писали:

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


В любом случае всё сводится к проверке валидности параметров передаваемых в системные функции. Так что как раз никакой разницы.

M>Я предпочитаю иметь дело с конечным числом ошибок в виртуальной машине или верификаторе, чем с бесконечным потоком ошибок в драйверах и службах. По-моему — самоочевидно.


Что-за пропаганда?

M>Да оно в общем-то и так ясно. Но у меня есть смутное подозрение, что эти товарищи как раз специалистами и являются. Может им в чем-то таки виднее? Пускай даже и не во всем


Да тут как сказать. У MS маркетинг на уровне. Почему бы и не создать ещё одну ОС, ради рекламы, а?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.06.06 21:30
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Покажи мне декомпилятор из бинраника в С++. Декомпилятор из IL в C# я могу показать легко... и не один... Это я к тому сколько информации доступно виртуальной машине и современным процессорам.


Это скорее говорит о степени оптимизации, чем о наличии информации.

WH>Нам не нужно решить все проблемы. Нам нужно создать sandbox, а это не тоже самое что решить все проблемы.


А разве его уже нет? Я что-то не помню чтобы какая-либо user-mode программа порушила мою XP. Правда иногда так зависнет, что перезагрузить быстрее, но, подчёркиваю, это не необходимость. Вся проблема в драйверах, а тут безопасность тибо hardware-supported, либо работают маркетологи.

WH>При наличии метаинформации и типизированного ассемблера это решается элементарными проверками.


На мифическом процессоре Intel Pentium Zju Secure Edition.
В рамках user-mode мы можем создать что угодно. Да хотя бы VMWare, это вообще sandbox дальше некуда. И что-то я там managed вещей не припомню. А вот в ядре уже ничего не спасает.

WH>Попробуй используя только safe код сделать что-то криминальное типа переполнения буфера на .НЕТ.


Попробуй, используя только safe код написать видеодрайвер

AS>>И. Сделав подобный верифайер, можно _существенно_ снизить вероятность атаки и на неуправляемый код. Что мешает его сделать? А то, что сейчас политика сместилась на управляемый код.

WH>Думаешь политика? Если да то попробуй...

Вообще-то в Vista будет Address Layout Randomization, так что акценты никуда не сместились.

WH>На самом примитивном уровне там нет переполнения буфера. У меня нет статистики но что-то мне подсказывает что это основная дырка для программного взлома систем.


Как это так — буфер есть, а переполнения нет? Если посылать заведомо некорректные данные, на которые программа не расчитана, то она упадёт. И, собственно, какая к чёрту разница она просто упадёт или удастстя записать код в стек? Ведь DoS атака уже удалась. Вот, например, если в форумах РСДН тема топика слишком длиная, то в ответе, после добавления 'Re:', конец будет обрезан. Чем не переполнение и, как следствие, порча данных? Ну и как, помог тебе .Net фреймворк?

WH>Единственный кто может напакостить это драйвер работающий с DMA


Да вообще-то практически любой драйвер, если ты, конечно, не хочешь чтобы сетевая карта жрала 30% процессорного времени, а на GeForce 5200 можно было играть только во второй Quake.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 12.06.06 21:44
Оценка: +1
AS>>Отлично. Перечислите разницу,
WH>Покажи мне декомпилятор из бинраника в С++. Декомпилятор из IL в C# я могу показать легко... и не один... Это я к тому сколько информации доступно виртуальной машине и современным процессорам.

IDA. Ну и плюсом — что мешает включать нужную для подобной декомпиляции информацию в бинарники (хотя бы тех же драйверов)? Еще раз IL — это не панацея.

AS>>А по-моему — нет. Проблемы безопасности не заканчиваются на ограничении возможности исполнения кода. Напротив — они тут только начинаются. Число ошибок в любой реализации бесконечно. И решить _все_ проблемы исполняемого кода, пусть и на виртуальной машине, при помощи верифайера — нереально, на мой взгляд.

WH>Нам не нужно решить все проблемы. Нам нужно создать sandbox, а это не тоже самое что решить все проблемы.
AS>>Это NP-полная задача поиска в бесконечном (в общем то случае) пространстве состояний. Мы его можем искуственно ограничить (введением той самой виртуальной машины). Вопрос в том, _насколько_. Все дело как раз в том верифайере.
WH>Нам не нужно проверять все множество состояний. Достаточно гарантировать что ни при каких условиях не будет нарушения типизации, выхода за приделы массива или использован невалидный указатель. При наличии метаинформации и типизированного ассемблера это решается элементарными проверками.
WH>Попробуй используя только safe код сделать что-то криминальное типа переполнения буфера на .НЕТ.

Из драйвера? Элементарно. Пример уже приводили сами авторы — перепрограммировать любое устройство, которое может мапить память на адресное пространство PCI шины. И. где гарантия, что реализация JIT компилятора для IL, вериафайера и сандбокса будет идеальна и свободна от ошибок? Если уж они в железе есть (а ведь там архитектура проверяется годами), то и тут их не избежать. И дырки _будут_ находиться. Сейчас их "нет", поскольку никому не надо. Вспомни, вирусы под win32 тоже не сразу появились — понадобилось пару лет — и ва ля. Спрос породит предложение.

AS>>И. Сделав подобный верифайер, можно _существенно_ снизить вероятность атаки и на неуправляемый код. Что мешает его сделать? А то, что сейчас политика сместилась на управляемый код.

WH>Думаешь политика? Если да то попробуй...

Про верифайер для драйверов уже написали. Почему бы подобное не сделать для системных сервисов?

AS>>Тогда где нормальное тестирование безопасности? Думаю, было бы желание — они бы это показали, хотя бы на элементарном примере уязвимостей системных сервисов. Может, просто показывать нечего? Тогда это и есть — просто реклама.

WH>На самом примитивном уровне там нет переполнения буфера. У меня нет статистики но что-то мне подсказывает что это основная дырка для программного взлома систем.

Супер. Это пять. Мы говорим про безопасность приложений (то бишь гарантию того, что неправильно написаный драйвер не вынесет всю систему) или про внешнюю безопасность? Это как бы ортогональные вещи. Внутреняя безопасность — это проблемы драйверов и системных сервисов. Существующие проблемы внешней безопасности вызваны как банальными ошибками программирования (те же переполнения буфера), так и ошибками в архитектуре (например, DCOM на windows 9х). Проблемы же внутренней безопасности решаются написанием адекватного фреймворка для тестирования и разработки драйверов, которого вот уже как больше 10 лет нет (сколько там процентов падений системы вызвано ошибками в драйверах? 80 или больше, я уже не помню — но цифирь была). До сих пор написание драйвера — это пыточный процесс, включающий в себя поиск документации, разбор недокументированных функций и т.п. Ведь просто _нормальный_ фреймворк повысил бы стабильность драйверов на порядки. Но его нет. И не будет, судя по всему.

WH>Единственный кто может напакостить это драйвер работающий с DMA

WH>

WH>An IoPort provides an interface to a device’s I/O port registers. It verifies that register references are in bounds and a driver does not write to read-only memory. An IoDma provides access to the built-in DMA controller for legacy hardware. IoIrqs notify a driver when a hardware interrupt arrives. IoMemory provides a bounds checked access to a fixed region of memory containing memory-mapped registers or pinned for use in DMA.

WH>The only unsafe aspect of the driver-device interface is DMA. Existing DMA architectures provide no memory protection, so a misbehaving or malicious driver can program a DMAcapable device to overwrite any part of memory. Because of the diversity of DMA interfaces, we have not found a good abstraction to encapsulating them. We anticipate that future hardware will provide memory protection for DMA transfers.

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

Предлагаю подумать над следующим:
1. Почему бы не разработать нормальный вариант расширения х86 (нет, не убогий SYSCALL), который бы позволил аппаратно кешировать состояния потоков. В этом случае вызовы системных сервисов и переключения контекста занимали _значительно_ меньшее время. (А ведь это единственный видимый плюс, показаный на тестах из статьи)
2. Почему бы не поправить некоторые ошибки х386 — те же непривелигерованные привелегированные команды и прочее?
3. Зачем вводить лишнюю прослойку из IL, когда при желании компилятор может предоставить всю нужную информацию для анализа неуправляемого кода?

Ответ на эти вопросы у меня один и я уже его декларировал. Возможно, я и не прав, но ощущения у меня именно такие.

В общем, повторюсь, все, что было приведено — не аргументация и тем более не серьезный анализ безопасности предлагаемого решения (как на уровне защиты от непреднамеренных ошибок, так и от преднамеренных). Я на звание специалиста в данной области не претендую, и все, кто тут высказывался, по-видимому, тоже (по крайней мере, я адекватных аргументов не увидел). Все сводится к тому, что "IL это безопасно, потому что безопасно и типизированно, .нет — это хорошо и прогрессивно". По мне — это плохая аргументация. Ровно так же много лет назад говорили про защищенный режим 386. К чему это привело сейчас — знают все.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[8]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 13.06.06 21:28
Оценка: +1
AS>>IDA.
WH>Я его давно не видел. А что он уже научился декомпилировать в С++ и буква A в этой аббревиатуре лишь дань бренду?
AS>>Ну и плюсом — что мешает включать нужную для подобной декомпиляции информацию в бинарники (хотя бы тех же драйверов)?
WH>Те рядом положить IL или что-то подобное?
AS>>Еще раз IL — это не панацея.
WH>А кто говорит про панацею? Это просто шаг вперед.

Ой ли? А не попытка ли это замаскировать проталкивание своей идеологии? Для каждой парадигмы есть свои ниши. И мое _глубокое_ убеждение, что в высокопроизводительных решениях управляемому коду (а уж тем более с GC) делать просто нечего. Может, я и ошибаюсь, но это _мое_ мнение.

AS>>Из драйвера? Элементарно. Пример уже приводили сами авторы — перепрограммировать любое устройство, которое может мапить память на адресное пространство PCI шины.

WH>И много таких устройств? Может это просто решается сертификацией драйверов для подобных устройств?

Любая видеокарта. Да, решается. Выходит очередная виндовс-виста, и все пользователи дружно покупают новое железо, где эта проблема решена аппаратно, например, введением аутентицированного доступа к регистрам управления. Потом 3 года пользователи ждут драйвера для новой железки, потом недоумевают, как это очередной квейк 10 при наличии графики а-ля дюк нюкем бегает примерно с такими же тормозами, как и оный на 486 dx4-100.

AS>>И. где гарантия, что реализация JIT компилятора для IL, вериафайера и сандбокса будет идеальна и свободна от ошибок?

WH>Это относительно небольшой объем кода. И весь этот код контролируется одной конторой. Его можно просто математически доказать.
AS>>Если уж они в железе есть (а ведь там архитектура проверяется годами), то и тут их не избежать.
WH>Железо постоянно модифицируется. К тому же сейчас x86 это просто монстр какойто... мне вобще не понятно как до сих пор эта архитектура находится на плаву.

Не такой уж и монстр. Но что уродец — это точно. Дык вот надо уродца править, вводить режима совместимости х86 в виде виртуализации (ведь внутри тот же к8 — это совсем не х86), а не изобретать очередной велосипед.
И. Под всем этим все равно будет х86, со всеми ляпсусами. И в любом случае, низкоуровневые драйвера будут вынуждены использовать ассемблер\С, например, для доступа к портам. Т.е. опять же организовывается некий HAL. Позвольте, товарищи, но ведь тот же самый HAL и сейчас уже есть на NT.

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


И что? Аналогично сейчас и под NT — 99 процентов правильно написаных драйверов просто перекомпилируются под нужную платформу — все делается через HAL.

AS>>И дырки _будут_ находиться. Сейчас их "нет", поскольку никому не надо. Вспомни, вирусы под win32 тоже не сразу появились — понадобилось пару лет — и ва ля. Спрос породит предложение.

WH>Вирусы ходят через переполнение буфера и отсутствие CAS.
WH>Я не говорю что под управляемой ОС вирусов не будет вобще но то что их будет делать намного трудней это определенно.

Трудней будет найти первый вариант. А потом — все пойдет по уже обкатанной на вин32 схеме

AS>>Про верифайер для драйверов уже написали.

WH>А что они там такого написали? Что именно проверяется? Корректность работы с железкой? Так верифаер управляемого кода справится с этим по крайней мере не хуже.

И что? Это повод переходить на управляемый код, и терять в производительности? Сомнительно... Тем более что нормальных тестов производительности\безопасности так и не приведено

AS>>Почему бы подобное не сделать для системных сервисов?

WH>А системные сервисы вобще творят что-попало. Их вобще озвереешь врефифицировать. И управляемый код вместе с вездисущим CAS тут будет как нельзя кстати.

Системные сервисы — имеются в виду функции, предоставляемые ядром — натив апи и другие, те же вин32. User mode коду на самом деле доступно _очень_ мало даже сейчас, и отрубить ему вообще все варианты нагадить — очень просто. Вот только и даже более. Основная проблема сейчас, не внутренняя, а внешняя безопасность. А даже не ошибки, вызванные багами системных сервисов\приложения, а ... пользователи, работающие под администратором. Всегда. Т.е. установить драйвер и запустить его — относительно просто. Аналогичная ситуация будет и под любой другой системой — это проблема мышления пользователей, которые по 1,3.14здяйски (сорри, но другого термина просто тут не подобрать) относятся к секурити, а не безопасности системы...
Подумай сам, ведь для реализации ремотинга (ведь надо же как то организовывать взаимодействие) все равно придется разрешать исполнение удаленного кода. И как только это будет позволено — все, внешней безопасности больше нет, как сейчас произошло с RPС на виндах...

AS>> Супер. Это пять. Мы говорим про безопасность приложений (то бишь гарантию того, что неправильно написаный драйвер не вынесет всю систему) или про внешнюю безопасность? Это как бы ортогональные вещи. Внутреняя безопасность — это проблемы драйверов и системных сервисов.

WH>Те проблемы пользователей...
AS>>Существующие проблемы внешней безопасности вызваны как банальными ошибками программирования (те же переполнения буфера), так и ошибками в архитектуре (например, DCOM на windows 9х).
WH>Вот я предлагаю избавится хотябы от ошибок программирование по максимому.

Но ведь для этого не обязательно пользоваться IL. Достаточно написать качественные фреймворки для разработки и тестирования. Почему бы не тратить силы и время на это, а не на написание абстрактной ОС? Что то мне это ситуация Оберон больно напоминает. Теоретически все хорошо, а вот практически С++, созданный практиками и промышленностью, фактически убил все паскалеподобные языки.

AS>>Проблемы же внутренней безопасности решаются написанием адекватного фреймворка для тестирования и разработки драйверов, которого вот уже как больше 10 лет нет (сколько там процентов падений системы вызвано ошибками в драйверах? 80 или больше, я уже не помню — но цифирь была). До сих пор написание драйвера — это пыточный процесс, включающий в себя поиск документации, разбор недокументированных функций и т.п. Ведь просто _нормальный_ фреймворк повысил бы стабильность драйверов на порядки. Но его нет. И не будет, судя по всему.

WH>Вот управляемые ОС это и есть путь к такому фреймворку. Причем значительно болие нормальному чем можно будет добится под виндой.

Очень сильное высказывание. Я вот так бы не утверждал — там все совсем не однозначно. Повторюсь, юзер моде драйвера (а таковых _очень_ много — это драйвера сканеров, принтеров и т.п.) ввобще не способны даже при желании вынести систему. А то, что предлагает сингулярити — фактически аналог этих самых юзер моде драйверов со значительно ускоренным взаимодействием ввиду отсутствия переключения контекстов. Что мешает это сделать аппаратно и использовать уже в текущих неуправляемых системах? А ничего, на самом деле. Было бы желание... А ведь тогда _очень_ много драйверов можно будет реализовать в виде mini-user mode драйверов, и сильно выиграть и на их стоимости, и на стабильности.

AS>>1. Почему бы не разработать нормальный вариант расширения х86 (нет, не убогий SYSCALL), который бы позволил аппаратно кешировать состояния потоков. В этом случае вызовы системных сервисов и переключения контекста занимали _значительно_ меньшее время. (А ведь это единственный видимый плюс, показаный на тестах из статьи)

WH>Угу... еше одно расширение x86... как ты думешь систему можно расширять бесконечно сохраняя обратную совместимость?

Это должно делаться на программно-_аппаратном уровне_ — см. виртуализацию. Сейчас ее сделать очень муторно, это связано с убогостью х86. Но даже мелкие правки _значительно_ повысят производительность виртуальных машин. А что это значит — ну ты и сам понимаешь. Попробуй убить хост систему из-под вмваре? Вот и сандбокс для начальной проверки приложений\драйверов.

AS>>2. Почему бы не поправить некоторые ошибки х386 — те же непривелигерованные привелегированные команды и прочее?

WH>Править ошибки в железе? Те забить на совместимость?

См выше.

AS>>3. Зачем вводить лишнюю прослойку из IL, когда при желании компилятор может предоставить всю нужную информацию для анализа неуправляемого кода?

WH>Те рядом положить IL? И отказаться от межпроцессорной переносимости?

Нет. Исходники, преобразованные в нужный вид, пригодный для анализа — этакий псевдокод, но отображающийся на нативный. Не IL. Как я уже говорил, большинство драйверов\приложений, написанных правильно, являются платформенно-независимыми в рамках NT.

AS>>В общем, повторюсь, все, что было приведено — не аргументация и тем более не серьезный анализ безопасности предлагаемого решения (как на уровне защиты от непреднамеренных ошибок, так и от преднамеренных). Я на звание специалиста в данной области не претендую, и все, кто тут высказывался, по-видимому, тоже (по крайней мере, я адекватных аргументов не увидел). Все сводится к тому, что "IL это безопасно, потому что безопасно и типизированно, .нет — это хорошо и прогрессивно". По мне — это плохая аргументация. Ровно так же много лет назад говорили про защищенный режим 386. К чему это привело сейчас — знают все.


WH>Гранулярность защиты в x86'ой архитектуре очень низкая. Также она очень низкая и во всех других системах о которых я читал. Именно по этому я не верю в чисто аппаратное решение. В тоже время защита в управляемой системе работает хоть с точностью до бита. Причем статический анализ подавляющие большинство этих проверок способен убрать.


Например, какие системы имеются в виду? Например, если вспомнить вин нт 3.5, там многие драйвера были user-mode. В NT4 от этого отказались. Почему? Правильно — из-за низкой производительности. Причина — большое время вызова системных сервисов. Решение — тот же SYSCALL, но в нормальном вариант. Все-таки 200 тактов для callgate — это слишком.
Почему ты считаешь, что тот же user mode драйвер (а это именно то, что предлагает сингулярити), но только еще более ограниченный в способах взаимодействия с аппаратурой, будет способен обеспечить хоть сколько приемлемую производительность той же видеоподсистемы?
На мой взгляд, вариантов нет — либо производительность, либо безопасность (лучше называть это другим термином — устойчивость.). А сравнивать производительность драйверов IDE — ну некорректно это, некорректно. Пусть сравнивают видеодрайвера — вот тут мы сможем реально посмотреть, оправдывает ли себя такой подход. Графика всегда была наиболее требовательна к качеству программного интерфейса. Рассуждать можно очень красиво, а вот практика очень часто разбивает такие теоретические построения в прах. Итого — пока не будет _адекватных_ тестов производительности (а не того, что там приведено сейчас) и безопасности\устойчивости, говорить о чем-либо вообще бессмысленно. Если ты не интересовался, на какие ухищрения идут kernel-программисты, дабы обеспечить приемлемую производительность NT, очень рекомендую. Например (из того, что могу прямо сейчас вспомнить), сдвиг наиболее часто используемых функций в начало секции, чтобы обеспечить меньшую сегментацию виртуальной памяти и лучший пайплайнинг. Можно ли это все будет учитывать с использованием IL? _Очень_ сомнительно...
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[9]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 22:18
Оценка: -1
Здравствуйте, Andrew S, Вы писали:

AS>Ой ли? А не попытка ли это замаскировать проталкивание своей идеологии? Для каждой парадигмы есть свои ниши. И мое _глубокое_ убеждение, что в высокопроизводительных решениях управляемому коду (а уж тем более с GC) делать просто нечего. Может, я и ошибаюсь, но это _мое_ мнение.

ASM vs C
C vs C++
C++ vs .NET

AS>Любая видеокарта. Да, решается. Выходит очередная виндовс-виста, и все пользователи дружно покупают новое железо, где эта проблема решена аппаратно, например, введением аутентицированного доступа к регистрам управления. Потом 3 года пользователи ждут драйвера для новой железки, потом недоумевают, как это очередной квейк 10 при наличии графики а-ля дюк нюкем бегает примерно с такими же тормозами, как и оный на 486 dx4-100.

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

AS>Не такой уж и монстр. Но что уродец — это точно. Дык вот надо уродца править, вводить режима совместимости х86 в виде виртуализации (ведь внутри тот же к8 — это совсем не х86), а не изобретать очередной велосипед.

AS>И. Под всем этим все равно будет х86, со всеми ляпсусами. И в любом случае, низкоуровневые драйвера будут вынуждены использовать ассемблер\С, например, для доступа к портам. Т.е. опять же организовывается некий HAL. Позвольте, товарищи, но ведь тот же самый HAL и сейчас уже есть на NT.
От HAL никто никуда не денется. Вот только HAL HAL'у рознь.

AS>И что? Аналогично сейчас и под NT — 99 процентов правильно написаных драйверов просто перекомпилируются под нужную платформу — все делается через HAL.

Я говорил не только и не столько про драйверы... драйверы это вобще кот наплакал... я говорил про софт вобще.

AS>Трудней будет найти первый вариант. А потом — все пойдет по уже обкатанной на вин32 схеме

С тотальным CAS вирусам развернутся просто негде будет. Даже если юзер сидит под админом.

AS>И что? Это повод переходить на управляемый код, и терять в производительности? Сомнительно... Тем более что нормальных тестов производительности\безопасности так и не приведено

Потери производительности? Это только от качества оптимизатора зависит, а они постоянно совершенствуются.

AS>Системные сервисы — имеются в виду функции, предоставляемые ядром — натив апи и другие, те же вин32. User mode коду на самом деле доступно _очень_ мало даже сейчас, и отрубить ему вообще все варианты нагадить — очень просто. Вот только и даже более. Основная проблема сейчас, не внутренняя, а внешняя безопасность. А даже не ошибки, вызванные багами системных сервисов\приложения, а ... пользователи, работающие под администратором. Всегда. Т.е. установить драйвер и запустить его — относительно просто. Аналогичная ситуация будет и под любой другой системой — это проблема мышления пользователей, которые по 1,3.14здяйски (сорри, но другого термина просто тут не подобрать) относятся к секурити, а не безопасности системы...

Вот именно по тому что пользователи сидят под админом и нужен тотальный CAS.
AS>Подумай сам, ведь для реализации ремотинга (ведь надо же как то организовывать взаимодействие) все равно придется разрешать исполнение удаленного кода. И как только это будет позволено — все, внешней безопасности больше нет, как сейчас произошло с RPС на виндах...
Ответ не верный. Если у внешнего кода будут права только на то чтобы что-то сделать с потоком байт то никуда вломится он не сможет ибо CAS.

AS>Но ведь для этого не обязательно пользоваться IL. Достаточно написать качественные фреймворки для разработки и тестирования. Почему бы не тратить силы и время на это, а не на написание абстрактной ОС?

Попыток было много. И всем им далеко до успехов управляемых сред.
AS>Что то мне это ситуация Оберон больно напоминает. Теоретически все хорошо, а вот практически С++, созданный практиками и промышленностью, фактически убил все паскалеподобные языки.
Теоритически ни Оберон ни Оберон ОС ничего не стоят. Оберон примитивнеший язык с совершенно дурацким синтаксисом. Оберон ОС однопользовательские, без CAS, без изоляции процессов, с одним мусорщиком на всех...

AS>Это должно делаться на программно-_аппаратном уровне_ — см. виртуализацию.

А по мне это должно решаться на уровне VM. Те просто выкидываем x86'ой камень и ставим какуюнибудь альфу.
AS>Сейчас ее сделать очень муторно, это связано с убогостью х86. Но даже мелкие правки _значительно_ повысят производительность виртуальных машин. А что это значит — ну ты и сам понимаешь. Попробуй убить хост систему из-под вмваре? Вот и сандбокс для начальной проверки приложений\драйверов.
Начальной проверки абсолютно не достаточно. Проверка должна быть постоянной.

AS> Нет. Исходники, преобразованные в нужный вид, пригодный для анализа — этакий псевдокод, но отображающийся на нативный. Не IL. Как я уже говорил, большинство драйверов\приложений, написанных правильно, являются платформенно-независимыми в рамках NT.

Угу... а как ты будешь защищаться от рассинхронизации этого псевдокода и машинного кода?

AS>Например, какие системы имеются в виду? Например, если вспомнить вин нт 3.5, там многие драйвера были user-mode. В NT4 от этого отказались. Почему? Правильно — из-за низкой производительности. Причина — большое время вызова системных сервисов. Решение — тот же SYSCALL, но в нормальном вариант. Все-таки 200 тактов для callgate — это слишком.

Я имел в виду аппаратные решения по защите памяти с точностью до страници памяти и с контролем кто куда пишет.
AS>Почему ты считаешь, что тот же user mode драйвер (а это именно то, что предлагает сингулярити), но только еще более ограниченный в способах взаимодействия с аппаратурой, будет способен обеспечить хоть сколько приемлемую производительность той же видеоподсистемы?
А в чем проблема? В сингулярити все в одном кольце.
Если ты про контроль того куда можно писать, а куда нет то это пара тактов даже если оптимизатор не сможет устранить проверку что вряд ли.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 19:30
Оценка: -1
AS>>Еще раз. Я прощу тебя привести пример успешных ОС, построенных на управляемых средах, то, что имеет свойство называться управляемые системы. По крайней мере, я понял тебя именно так, думаю, все, кто это прочитает, поймут так же.
WH>Если бы я хотел написать ОС то я бы написал ОС. Система это совокупность программных и аппаратных решений.

AS>>Пусть подписывает.

WH>Ну и зачем тогда эта подпись вобще нужна?

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

AS>>На этот код в любом случае будет накладываться все то же ограничение, что и сейчас. Дополнительная информация нужна для определения "безопасности" нативного кода и решения, можно ли его загружать в текущем контектсе.

WH>И толку от такой проверки если она легко может быть фальсифицирована?
AS>>Загрузка на исполнение — ничего страшного не случится.
WH>Да ну? То-то у меня из-за одного кривого драйвера винда переодически в синий экран вываливается.
AS>>А вот если убитый IL загрузить в сингулярити — будет большой бабах. Ага?
WH>Я вот не слышал о том чтобы .НЕТ или жаба пропускали невалидный байткод.

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

AS>>Дополнительный лейер в виде IL. Если ты сможешь в IL задавать различные опции, влияющие на генерацию нативного кода, то ты потеряешь переносимость, да и смысл самого IL. Ну как мне еще это объяснить кроме как попросить тебя почитать про внутреннее устройство той же вин2к? Посмотри, как там это сделано, сколько оптимизировано просто _руками_. Прочитай, например, про префетч у Свена Шрайбера.

WH>Ссылки есть?
Есть книга "Недокументированные возможности Windows 2000"... стр.109. Вообще, может и можно что в интернет найти — ключевые слова OMAP, pdb. Мне не удалось с первой попытки, придется тебе просто поверить, что оно там есть либо достать книгу Еще, если интересно, можно почитать про SYSCALL\SYSENTER, про оптимизацию обработки прерываний в многопроцессорном кернеле... В общем то, много чего интересного, что совсем непросто будет реализовать только на IL — очевидно, опять потребуется использование неуправляемого кода, а следовательно, опять потенциальные проблемы, которые даже не будут зависеть от компилятора в IL\из IL.

AS>>Если новая система будет поддерживать виртуализацию — это не проблема. Поставь на xp64 wmware и наслаждайся старыми приложениями почти с той же производительностью. А если поддержка виртуализации будет аппаратной? Ведь то, как это сделано сейчас — просто магия. Я для интереса пробовал разобраться — там СТОЛЬКО всего...

WH>А если виртуализация будет основана на IL то никакой магии не нужно.

Магии не нужно на нормальном железе. Где оно, вот вопрос. И почему за почти 30 лет х86 этим никто не озаботился?

AS>>Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело.

WH>Ладно уел. Вот только ты забыл про
WH>

WH>>Кстати они сами сказали что не гонялись за производительностью. Так что там скорей всего можно еще будь здоров как все разогнать.


Ага. А теперь посмотри статью:

Если цель Singularity – надежность, почему эта статья содержит измерения производительности? Ответ прост: эти цифры демонстрируют, что предлагаемая нами архитектура не только не вредит производительности, но зачастую работает так же, как обычные системы, а то и быстрее. Другими словами, это практическая основа, на которой можно строить систему.

С другой стороны, в этой статье никак не отражена наша цель – повышение надежности. Измерить этот аспект системы существенно сложнее, чем производительность. У нас пока нет результатов для Singularity.


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

WH>>>Так вот если компилятор ЯВУ сгенерирует не верный IL то этот IL просто пошлют куда подальше.

AS>>Ты готов подписаться под этими словами? Один известный товарищ уже говорил, что перейти в ринг 0 под winnt невозможно без драйвера. Возможно, и способов уже известно несколько.
WH>Если компилятор IL будет доказан математически, а это возможно.

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

WH>>>Те ничто не мешает IL'у работать с тойже скоростью что и С++, а то и большей ибо доступны болие злые оптимизации из-за того что IL ограничен.

AS>>Ты готов под этим подписаться?
WH>Единственная проблема это есть некоторые проверки которые не устранить. Вот только съедают они очень мало. А во всем остальном можно оптимизировать не хуже чем С++. Болие того если подстраиваться под текущий процессор то...

А что мешает в абстрактную неуправляемую систему включить компилятор (как это сделано в юникс). Да и более того, кернел винды и сейчас содержит оптимизации под различные виды процессоров, да и HALы для них тоже различны... В общем то, повторюсь, ну никак я не вижу тут необходимости лишней прослойки в виде IL, уж извини. Наверное я тупой

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

AS>>>>так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае.

WH>>>А именно? Только ты учти что эта система совсем не НТ.
AS>>Я уже про часть из них говорил.
WH>А почему их невозможно применить в сингулярити говорил?

Потому что необходимо знание
1. Почему выполняется данная оптимизация (специфично для архитектуры платформы)
2. Каким образом выполнять данную оптимизацию (опять же специфично для архитектуры платформы)
3. Оптимально выполнить данную оптимизацию, (очевидно, итеративный процесс с промежуточными тестами).

Безусловно, какие то мелкие оптимизации можно будет сделать и тут, но полностью (учитывая что в сингулярили микрокернел) — на мой взгляд, просто невозможно.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re: Проект Singularity: обзор
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.06.06 15:04
Оценка:
Здравствуйте, Михаил Купаев (перевод), Вы писали:

МКП>Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


Складывается впечатление, что заявленые исследователями цели по построении надежной ОС уже реализованы в реальности: http://www.minix3.org
Причем без всяких заморочек с безопасными языками, отсутствием динамической загрузки кода, верификацией программ и прочим.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Проект Singularity: обзор
От: McSeem2 США http://www.antigrain.com
Дата: 06.06.06 00:59
Оценка:

...а остальная часть системы, исполняемая в SIP, состоит только из проверяемого безопасного (verifiably safe) кода, включая все драйверы устройств, системные процессы и приложения.


Чисто из любопытства. Драйверы устройств, если это не банальный USB, требуют плотного взаимодействия с аппаратурой, что является небезопасным по определению. Например, с видеокартой можно такого наворотить, что наступит полный систем-кирдык. Так или иначе, прямой доступ к железу обеспечить необходимо. А что тогда мешает видеодрайверу залезть в хард-драйв и все порушить? В чем же заключается безопасность и проверяемость драйверов?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Проект Singularity: обзор
От: McSeem2 США http://www.antigrain.com
Дата: 06.06.06 03:06
Оценка:
Здравствуйте, eao197, Вы писали:

E>Складывается впечатление, что заявленые исследователями цели по построении надежной ОС уже реализованы в реальности: http://www.minix3.org

E>Причем без всяких заморочек с безопасными языками, отсутствием динамической загрузки кода, верификацией программ и прочим.

Ну это какая-то любительская разработка. Есть еще QNX, например.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Проект Singularity: обзор
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.06.06 04:38
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ну это какая-то любительская разработка. Есть еще QNX, например.


Есть. Но QNX -- это ОС реального времени со всеми своими заморочками. Не факт что под нее будет удобно обычный софт писать.
А вот MINIX -- это обычный Unix, но ориентированный на отказоустойчивость. Сомневаюсь, что из него выйдет что-нибудь более-менее широко используемое на практике. Поскольку это разработка ученого, а не инженеров в мегакорпорации, то у MINIX есть все шансы повторить историю Виртовских Оберонов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Проект Singularity: обзор
От: mrozov  
Дата: 11.06.06 09:49
Оценка:
Здравствуйте, adontz, Вы писали:

A>В любом случае всё сводится к проверке валидности параметров передаваемых в системные функции. Так что как раз никакой разницы.

Не сводится ни в малейшей степени. Это вообще тяжело назвать серьезной задачей. Безопасность — гораздо более серьезная область.

A>Что-за пропаганда?

Пропаганда здравого смысла.

Давайте вспомним java-аплеты. Они безопасны. Кое-какие проблемы были, но давно и не много.
И теперь уже не важно, насколько хитрожопым был автор аплета — смело запускайте, хоть из-под админа.
Контрпример — ActiveX. Их безопасность обеспечить нельзя. Задача попросту не решается.

A>Да тут как сказать. У MS маркетинг на уровне. Почему бы и не создать ещё одну ОС, ради рекламы, а?

Они вполне могут. Но я не думаю, что только для рекламы.


Вообще, очень здравая мысль эта CAS. Права пользователя — правами пользователя, а для каждой программы права все равно свои. И хотя драйвер видеокарты способен на многое, но вот доступа к сети (или папке my pictures) он не получит, как бы не старался. Это мог бы быть большой шаг вперед.
Re[6]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.06.06 10:41
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Не сводится ни в малейшей степени. Это вообще тяжело назвать серьезной задачей. Безопасность — гораздо более серьезная область.


OK, давайте перечислите задачи проверки безопасности.

M>Давайте вспомним java-аплеты. Они безопасны. Кое-какие проблемы были, но давно и не много.

M>И теперь уже не важно, насколько хитрожопым был автор аплета — смело запускайте, хоть из-под админа.
M>Контрпример — ActiveX. Их безопасность обеспечить нельзя. Задача попросту не решается.

Ну так у них и назначение разное.

M>Вообще, очень здравая мысль эта CAS. Права пользователя — правами пользователя, а для каждой программы права все равно свои. И хотя драйвер видеокарты способен на многое, но вот доступа к сети (или папке my pictures) он не получит, как бы не старался. Это мог бы быть большой шаг вперед.


Вопрос в том, а во что выльется такая тотальная проверка? Не станет ли супербезопасная система заодно и супертормозной?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Проект Singularity: обзор
От: Андрей Хропов Россия  
Дата: 11.06.06 17:17
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ну это какая-то любительская разработка.

Ну насчет "какая-то" это я бы не сказал.
В общем-то на основе идей одной из предыдущих версий Minix Линус Торвальдс написал Linux.
Ну а то что не промышленный уровень это да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Проект Singularity: обзор
От: Дьяченко Александр Россия  
Дата: 11.06.06 17:47
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>И. Сделав подобный верифайер, можно _существенно_ снизить вероятность атаки и на неуправляемый код. Что мешает его сделать? А то, что сейчас политика сместилась на управляемый код.


Ну похоже в этом направлении тоже что-то делается. Правда на уровне исходников. Искать по словам "Prefast for Drivers" и "Static Driver Verifier".
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[7]: Проект Singularity: обзор
От: WolfHound  
Дата: 12.06.06 21:03
Оценка:
Здравствуйте, adontz, Вы писали:

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

Не станет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.06.06 21:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Не станет.

Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 20:01
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности.

А причем тут винда и интероп?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 20:01
Оценка:
Здравствуйте, adontz, Вы писали:

A>Это скорее говорит о степени оптимизации, чем о наличии информации.

Нет. Именно о наличии информации. В бинарнике не остается никакой информации о структуре кода.

A>Попробуй, используя только safe код написать видеодрайвер

В сингулярити написали.

A>Как это так — буфер есть, а переполнения нет?

А вот так.
A>Если посылать заведомо некорректные данные, на которые программа не расчитана, то она упадёт.
В нормальной программе будет откат транзакции.
A>И, собственно, какая к чёрту разница она просто упадёт или удастстя записать код в стек?
Да в самом деле какая разница?... Послали пользователя который засылает не пойми что или отдали данные стоймостью несколько миллионов кому попало?
A>Ведь DoS атака уже удалась.
Одно дело DDoS другое дело когда сервер секретные данные кому попало передает.
A>Вот, например, если в форумах РСДН тема топика слишком длиная, то в ответе, после добавления 'Re:', конец будет обрезан. Чем не переполнение и, как следствие, порча данных? Ну и как, помог тебе .Net фреймворк?
Это ограничение задано в базе данных. Задано оно не случайно и такое поведение предусмотрено.

A>Да вообще-то практически любой драйвер, если ты, конечно, не хочешь чтобы сетевая карта жрала 30% процессорного времени, а на GeForce 5200 можно было играть только во второй Quake.

Читай отчет по сингулярити еще раз. Там специально для тебя есть раздел в котором сравнивается производительность.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 20:01
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>IDA.

Я его давно не видел. А что он уже научился декомпилировать в С++ и буква A в этой аббревиатуре лишь дань бренду?
AS>Ну и плюсом — что мешает включать нужную для подобной декомпиляции информацию в бинарники (хотя бы тех же драйверов)?
Те рядом положить IL или что-то подобное?
AS>Еще раз IL — это не панацея.
А кто говорит про панацею? Это просто шаг вперед.

AS>Из драйвера? Элементарно. Пример уже приводили сами авторы — перепрограммировать любое устройство, которое может мапить память на адресное пространство PCI шины.

И много таких устройств? Может это просто решается сертификацией драйверов для подобных устройств?
AS>И. где гарантия, что реализация JIT компилятора для IL, вериафайера и сандбокса будет идеальна и свободна от ошибок?
Это относительно небольшой объем кода. И весь этот код контролируется одной конторой. Его можно просто математически доказать.
AS>Если уж они в железе есть (а ведь там архитектура проверяется годами), то и тут их не избежать.
Железо постоянно модифицируется. К тому же сейчас x86 это просто монстр какойто... мне вобще не понятно как до сих пор эта архитектура находится на плаву.
Кстати есть одно убийственное преймущество таких ОС... это независимость от железа самой ОС и всего софта что под нее написан. Ибо для портирование всего софта под новый процессор достаточно переписать лишь часть JIT'а.
AS>И дырки _будут_ находиться. Сейчас их "нет", поскольку никому не надо. Вспомни, вирусы под win32 тоже не сразу появились — понадобилось пару лет — и ва ля. Спрос породит предложение.
Вирусы ходят через переполнение буфера и отсутствие CAS.
Я не говорю что под управляемой ОС вирусов не будет вобще но то что их будет делать намного трудней это определенно.

AS>Про верифайер для драйверов уже написали.

А что они там такого написали? Что именно проверяется? Корректность работы с железкой? Так верифаер управляемого кода справится с этим по крайней мере не хуже.
AS>Почему бы подобное не сделать для системных сервисов?
А системные сервисы вобще творят что-попало. Их вобще озвереешь врефифицировать. И управляемый код вместе с вездисущим CAS тут будет как нельзя кстати.

AS> Супер. Это пять. Мы говорим про безопасность приложений (то бишь гарантию того, что неправильно написаный драйвер не вынесет всю систему) или про внешнюю безопасность? Это как бы ортогональные вещи. Внутреняя безопасность — это проблемы драйверов и системных сервисов.

Те проблемы пользователей...
AS>Существующие проблемы внешней безопасности вызваны как банальными ошибками программирования (те же переполнения буфера), так и ошибками в архитектуре (например, DCOM на windows 9х).
Вот я предлагаю избавится хотябы от ошибок программирование по максимому.
AS>Проблемы же внутренней безопасности решаются написанием адекватного фреймворка для тестирования и разработки драйверов, которого вот уже как больше 10 лет нет (сколько там процентов падений системы вызвано ошибками в драйверах? 80 или больше, я уже не помню — но цифирь была). До сих пор написание драйвера — это пыточный процесс, включающий в себя поиск документации, разбор недокументированных функций и т.п. Ведь просто _нормальный_ фреймворк повысил бы стабильность драйверов на порядки. Но его нет. И не будет, судя по всему.
Вот управляемые ОС это и есть путь к такому фреймворку. Причем значительно болие нормальному чем можно будет добится под виндой.

AS>1. Почему бы не разработать нормальный вариант расширения х86 (нет, не убогий SYSCALL), который бы позволил аппаратно кешировать состояния потоков. В этом случае вызовы системных сервисов и переключения контекста занимали _значительно_ меньшее время. (А ведь это единственный видимый плюс, показаный на тестах из статьи)

Угу... еше одно расширение x86... как ты думешь систему можно расширять бесконечно сохраняя обратную совместимость?
AS>2. Почему бы не поправить некоторые ошибки х386 — те же непривелигерованные привелегированные команды и прочее?
Править ошибки в железе? Те забить на совместимость?
AS>3. Зачем вводить лишнюю прослойку из IL, когда при желании компилятор может предоставить всю нужную информацию для анализа неуправляемого кода?
Те рядом положить IL? И отказаться от межпроцессорной переносимости?

AS>В общем, повторюсь, все, что было приведено — не аргументация и тем более не серьезный анализ безопасности предлагаемого решения (как на уровне защиты от непреднамеренных ошибок, так и от преднамеренных). Я на звание специалиста в данной области не претендую, и все, кто тут высказывался, по-видимому, тоже (по крайней мере, я адекватных аргументов не увидел). Все сводится к тому, что "IL это безопасно, потому что безопасно и типизированно, .нет — это хорошо и прогрессивно". По мне — это плохая аргументация. Ровно так же много лет назад говорили про защищенный режим 386. К чему это привело сейчас — знают все.

Гранулярность защиты в x86'ой архитектуре очень низкая. Также она очень низкая и во всех других системах о которых я читал. Именно по этому я не верю в чисто аппаратное решение. В тоже время защита в управляемой системе работает хоть с точностью до бита. Причем статический анализ подавляющие большинство этих проверок способен убрать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.06.06 20:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Да вообще-то практически любой драйвер, если ты, конечно, не хочешь чтобы сетевая карта жрала 30% процессорного времени, а на GeForce 5200 можно было играть только во второй Quake.

WH>Читай отчет по сингулярити еще раз. Там специально для тебя есть раздел в котором сравнивается производительность.

Там нет ничего про видеодрайверы.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.06.06 20:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности.

WH>А причем тут винда и интероп?

Насколько я понял права per executable в Singularity присутсвуют.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 20:57
Оценка:
Здравствуйте, adontz, Вы писали:

A>Там нет ничего про видеодрайверы.

Но есть про сеть.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 20:57
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности.

WH>>А причем тут винда и интероп?
A>Насколько я понял права per executable в Singularity присутсвуют.
Не понял.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.06.06 21:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Там нет ничего про видеодрайверы.

WH>Но есть про сеть.

TCP-стек Singularity не полностью совместим с IPv4


Не ясно что сравнивалось. Полная реализация может иметь другие показатели.

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


FastEthernet поддерживающий скорость 100МБит/сек существует с 1992 года.
GigabitEthernet поддерживающий скорость 1000МБит/сек существует с 1996 года.
В данный момент за окном наблюдается 2006 год.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.06.06 21:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Насколько я понял права per executable в Singularity присутсвуют.

WH>Не понял.

Ну аналог CAS, когда программа будучи запущенной под админом всё равно имеет ограниченные права.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 21:22
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ну аналог CAS, когда программа будучи запущенной под админом всё равно имеет ограниченные права.

Ты вобще статью читал? А про то как обеспечивается безопасность в этой ОС читал?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Проект Singularity: обзор
От: WolfHound  
Дата: 13.06.06 21:22
Оценка:
Здравствуйте, adontz, Вы писали:

A>

TCP-стек Singularity не полностью совместим с IPv4

A>Не ясно что сравнивалось. Полная реализация может иметь другие показатели.
Может иметь, а может и не иметь.

A>

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


A>FastEthernet поддерживающий скорость 100МБит/сек существует с 1992 года.

A>GigabitEthernet поддерживающий скорость 1000МБит/сек существует с 1996 года.
A>В данный момент за окном наблюдается 2006 год.
Это голая пропускная способность железа. Тут же речь идет о весьма навороченом протоколе.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Проект Singularity: обзор
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.06.06 21:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Не ясно что сравнивалось. Полная реализация может иметь другие показатели.

WH>Может иметь, а может и не иметь.

Вот именно, так что в топку такие тесты.

A>>

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.

A>>FastEthernet поддерживающий скорость 100МБит/сек существует с 1992 года.
A>>GigabitEthernet поддерживающий скорость 1000МБит/сек существует с 1996 года.
A>>В данный момент за окном наблюдается 2006 год.
WH>Это голая пропускная способность железа. Тут же речь идет о весьма навороченом протоколе.

Какой такой протокол? Ясно же написано

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек

A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 10:13
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>Только вот недавно написал инсталлятор, который это дело обходит на винхр. Использую _только_ разрешенные системные сервисы и средства. Что будет мне мешать сделать ровно то же и там? Думаю, риторически, верно?

Это не корректное обобщение. По чему ты думаешь что если это возможно для WinXP то это возможно для любой ОС?

AS>Эээ, нет, дорогой. Основной упор сингулярити — это внутреняя безопасность, когда некорректно написанного драйвера быть просто не может (ура, все программисты наконец то станут писать идеальный код и наступит Великое Завтра).

Это касается не только драйверов. Ведь вирусы ходят в основном через прикладной софт, а не через драйверы.
К тому же ты опять переключаешься с темы переносимости.

WH>>С тотальным CAS вирусам развернутся просто негде будет. Даже если юзер сидит под админом.

AS>
Чего улыбаешься? Если процесс только и может что общатся по предоставленным ему каналам то ничего другого он сделать не сможет.

AS>Введение любого промежуточного представления (того же IL) — это потери.

Не больше чем при приминении С/С++.
AS>Если ты посмотришь, сколько времени в процентном соотношении занимают системные вызовы в среднестатистическом сервере, ты поймешь, что это, собственно, не камень преткновения на вин нт (там фактически доли процента получаются). Ты можешь гарантировать, что оптимизатор с довольно ограниченного IL сможет обеспечить нормальный код? Я бы не стал на это ставить больше одной копейки
А я бы стал. Учитывая что уже сейчас .НЕТ не сильно отстает от С++. А там еще оптимизатор писать и писать.

AS>Нужно нормальное разграничение прав доступа. И сделать это в текущей NT — не просто, а очень просто. Все зависит от культуры администрирования.

Тебе самому не смешно? Какая культура у тети Кати которая только и может что включить компьютер и запустит ворд? А выйти в инет для нее вобще высший пилотаж.
Болие того даже крутые админы тоже люди... и чем меньше мест где они могут накосячить тем меньше будет косяков...

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

Верифайер проверяет корректность IL'а и его метаинформации. Если тебе удастся сгенерить не корректный IL который пропустит верифайер то может ты и сможешь что-то сломать.
Вот только моя практика показывает что сгенерить некорректный IL который пропустит .НЕТ не получается. .НЕТ даже загружает сборку с некорректным IL'ом вот только при попытке обратится к этому коду вылетает исключение что-то типа НеМогуСкомпилироватьТотБредЧтоВыМнеПодсунули. А в сингулярити программа с не корректным IL даже не установится.

AS>Назови примеры успешных управляемых сред, используемых достаточно широко?

.NET, Java. Достаточно? На этих технологиях наколбасили кода я так думаю побольше чем на С++. При том что С++ намного старше.

WH>>Теоритически ни Оберон ни Оберон ОС ничего не стоят. Оберон примитивнеший язык с совершенно дурацким синтаксисом. Оберон ОС однопользовательские, без CAS, без изоляции процессов, с одним мусорщиком на всех...

AS>Заметь, это не я сказал.
А какое отношение убогий оберон имеет к сингулярити с совершенно иной архитектурой?

AS>Ответ не верный. Постоянная проверка — гарантия тормозов.

Проверка проверке рознь. Если эта проверка сделана статически, а большинство проверок можно выполнить статически...

AS>Введением подписи. Уж синхронизировать их (а тем более в одном бинарнике) проблемы не будет, а?

И кто будет подписывать? К томуже с таким подходом придется подписывать абсолютно весь софт в то время как в сингулярити нужно подсписывать только небольшую группу драйверов. Объем работы отличается на несколько порядков.

AS>Например? Конкретные платформы. А то как то получается беспредметно.

Singularity? Прошлый век!
Автор: Cyberax
Дата: 31.05.06


AS>Ты действительно так думаешь? Ну... мне тогда нечего сказать.

Именно. Например и тогоже отчета пример драйвера для S3Trio
// Hardware resources from PCI config
[IoMemoryRange(0, Default = 0xf8000000, Length = 0x400000)]
IoMemoryRange frameBuffer;
// Fixed hardware resources
[IoFixedMemoryRange(Base = 0xb8000, Length = 0x8000)]
IoMemoryRange textBuffer;
[IoFixedMemoryRange(Base = 0xa0000, Length = 0x8000)]
IoMemoryRange fontBuffer;
[IoFixedPortRange(Base = 0x03c0, Length = 0x20)]
IoPortRange control;
[IoFixedPortRange(Base = 0x4ae8, Length = 0x02)]
IoPortRange advanced;
[IoFixedPortRange(Base = 0x9ae8, Length = 0x02)]
IoPortRange gpstat;

Все проверки при работе с HAL'ом занимают пару тактов даже если они не будут устранены.
AS>Это сильно! В отдельных процессах. Даже если учесть, что процессы тут очень легкие, все равно. Иы хоть представляешь, какова производительность этого?
2 message ping pong 1,452 CPU Cycles это со всеми проверками шедулингом... Это болие чем в 4 раза быстрее чем в винде.
AS>Пусть даже драйвер как trustee общается c hal при помощи прямых вызовов.
Именно это он и делает. Только драйвер не trusted, а verified. И проверки осуществляются через те атрибуты что я показал выше.
AS>Но это все фигня — основное назначение драйвера обеспечивать интерфейс вовне. Представь себе производительность обмена по каналам в случае gdi драйвера, тем более тот исполняет в контексте отдельного процесса, а значит, каждый обмен — это шедулинг?
Виндовый ABI call 627 такста. Посылка сообщения в сингулярити 1,452 / 2 = 726. Не сильно медленней. И это при том что сообщение может быть любого объема.
AS>Просто в качестве интереса — есть практический опыт написания драйверов?
Нет.
AS>У меня небольшой есть — и даже тут уже приходится задумываться о том, как лучше организовать взаимодействие с user. И это при том, что в моем распоряжении все же не каналы, а гораздо более мощные и быстродействующие механизмы...
Например?

AS>А во-вторых. Сколько ты думаешь времени занимает контроль правильности параметров при системном вызове виннт? С учетом, что вызов занимает около 500-2000 тактов (в зависимости от системы), а смена контекста user\kernel — 100-200 (тоже в зависимости от системы).

Столькоже как и при вызове пользовательского кода. Ты забываешь одну не маловажную вещь, а именно то что если в интерфейсе написано что придет указатель значит придет указатель причем именно на тот тип на какой сказано если это массив то там будет памяти ровно столько сколько нужно для того чтобы разместить этот массив в то время как в винде может прибыть любой мусор.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 13:14
Оценка:
AS>>Назови примеры успешных управляемых сред, используемых достаточно широко?
WH>.NET, Java. Достаточно? На этих технологиях наколбасили кода я так думаю побольше чем на С++. При том что С++ намного старше.

В данном случае мы говорим про операционные системы, а не меряем пенисы в виде количества кода С++ и Джава. Давай не отклоняться от темы, ок?

WH>>>Теоритически ни Оберон ни Оберон ОС ничего не стоят. Оберон примитивнеший язык с совершенно дурацким синтаксисом. Оберон ОС AS>>Ответ не верный. Постоянная проверка — гарантия тормозов.

WH>Проверка проверке рознь. Если эта проверка сделана статически, а большинство проверок можно выполнить статически...

Ровно как и для неуправляемого кода. Пример уже приводили.

AS>>Введением подписи. Уж синхронизировать их (а тем более в одном бинарнике) проблемы не будет, а?

WH>И кто будет подписывать? К томуже с таким подходом придется подписывать абсолютно весь софт в то время как в сингулярити нужно подсписывать только небольшую группу драйверов. Объем работы отличается на несколько порядков.

Подписывать их будет компилятор, который сгенерил данный бинарник. Ведь никто не отменяет _текущие_ ограничения, это лишь вспомогательная информация.

AS>>Ты действительно так думаешь? Ну... мне тогда нечего сказать.

WH>Именно. Например и тогоже отчета пример драйвера для S3Trio
WH>
WH>// Hardware resources from PCI config
WH>[IoMemoryRange(0, Default = 0xf8000000, Length = 0x400000)]
WH>IoMemoryRange frameBuffer;
WH>// Fixed hardware resources
WH>[IoFixedMemoryRange(Base = 0xb8000, Length = 0x8000)]
WH>IoMemoryRange textBuffer;
WH>[IoFixedMemoryRange(Base = 0xa0000, Length = 0x8000)]
WH>IoMemoryRange fontBuffer;
WH>[IoFixedPortRange(Base = 0x03c0, Length = 0x20)]
WH>IoPortRange control;
WH>[IoFixedPortRange(Base = 0x4ae8, Length = 0x02)]
WH>IoPortRange advanced;
WH>[IoFixedPortRange(Base = 0x9ae8, Length = 0x02)]
WH>IoPortRange gpstat;
WH>

WH>Все проверки при работе с HAL'ом занимают пару тактов даже если они не будут устранены.

И что? Ровно так же драйвер в NT общается с HAL — просто вызовы функций. О чем это говорит? А ни о чем. Хотя, нет. NT хал будет как минимум не медленнее (а с учетом оптимизации — наверняка быстрее).

AS>>Это сильно! В отдельных процессах. Даже если учесть, что процессы тут очень легкие, все равно. Иы хоть представляешь, какова производительность этого?

WH>2 message ping pong 1,452 CPU Cycles это со всеми проверками шедулингом... Это болие чем в 4 раза быстрее чем в винде.

Быстрее чем что? Чем именованые каналы? Это вообще разные вещи. Корректно сравнивать LPC. В сингулярити каналы — основной способ общения. А в NT — lpc и api call. Не надо смешивать теплое с мягким. Я могу сделать апи, которое будет супер быстрое для решения одной локальной задачи и мегатормозное для всех остальных мильонов. И о чем это говорит? Да о заточке под конкретное тестирование. Корректно брать кумулятивные тесты, включающие обращение к аппаратуре, вычисления, и т.п. — в общем, эмулирующие обычную активность как сервера, так и рабочей станции, и на основании этих результатов сравнивать производительность.

AS>>Пусть даже драйвер как trustee общается c hal при помощи прямых вызовов.

WH>Именно это он и делает. Только драйвер не trusted, а verified. И проверки осуществляются через те атрибуты что я показал выше.
AS>>Но это все фигня — основное назначение драйвера обеспечивать интерфейс вовне. Представь себе производительность обмена по каналам в случае gdi драйвера, тем более тот исполняет в контексте отдельного процесса, а значит, каждый обмен — это шедулинг?
WH>Виндовый ABI call 627 такста. Посылка сообщения в сингулярити 1,452 / 2 = 726. Не сильно медленней. И это при том что сообщение может быть любого объема.

Сомнительная арифметика. 627 на просто смену контекста — нонсенс. в случае использования SYSCALL\SYSENTER — не верю.
http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223__2/
http://groups.google.ru/group/fido7.talks.asm/browse_frm/thread/8e2bcac6d5a507e/9fc6af5cace5b674?lnk=st&amp;q=SYSENTER&amp;rnum=6&amp;hl=ru#9fc6af5cace5b674


Total CPU
Entering Supervisor Mode
Exiting Supervisor Mode
Transition Time


Sysenter/Sysexit Instruction-based System Call
0x076 (118)
0x03f (63)
0x0b5 (181)



Итого — 181 + еще тактов 100 на все остальные манипуляции. Итого в 2 раза меньше. Откуда у них взялась та цифирь???

AS>>У меня небольшой есть — и даже тут уже приходится задумываться о том, как лучше организовать взаимодействие с user. И это при том, что в моем распоряжении все же не каналы, а гораздо более мощные и быстродействующие механизмы...

WH>Например?

Разделяемая заблокированная память, секции. IOCTL (аж 2 разных типа) + MDL. В общем, способов получить _максимальное_ быстродействие взаимодействия с пользователем много. Единственно — большое время смена контекста, о чем все давно пинают m$. Но это может и _должно_ решаться аппаратно — я не могу понять, _почему_ процессоры содержат аппаратную поддержку тасков, но при это в целях повышения производительности используется программный вариант. Нонсенс? А ведь должно быть наоборот и пинать нужно производителей процессоров за подобное хамство. Ты посмотри, просто для интереса, какие извращения приходится делать, чтобы обеспечить приемлемую производительность на х86... Это проблемы аппаратные, а не программные, и почему их не решают — право, я не знаю. Наверняка, были регрессивные тесты, по которым было понятно где узкое место и наверняка переключения контекстов и потоков это не то, где надо искать производительность. Опять же, сравни приведенную статистику памяти. Надеюсь, ты не будешь спорить с тем, что чем меньше воркинг сет для процесса, тем быстрее и манаджер памяти, и сам исполняемый код, который лучше помещаяется в T-кеш?

AS>>А во-вторых. Сколько ты думаешь времени занимает контроль правильности параметров при системном вызове виннт? С учетом, что вызов занимает около 500-2000 тактов (в зависимости от системы), а смена контекста user\kernel — 100-200 (тоже в зависимости от системы).

WH>Столькоже как и при вызове пользовательского кода. Ты забываешь одну не маловажную вещь, а именно то что если в интерфейсе написано что придет указатель значит придет указатель причем именно на тот тип на какой сказано если это массив то там будет памяти ровно столько сколько нужно для того чтобы разместить этот массив в то время как в винде может прибыть любой мусор.

Это верно. Но. Разве мы не можем сделать мод компилятора, который скажет, что придет одно, а на самом деле отправит другое? И что тогда будет в этом случае? С учетом, что обмануть верифайер тоже будет, думаю, можно. Что тогда? Писать верифайер, почти такой же, как и для нативного кода? А смысл тогда?
Заметь, я не говорю, что идея плоха или еще что (хотя я и считаю, что это слишком панковско, когда все в одном кольце + не верю в производительность IL кода как на основании объективных тестов и субъективных ощущений, так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае. Современные х86 — это очень тонкая штука. Тот же префетч позволяет повысить производительность в разы.). Я лишь говорю, что не все проблемы показаны, о некоторых вообще ничего не сказано, а приведенные тесты производительности никуда не годяться. Или ты считаешь, что приведенные результаты объективны? Извини, но тогда объясни мне,


Singularity выдала 91 операцию в секунду при взвешенной средней пропускной способности в 362 Kбит/с. Web-сервер IIS, выполняемый под управлением Windows 2003 на идентичной аппаратуре, выдает 761 операцию в секунду при взвешенной средней пропускной способности в 336 Kбит/с.

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


Разница по операциям в 8 раз — неслабо?
А что насчет стека TCP. 48 МБит? Извини, но даже на моем дохлом PII-366 на winnt4 я насыщал 100 мегабитную сетку на 100% обычными сокетами. А с учетом того, что гигабитные скорости сейчас совсем не редкость, а данность, то что это — демонстрация скорости каналов? Производительность диского теста я даже прокомментировать не могу — кто-нибудь вообще понял, что там и как тестировалось? Вот я смотрю соответствующие тесты на ф-центре и там все понятно — даны паттеры и прочее, видно, что где и как. Главное, доступны исходные коды тестов (f-test) и паттерны. Что же тут такое, а? Объясни мне, а то спать спокойно не смогу
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[13]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 16:12
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>>>Назови примеры успешных управляемых сред, используемых достаточно широко?

WH>>.NET, Java. Достаточно? На этих технологиях наколбасили кода я так думаю побольше чем на С++. При том что С++ намного старше.
AS>В данном случае мы говорим про операционные системы, а не меряем пенисы в виде количества кода С++ и Джава. Давай не отклоняться от темы, ок?
Вобщето ты начал про успешние управляемые среды...

AS>Ровно как и для неуправляемого кода. Пример уже приводили.

Где?

AS>Подписывать их будет компилятор, который сгенерил данный бинарник. Ведь никто не отменяет _текущие_ ограничения, это лишь вспомогательная информация.

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

AS>И что? Ровно так же драйвер в NT общается с HAL — просто вызовы функций. О чем это говорит? А ни о чем. Хотя, нет. NT хал будет как минимум не медленнее (а с учетом оптимизации — наверняка быстрее).

У тебя какоето сильно предвзятое мнение. Кто мешает сделать все теже оптимизации компилятору IL'а?

AS>Разделяемая заблокированная память, секции. IOCTL (аж 2 разных типа) + MDL. В общем, способов получить _максимальное_ быстродействие взаимодействия с пользователем много. Единственно — большое время смена контекста, о чем все давно пинают m$. Но это может и _должно_ решаться аппаратно — я не могу понять, _почему_ процессоры содержат аппаратную поддержку тасков, но при это в целях повышения производительности используется программный вариант. Нонсенс? А ведь должно быть наоборот и пинать нужно производителей процессоров за подобное хамство. Ты посмотри, просто для интереса, какие извращения приходится делать, чтобы обеспечить приемлемую производительность на х86... Это проблемы аппаратные, а не программные, и почему их не решают — право, я не знаю. Наверняка, были регрессивные тесты, по которым было понятно где узкое место и наверняка переключения контекстов и потоков это не то, где надо искать производительность.

Я вобщем не спорю с тем что x86 уродливый монстр. А менять архитектуру на право и на лево не дает какраз привязка всего софта к этому самому x86.
Я вот попробовал поставить WinXP64 так полдовина софта не встало.
AS>Опять же, сравни приведенную статистику памяти. Надеюсь, ты не будешь спорить с тем, что чем меньше воркинг сет для процесса, тем быстрее и манаджер памяти, и сам исполняемый код, который лучше помещаяется в T-кеш?
Гм... меньше получилось только у FreeBSD. Болие того большую часть памяти которую сожрал процесс можно спокойно расшарить между разными процессами.
Кстати они сами сказали что не гонялись за производительностью. Так что там скорей всего можно еще будь здоров как все разогнать.

AS>Это верно. Но. Разве мы не можем сделать мод компилятора, который скажет, что придет одно, а на самом деле отправит другое? И что тогда будет в этом случае? С учетом, что обмануть верифайер тоже будет, думаю, можно. Что тогда? Писать верифайер, почти такой же, как и для нативного кода? А смысл тогда?

Мод компилятора сделать не возможно. Ибо компиляторы ЯВУ генерирую IL и метаинформацию, а машинный код генерирует компилятор вшитый в систему.
Так вот если компилятор ЯВУ сгенерирует не верный IL то этот IL просто пошлют куда подальше.
AS>Заметь, я не говорю, что идея плоха или еще что (хотя я и считаю, что это слишком панковско, когда все в одном кольце + не верю в производительность IL кода как на основании объективных тестов и субъективных ощущений,
Ну субъективные ощущения можно сразу послать куда подальше. А вот мои тесты говорят что IL с каждой версией .НЕТ работает все шустрей. Те дело лишь в развитии оптимизаторов.
Те ничто не мешает IL'у работать с тойже скоростью что и С++, а то и большей ибо доступны болие злые оптимизации из-за того что IL ограничен.
AS>так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае.
А именно? Только ты учти что эта система совсем не НТ.
AS>Современные х86 — это очень тонкая штука. Тот же префетч позволяет повысить производительность в разы.). Я лишь говорю, что не все проблемы показаны, о некоторых вообще ничего не сказано, а приведенные тесты производительности никуда не годяться. Или ты считаешь, что приведенные результаты объективны? Извини, но тогда объясни мне,
Скажем так я не думаю что они сильно искажены ибо если так то рано или позно будет скандал.
AS>Разница по операциям в 8 раз — неслабо?
Ты не забывай что там еще Web сервер не понятного происхождения под ногами путается.
AS>А что насчет стека TCP. 48 МБит? Извини, но даже на моем дохлом PII-366 на winnt4 я насыщал 100 мегабитную сетку на 100% обычными сокетами. А с учетом того, что гигабитные скорости сейчас совсем не редкость, а данность, то что это — демонстрация скорости каналов? Производительность диского теста я даже прокомментировать не могу — кто-нибудь вообще понял, что там и как тестировалось? Вот я смотрю соответствующие тесты на ф-центре и там все понятно — даны паттеры и прочее, видно, что где и как. Главное, доступны исходные коды тестов (f-test) и паттерны. Что же тут такое, а? Объясни мне, а то спать спокойно не смогу
А у меня ты чего спрашиваешь? Я чтоли эти тесты проводил.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Проект Singularity: обзор
От: Дьяченко Александр Россия  
Дата: 14.06.06 18:23
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>

AS>Singularity выдала 91 операцию в секунду при взвешенной средней пропускной способности в 362 Kбит/с. Web-сервер IIS, выполняемый под управлением Windows 2003 на идентичной аппаратуре, выдает 761 операцию в секунду при взвешенной средней пропускной способности в 336 Kбит/с.

AS>Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


AS>Разница по операциям в 8 раз — неслабо?


Из нового TR (уже не так плохо):

Singularity achieves 247 ops/second with a weighted average throughput of 376 Kbits/second. By contrast, Microsoft Windows 2003 running the IIS web server, on identical hardware, achieves 761 ops/second with a weighted average throughput of 336 Kbits/second. Singularity’s average response time, with 78 connections, of 320 ms/op is comparable to Window’s time of 304 ms/op. Singularity’s throughput on this benchmark is not bound by the sealed architecture, but
is disk bound and limited by the caching algorithms in our experimental file system. In contrast, Windows is network bound thanks to its highly tuned file caching. We have an ongoing effort to improve the file system and expect much closer performance in the future. While definitely not conclusive, the response time numbers suggest that the sealed process architecture is viable.

Может в старом опечатка или что-то они там допиливают...
Кстати они вроде еще ее не наголой машине пускают а на WMVare (или уже нет?), что тоже должно сказываться...
Кстати там вроде и тест описывается достаточно подробно и железо там тоже дано.

Ссылки:

TR-2006-43 (Здесь так что-то где-то задевается по касательной)
TR-2006-51 (С цифрами здесь)
... << RSDN@Home 1.2.0 alpha rev. 652>>
Re[15]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 19:04
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>Еще раз. Я прощу тебя привести пример успешных ОС, построенных на управляемых средах, то, что имеет свойство называться управляемые системы. По крайней мере, я понял тебя именно так, думаю, все, кто это прочитает, поймут так же.

Если бы я хотел написать ОС то я бы написал ОС. Система это совокупность программных и аппаратных решений.

AS>Пусть подписывает.

Ну и зачем тогда эта подпись вобще нужна?
AS>На этот код в любом случае будет накладываться все то же ограничение, что и сейчас. Дополнительная информация нужна для определения "безопасности" нативного кода и решения, можно ли его загружать в текущем контектсе.
И толку от такой проверки если она легко может быть фальсифицирована?
AS>Загрузка на исполнение — ничего страшного не случится.
Да ну? То-то у меня из-за одного кривого драйвера винда переодически в синий экран вываливается.
AS>А вот если убитый IL загрузить в сингулярити — будет большой бабах. Ага?
Я вот не слышал о том чтобы .НЕТ или жаба пропускали невалидный байткод.

AS>Дополнительный лейер в виде IL. Если ты сможешь в IL задавать различные опции, влияющие на генерацию нативного кода, то ты потеряешь переносимость, да и смысл самого IL. Ну как мне еще это объяснить кроме как попросить тебя почитать про внутреннее устройство той же вин2к? Посмотри, как там это сделано, сколько оптимизировано просто _руками_. Прочитай, например, про префетч у Свена Шрайбера.

Ссылки есть?

AS>Если новая система будет поддерживать виртуализацию — это не проблема. Поставь на xp64 wmware и наслаждайся старыми приложениями почти с той же производительностью. А если поддержка виртуализации будет аппаратной? Ведь то, как это сделано сейчас — просто магия. Я для интереса пробовал разобраться — там СТОЛЬКО всего...

А если виртуализация будет основана на IL то никакой магии не нужно.

AS>Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело.

Ладно уел. Вот только ты забыл про

WH>>Кстати они сами сказали что не гонялись за производительностью. Так что там скорей всего можно еще будь здоров как все разогнать.


WH>>Так вот если компилятор ЯВУ сгенерирует не верный IL то этот IL просто пошлют куда подальше.

AS>Ты готов подписаться под этими словами? Один известный товарищ уже говорил, что перейти в ринг 0 под winnt невозможно без драйвера. Возможно, и способов уже известно несколько.
Если компилятор IL будет доказан математически, а это возможно.

WH>>Те ничто не мешает IL'у работать с тойже скоростью что и С++, а то и большей ибо доступны болие злые оптимизации из-за того что IL ограничен.

AS>Ты готов под этим подписаться?
Единственная проблема это есть некоторые проверки которые не устранить. Вот только съедают они очень мало. А во всем остальном можно оптимизировать не хуже чем С++. Болие того если подстраиваться под текущий процессор то...

AS>>>так и из-за наличия некоторых знаний о способах оптимизации ядра NT, которые просто невозможно применить в данном случае.

WH>>А именно? Только ты учти что эта система совсем не НТ.
AS>Я уже про часть из них говорил.
А почему их невозможно применить в сингулярити говорил?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Нифига.
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 14.06.06 19:16
Оценка:
Здравствуйте, Андрей Хропов, Вы писали:

АХ>В общем-то на основе идей одной из предыдущих версий Minix Линус Торвальдс написал Linux.

Нет. Торвальдс написал Линукс, чтобы использовать его как замену Миниксу, потому что в тот момент лицензия на Миникс была несвободная. Но вот по архитектуре эти 2 системы ничего общего не имеют. У Торвальдса — монолит с динамической загрузкой модулей, а у Танненбаума — микроядро. У них по этому поводу даже спор был, их переписка довольно известна, поищи на сайте Миникса. Танненбаум даже как-то в сердцах высказался, что будь Торвальдс его студентом, он у него за такую архитектуру "неуд" бы получил
Re[4]: О цене реалтайма
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 14.06.06 19:21
Оценка:
Здравствуйте, eao197, Вы писали:

E>QNX -- это ОС реального времени со всеми своими заморочками. Не факт что под нее будет удобно обычный софт писать.


А какие у ОСРВ заморочки, кроме снижения средней производительности? ИМХО, там всё то же, только приходится платить за детерменированность временных характеристик при худшем случае снижением производительности в среднем. Как-никак, это дополнительный функционал, а он за бесплатно не бывает.
Re[4]: RT MINIX
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 14.06.06 19:23
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>QNX -- это ОС реального времени ... А вот MINIX -- это обычный Unix, но ориентированный на отказоустойчивость.


Есть, кстати, real-time модификация Minix'а.
Re[17]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 20:43
Оценка:
Здравствуйте, Andrew S, Вы писали:

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

Для этого придется написать доказавальщик который работает с учетом указателей и реинтерпритации памяти.
А это задаче ИМХО вобще не разрешимая.
К тому же зачем нам нужно отсекать только не намеренные косяки?

AS>Ну так это пока никому не надо? Ты готов дать гарантию, что это невозможно, если кому то очень понадобится?

Для жабы и .НЕТ нет ибо на сколько мне извесно их оптимизаторы математически не доказываются.

WH>>Если компилятор IL будет доказан математически, а это возможно.

AS>Аналогично я могу сказать, что можно доказать математически устойчивость абстрактного процессора. Доказательства возможности доказательства есть? Очень бы хотелось хотя бы общие положения. Наконец кто-то решил задачу многокритериального поиска за приемлемое время.
Тут нужно различать систему которая ищет доказательства и систему которая проверяет доказательства.
Те искать доказательства будет программист при помощи своей квантовой нейросетки которая иногда сбоит. А проверять будет машина вероятность сбоя которой практически равена нулю.
Re[5]: Процессор для safe OS
Автор: Cyberax
Дата: 13.06.06

Re[5]: Процессор для safe OS
Автор: Lazy Cjow Rhrr
Дата: 13.06.06


AS>А что мешает в абстрактную неуправляемую систему включить компилятор (как это сделано в юникс). Да и более того, кернел винды и сейчас содержит оптимизации под различные виды процессоров, да и HALы для них тоже различны... В общем то, повторюсь, ну никак я не вижу тут необходимости лишней прослойки в виде IL, уж извини. Наверное я тупой

IL позволяет создать кучу языков под платформу не заморачиваясь генерацией машинного кода.
Болие того иногда прикладным программам нужно создавать код на лету и с IL это сделать на порядки проще чем возится с чемто другим. Про прямую генерацию машинного кодя я вобще молчу.

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

Reflector востанавливает код почти один в один. Правда он заточен на C# и близкие к нему языки (VB.NET, Delphi.NET...) так что на nemerle он иногда затыкается ибо не может перевести сложный match в конструкции C#. Но если бы он был заточен на немерле то востанавливал бы и его хотя это намного сложнее ибо семантика языка плохо ложится на IL.
В любом случае спецификация IL такова что он в любом случае типизированный. Болие того проверка типизации производится за один проход по IL и алгоритм там настолько примитивный что накосячить практически не возможно.

Кстати я считаю что MSIL не самй подходящий промежуточный язык. Уж слишком бедны его возможности. К тому же мелкосов пошол по пути x86 напихав в IL кучу всякой дряни.
Тем не мение если кое что вычистить, кое что добавить то промежуточный язык для абстрагирования от платформы это то что нужно. И будет уже не важно что у нас за камень x86, alpha, sparc или что-то еще.

AS>Потому что необходимо знание

AS>1. Почему выполняется данная оптимизация (специфично для архитектуры платформы)
Прошивается в компилятор для данной платформы.
AS>2. Каким образом выполнять данную оптимизацию (опять же специфично для архитектуры платформы)
Опять же прошивается в компилятор.
AS>3. Оптимально выполнить данную оптимизацию, (очевидно, итеративный процесс с промежуточными тестами).
Вот разработчики компилятора пусть и проводят итерации.

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

AS>Безусловно, какие то мелкие оптимизации можно будет сделать и тут, но полностью (учитывая что в сингулярили микрокернел) — на мой взгляд, просто невозможно.

Ну без микроядра говорить о надежной системе вобще не стоит. Ибо если сбойнет драйвер режима ядра то все полутит к чертовой бабушке. А в микроядерной архитектуре полетит только этот драйвер который можно перезапустить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 20:50
Оценка:
WH>Кстати я считаю что MSIL не самй подходящий промежуточный язык. Уж слишком бедны его возможности. К тому же мелкосов пошол по пути x86 напихав в IL кучу всякой дряни.

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

WH>Тем не мение если кое что вычистить, кое что добавить то промежуточный язык для абстрагирования от платформы это то что нужно. И будет уже не важно что у нас за камень x86, alpha, sparc или что-то еще.


Ну а почему тот же С++ (или скажем так, промежуточные состояния компиляции с него) не может быть таким промежуточным языком? Платформенно-зависимых вещей в нем ведь тоже нет, типобезопасность при желании может быть на высоте (и уж компилятор точно в состоянии это проверить). Зачем обязательно тащить какой то IL, когда можно все делать на уровне исходников? Опять же для меня совсем не очевидны преймущества GC перед обычным менеджером памяти. Где то он выигрывает, где то — проигрывает. В общем, все совсем неоднозначно. Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем...
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[16]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 21:12
Оценка:
AS>>Получаем экзешник размером 2 (!!) кб и занимающий в воркинг сете 148 кб. Итого — приведенные в статье цифири есть БРЕД. Нормально замерить память, занимаемую приложением, можно только посмотрев то, что оно аллоцирует при помощиу VirtualQueryEx (и тут значения что для моего примера в 2кб, что для исходного в 40 кб будут очень близки — с точностью до разницы в размере бинарников). Заметь, в отличие от авторов статьи, я привел конкретные примеры, конкретные опции, сказал, что и где смотреть. Какие нафиг результаты после такого, ты о чем? Господа даже не потрудились разобраться, что они измеряют и как. Извини, но это не дело.
WH>Ладно уел.

Кстати, вот еще один аргумент, который ну совсем разрушает эти измерения (в т. ч. и мои, хотя они лишь были для демонстрации неправильности подхода). Дело в том, что занимаемое процессом виртуальное адресное пространство не есть показатель (в отличие от сингулярити, где виртуальное == физическое). Надо считать _физические_ страницы памяти, которые выделены под уникальные для процесса операции — его код и данные. Поскольку в NT и в линуксе\Free реализован подход, когда одинаковые модули разделяют код (насчет данных сейчас не помню, но и их часть, кажется тоже) — в общем, все, что в PE на уровне lazy copy on write — т.е. для dll создается копия физической страницы (которая отображает на тот же виртуальный адресс процесса, что и старая) только после ее (страницы) изменения. Поскольку такие изменения в системных библиотеках не происходят, то большинство даже из максимального воркинг сета — это собственно, общий код для всех процессов.
Вот, кстати, из статьи:

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

Т.е. они говорят что "а мы вот еще лучше сделаем, чем даже сейчас". А при том совершенно умалчивают о том, что, собственно, в приведенных результатах (если были бы приведены не воркинг сета, а закоммиченных для приложения страниц) для других систем бОльшая часть кода\данных _уже_ реализована как совместное использование библиотек. Т.о. приведенные изменения даже _теоретически_ ничего показать адекватного не могут, вот такие пироги. Все, что из них видно — каким образом работает менеджер памяти, обеспечивая префетч для виртуальных (а иногда и физических, но когда каких — непонятно) страниц по своим внутренним соображениям. Это, кстати, к вопросу о специалистах, которые писали эту статью. Тут явно или намернно умалчивают, либо просто не понимают, о чем речь. Как сказал адонтз — в топку такие тесты. Однозначно.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[19]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 21:18
Оценка:
Здравствуйте, Andrew S, Вы писали:

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

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

AS>Ну а почему тот же С++ (или скажем так, промежуточные состояния компиляции с него)

Те IL?
AS>не может быть таким промежуточным языком? Платформенно-зависимых вещей в нем ведь тоже нет,
Теоритически. На практике нужно писать код ооочень осторожно чтобы это было.
AS>типобезопасность при желании может быть на высоте (и уж компилятор точно в состоянии это проверить).
А это вобще мечты. Пока существуют касты отличные от dynamic_cast ни о какой типизации можно не говорить. Тоже самое касается висячих указателей и выходов за придела массива.
AS>Зачем обязательно тащить какой то IL, когда можно все делать на уровне исходников?
Везде распрастронять исходники? Тем болие исходники на С++ имеют привычку компилироваться часами.
AS>Опять же для меня совсем не очевидны преймущества GC перед обычным менеджером памяти. Где то он выигрывает, где то — проигрывает. В общем, все совсем неоднозначно.
Его главное преймущество это гарантированное отсутствие висячих указателей. Те не скорость, а надежность. Да и утечку памяти устроить гораздо сложнее.
Кстати в сингулярити можно делать любые ГЦ в том числе и полное отсутствие ГД для какого либо процесса в случае если память можно распределить один раз и навсегда.
AS>Зачем опять динамическая компиляция, когда достаточно сделать это один раз, как в том же линуксе? В общем, много зачем...
В сингулярити компиляция происходит во время установки программы. Дальше ОС поднимает уже скомпилированный код.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Проект Singularity: обзор
От: WolfHound  
Дата: 14.06.06 22:10
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>И опять таки упремся в проблему надежности компилятора в IL,

Этой проблемы не вобще. IL можно генерить как попало главное чтобы го не пропустил верифайер.
AS>верифайера и компилятора из IL в нативный код.
А вот это можно даказать математически.
Тпизация это тоже доказательство правильности работы которое проверяет компилятор и/или рантайм.
AS> Ведь если математически доказать корректность не представляется возможным,
Кто сказал?
Если человек придумает доказательство то компилятору останется его только проверить не забыл ли чего человек.
Скажем тот верифайр который встроен в современный .НЕТ настолько прост что его можно довольно легко доказать.
В принципе верифайр можно делать слоеным и доказывать каждый слой по отдельности.
В прочем верифайр это фигня. Доказать оптимизатор будет много сложнее хотя тоже возможно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Проект Singularity: обзор
От: Andrew S Россия http://alchemy-lab.com
Дата: 14.06.06 22:36
Оценка:
AS>> Ведь если математически доказать корректность не представляется возможным,
WH>Кто сказал?
WH>Если человек придумает доказательство то компилятору останется его только проверить не забыл ли чего человек.
WH>Скажем тот верифайр который встроен в современный .НЕТ настолько прост что его можно довольно легко доказать.
WH>В принципе верифайр можно делать слоеным и доказывать каждый слой по отдельности.
WH>В прочем верифайр это фигня. Доказать оптимизатор будет много сложнее хотя тоже возможно.

Вот и пример исследования по надежности — доказательство корректности оптимизатора и верифайера. И доказательноство того, что доказательства ихней надежности достоточно для обпеспечения надежности и устойчивости самой системы. Итого, если это возможно, то где они, доказательства, и в частности, в статье? И желательно, чтобы там же было обоснование невозможности сделать оного для нативного кода. Хороше обоснование, броня. Пока этого не будет — все это будет околонаучным проектом. А так ... все эти "можно, если и т.п." — вилами по воде писано. Не поверю, пока сам не увижу, не потрогаю и не пойму, почему так, а не иначе. Поинт.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[20]: Злостный офтоп
От: McSeem2 США http://www.antigrain.com
Дата: 15.06.06 04:59
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Тоже самое касается висячих указателей и выходов за придела массива.


(удручнно) Ну ты же грамотный человек! Не опускайся же до китайских чушков типа "девственный мел который уничтожить черви". Ты не подумай, что я на тебя наезжаю. Метафорически выражаясь, мне за даржаву обидно.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[18]: Немного попридираюсь...
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 15.06.06 08:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>алгоритм там настолько примитивный что накосячить практически не возможно.


Это ты оптимист Для косяков, ИМХО, всегда место есть.
Re: Проект Singularity: обзор
От: minorlogic Украина  
Дата: 15.06.06 19:01
Оценка:
Здравствуйте, Михаил Купаев (перевод), Вы писали:

МКП>Статья:

МКП>Проект Singularity: обзор
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


МКП>Авторы:

МКП> Михаил Купаев (перевод)

МКП>Аннотация:

МКП>Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

В любом случае тесты на производительность , выглядят мягко говоря нелепо ...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.