Проект 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: Проект 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[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[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[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[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[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[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[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[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[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) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.