Здравствуйте, 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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Да вообще-то практически любой драйвер, если ты, конечно, не хочешь чтобы сетевая карта жрала 30% процессорного времени, а на GeForce 5200 можно было играть только во второй Quake. WH>Читай отчет по сингулярити еще раз. Там специально для тебя есть раздел в котором сравнивается производительность.
Здравствуйте, WolfHound, Вы писали:
A>>Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности. WH>А причем тут винда и интероп?
Насколько я понял права per executable в Singularity присутсвуют.
Здравствуйте, adontz, Вы писали:
A>>>Ну да прямо. Зайди на pinvoke.net и погляди сколько там интеропов с атрибутами подавляющими проверки безопасности. WH>>А причем тут винда и интероп? A>Насколько я понял права per executable в Singularity присутсвуют.
Не понял.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Там нет ничего про видеодрайверы. WH>Но есть про сеть.
TCP-стек Singularity не полностью совместим с IPv4
Не ясно что сравнивалось. Полная реализация может иметь другие показатели.
Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.
FastEthernet поддерживающий скорость 100МБит/сек существует с 1992 года.
GigabitEthernet поддерживающий скорость 1000МБит/сек существует с 1996 года.
В данный момент за окном наблюдается 2006 год.
Здравствуйте, adontz, Вы писали:
A>Ну аналог CAS, когда программа будучи запущенной под админом всё равно имеет ограниченные права.
Ты вобще статью читал? А про то как обеспечивается безопасность в этой ОС читал?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Не ясно что сравнивалось. Полная реализация может иметь другие показатели. WH>Может иметь, а может и не иметь.
Вот именно, так что в топку такие тесты.
A>>
Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.
A>>FastEthernet поддерживающий скорость 100МБит/сек существует с 1992 года. A>>GigabitEthernet поддерживающий скорость 1000МБит/сек существует с 1996 года. A>>В данный момент за окном наблюдается 2006 год. WH>Это голая пропускная способность железа. Тут же речь идет о весьма навороченом протоколе.
Какой такой протокол? Ясно же написано
Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек
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? _Очень_ сомнительно...
Здравствуйте, 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) А. Эйнштейн
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 (тоже в зависимости от системы).
Здравствуйте, 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? Прошлый век!
Все проверки при работе с 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) А. Эйнштейн
AS>>Назови примеры успешных управляемых сред, используемых достаточно широко? WH>.NET, Java. Достаточно? На этих технологиях наколбасили кода я так думаю побольше чем на С++. При том что С++ намного старше.
В данном случае мы говорим про операционные системы, а не меряем пенисы в виде количества кода С++ и Джава. Давай не отклоняться от темы, ок?
WH>>>Теоритически ни Оберон ни Оберон ОС ничего не стоят. Оберон примитивнеший язык с совершенно дурацким синтаксисом. Оберон ОС AS>>Ответ не верный. Постоянная проверка — гарантия тормозов. WH>Проверка проверке рознь. Если эта проверка сделана статически, а большинство проверок можно выполнить статически...
Ровно как и для неуправляемого кода. Пример уже приводили.
AS>>Введением подписи. Уж синхронизировать их (а тем более в одном бинарнике) проблемы не будет, а? WH>И кто будет подписывать? К томуже с таким подходом придется подписывать абсолютно весь софт в то время как в сингулярити нужно подсписывать только небольшую группу драйверов. Объем работы отличается на несколько порядков.
Подписывать их будет компилятор, который сгенерил данный бинарник. Ведь никто не отменяет _текущие_ ограничения, это лишь вспомогательная информация.
AS>>Ты действительно так думаешь? Ну... мне тогда нечего сказать. WH>Именно. Например и тогоже отчета пример драйвера для S3Trio 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. Не сильно медленней. И это при том что сообщение может быть любого объема.
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) и паттерны. Что же тут такое, а? Объясни мне, а то спать спокойно не смогу
Здравствуйте, 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) А. Эйнштейн
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, но в данном случае мне просто лень):
Получаем экзешник размером 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>А у меня ты чего спрашиваешь? Я чтоли эти тесты проводил.
Ты утверждаешь, что эти тесты валидны. Будь добр обосновывать свои утверждения. Иначе смысл разговора, согласись?
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 (С цифрами здесь)
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, Андрей Хропов, Вы писали:
АХ>В общем-то на основе идей одной из предыдущих версий Minix Линус Торвальдс написал Linux.
Нет. Торвальдс написал Линукс, чтобы использовать его как замену Миниксу, потому что в тот момент лицензия на Миникс была несвободная. Но вот по архитектуре эти 2 системы ничего общего не имеют. У Торвальдса — монолит с динамической загрузкой модулей, а у Танненбаума — микроядро. У них по этому поводу даже спор был, их переписка довольно известна, поищи на сайте Миникса. Танненбаум даже как-то в сердцах высказался, что будь Торвальдс его студентом, он у него за такую архитектуру "неуд" бы получил
Супер. Это пять. Мы говорим про безопасность приложений (то бишь гарантию того, что неправильно написаный драйвер не вынесет всю систему) или про внешнюю безопасность? Это как бы ортогональные вещи. Внутреняя безопасность — это проблемы драйверов и системных сервисов. 
Все сводится к тому, что "IL это безопасно, потому что безопасно и типизированно, .нет — это хорошо и прогрессивно". По мне — это плохая аргументация. Ровно так же много лет назад говорили про защищенный режим 386. К чему это привело сейчас — знают все.
