Здравствуйте, WolfHound, Вы писали:
WH>Я склоняюсь к мнению что примитивом общения между процессами должны быть каналы аля сингулярити. WH>Собственно зависимыми типами можно проверять что протокол отработан верно и что канал будет непременно закрыт.
Тут зависимые типы не причем, достаточно строгой типизации. А насчет "закрыт" — пусть этим подсистема общения занимается.
WH>Плюс можно доказывать отсутствие циклов и прочих задержек в критичных по времени местах.
В общем случае не можно. Можно лишь специальным образом организованные рекурсии таким способом ограничивать. И то, более-менее доступно это пока лишь в С++, а в остальных местах на уровне игр и экспериментов.
Здравствуйте, WolfHound, Вы писали:
PD>>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно WH>Да мне плевать как. Главное что вирусы пролезают в ядро не смотря на аппаратную защиту.
Они могут туда пролезть, только предварительно проинсталлировав себя в систему (что не требует уровня ядра) и загрузившись как один из системных файлов при последующей загрузке OC. Отсюда мораль: не сидите в и-нете под админскими правами.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
Это всё малоинтересно. С точки зрения пользователя, самое страшное уже произошло — в коде оказалась ошибка, и запрошенную операцию выполнить не удалось. То, что ядро системы продолжает успешно работать, никому (кроме авторов ядра) неинтересно*. Это и есть та причина (а вовсе не производительность), по которой обеспечение иммутабельности переменной при помощи аппаратной защиты никому не нужно.
Интересно иметь до начала выполнения программы гарантии того, что даже и попыток выполнить недопустимую операцию не будет.
(*) — нет, я понимаю, что бывают ситуации, когда в одной среде выполняются приложения с разными классами требований. Грубо говоря, не хочется, чтобы управление впрыском в двигатель заткнулось от того, что отвалился MP3-плеер. Но аппаратная защита всего лишь спасёт управление впрыском от ошибок в плеере; спасти управление впрыском от ошибок в управлении впрыском она не может. А вот статическая верификация — может. А то вон Титаник был оборудован превосходной аппаратной защитой от затопления — даже лобовое столкновение с айсбергом не утопило бы его; пострадала бы только носовая часть. И где теперь Титаник? А вот система, которая бы гарантировала отсутствие столкновений с айсбергами, позволила бы вовсе отказаться от дорогостоящих внутренних переборок, сократив вес и расход топлива
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ili, Вы писали:
ili>>эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник. WH>Очень важная поправка: Верифицированный нативник.
гут. согласен. но:
Или его со временем полностью вытеснит верифицируемый промежуточный код?
т.е. я правильно понял, что мы сошлись на мнении, что нативник останется, но (может) будет верифицированным?
WH>
WH>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
WH>ИМХО тут весьма неоднозначно подразумевается именно аппаратная защита.
ИМХО нет. в вопросе вообще ничего не говорится о способах реализации этой изоляции.
но, давате расставим точки над i. ввиду того, что не сказано иного, я предполагаю, что речь идет о самых распространенных платформах — x86 & Windows NT 5.
х86 использует сегментацию памяти, дискрипторы сегментов храняться в таблицах, нас интересуют две из них это GDT — глобальная таблица дескрипторов и LDT — локальная таблица дескрипторов. глобальная таблица — одна, локальных может быть много. таким образом, процессор дает возможность изоляции виртуальной памяти через отдельные LDT для каждого процесса.
сам по себе процессор ничего не изолирует, пользоваться этой возможностью или нет — вопрос к операционной системе.
у виндов есть механизм распределения виртуальной памяти через VMM. за изоляцию памяти приложений отвечает именно он (если я не прав — дайте ссылочку чего почитать, буду признателен). так вот, эти самые винды используют для всех приложений одну LDT — т.е. аппаратные возможности используются в этом случае по минимуму.
WH>С доказательствами по аналогии иди в другое место.
на сколько мне известно аналогия может служить источником выдвижения гипотиз, но никак не доказательств.
я же ее использовал как вполне (ИМХО конечно) сходний пример с поставленными автором топика вопросами.
тот же нативный код — фундаментальное определение, и деться как таковой они кикуда не может (это по определению тот язык который понимает процессор, другого он не поймёт, а значит не выполнит, и тут хоть гвоздь в него вбивай, хоть расплавить угрожай — не поможет).
разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет, ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю). опять таки детали реализации в данном случае ИМХО не суть важны. важно само явление.
про изоляцию приложений при помощи виртуального адресного пространства — собственно говорил выше. так или иначе, но оно все равно надо, как минимум для того, чтобы прикладной программист случайно не запорол память соседнего процесса. про детали равлизации вообще выше.
Здравствуйте, Mystic, Вы писали:
M>Да никаких не надо, надо выполнить одну ассемблерную команду.
Хм. И насколько она будет быстрее, чем вот такой код:
public static int RightMostBitNumber(long seq)
{
if ((seq & 0x1) == 0x1)
{
// special case for odd v (assumed to happen half of the time)return 0;
}
else
{
var c = 1;
if ((seq & 0xffffffff) == 0)
{
seq >>= 32;
c += 32;
}
if ((seq & 0xffff) == 0)
{
seq >>= 16;
c += 16;
}
if ((seq & 0xff) == 0)
{
seq >>= 8;
c += 8;
}
if ((seq & 0xf) == 0)
{
seq >>= 4;
c += 4;
}
if ((seq & 0x3) == 0)
{
seq >>= 2;
c += 2;
}
c -= (int) seq & 0x1;
return c;
}
}
?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ili, Вы писали:
ili>тот же нативный код — фундаментальное определение, и деться как таковой они кикуда не может (это по определению тот язык который понимает процессор, другого он не поймёт, а значит не выполнит, и тут хоть гвоздь в него вбивай, хоть расплавить угрожай — не поможет).
А разве кто-то говорит что нативный код куда-то денется?
Вроде как говорят что программисту не придется нативный код писать.
ili>разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет.
Если статически доказано, что не может программа ничего плохо сделать, то и не нужна защита.
ili>ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю).
Накладные расходы — огромные, переключение контекста из пользовательского режима в режим ядра — совсем недешевая операция.
Даже в существущих ОС есть тененция выноса больше кода в режим пользователя, чтобы уменьшить переключения контекста.
ili>про изоляцию приложений при помощи виртуального адресного пространства — собственно говорил выше. так или иначе, но оно все равно надо, как минимум для того, чтобы прикладной программист случайно не запорол память соседнего процесса. про детали равлизации вообще выше.
Если при компиляции доказано что он не может это сделать, то рантаймовые проверки не нужны.
M>В случае GC подобную схему я вижу, например, только в такой реализации: время от времени я спрашиваю GC о том, какой размер памяти выделен динамически. Как только он превышает некоторое критическое значение, я должен освободить неактуальные позиции. Т. е. сделать их недостижимыми. Т. е. обнулить все ссылки на них. После этого я вызываю метод GC который бы форсировал освобождение кучи. Тут, конечно, возможны утечки: например я не сделал объект недостижимым и его не освободил GC. Но, главное, я очень сомневаюсь, что работа GC в таком режиме будет сопоставима по скорости с ручной работой.
Мое мнение, что при работе с большим количеством однотипных объектов, проще работать с ними как с массивом структур, по аналогии с кучей на массиве сос писком свободных позиций (либо если нет удалений то последняя заполненая позиция), а ссылка представляет собой структуру и ссылки на массив и индекс в этом массиве. (При отходе с объектов на структуры выигрыш 12 байт)
Так снимается нагрузка с GC, а сами эти массивы используй как пул для повторного использования.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ili, Вы писали:
G>А разве кто-то говорит что нативный код куда-то денется? G>Вроде как говорят что программисту не придется нативный код писать.
скажите, когда вы в последний раз писали нативный код? уже чертову уйму лет нативный код генерят компиляторы.
ili>>разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет. G>Если статически доказано, что не может программа ничего плохо сделать, то и не нужна защита.
защита-то никуда в этом случае не делась, она просто обеспечивается другим механизмом. о чем я и талдычу.
G>Накладные расходы — огромные, переключение контекста из пользовательского режима в режим ядра — совсем недешевая операция.
можно, пожалуйста, метрики? мне они не известны, с удовольствием бы ознакомился.
повторюсь, я с проблемами такого рода не сталкивался, о чем честно и не скрывая сказал, т.е. мои выводы основаны на моем опыте.
G>Даже в существущих ОС есть тененция выноса больше кода в режим пользователя, чтобы уменьшить переключения контекста.
готов принять это как аргумент, только имея перед глазами метрики.
G>Если при компиляции доказано что он не может это сделать, то рантаймовые проверки не нужны.
защита-то никуда в этом случае не делась, она просто обеспечивается другим механизмом. о чем я и талдычу.
Очевидно, что обеспечение безопасности кода крайне существенно. В настоящее время Singularity полагается на проверку исходного и промежуточного кода компилятором. В будущем типизированный ассемблер (Typed Assembly Language, TAL) позволит Singularity проверять безопасность скомпилированного кода. TAL требует, чтобы исполняемый модуль программы предоставлял доказательства своей типобезопасности (что в случае безопасных языков может делаться компилятором автоматически). Проверка корректности таких доказательств и того, что они применимы для инструкций в исполняемом модуле – прямолинейная задача для простого верификатора из нескольких тысяч строк кода. Такая стратегия сквозной проверки исключает компилятор – большую, сложную программу – из проверенной основы Singularity. Верификатор должен быть тщательно продуман, реализован и проверен, но эти задачи вполне выполнимы благодаря его простоте и размеру.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ili, Вы писали:
ili>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, ili, Вы писали:
G>>А разве кто-то говорит что нативный код куда-то денется? G>>Вроде как говорят что программисту не придется нативный код писать.
ili>скажите, когда вы в последний раз писали нативный код? уже чертову уйму лет нативный код генерят компиляторы.
Вы пишите нативный код на C\C++\Delphi
G>>Накладные расходы — огромные, переключение контекста из пользовательского режима в режим ядра — совсем недешевая операция.
ili>можно, пожалуйста, метрики? мне они не известны, с удовольствием бы ознакомился. ili>повторюсь, я с проблемами такого рода не сталкивался, о чем честно и не скрывая сказал, т.е. мои выводы основаны на моем опыте.
С метриками туго, так как почти нет реализаций без разделения user\kernel.
В доках по Singularity есть тесты некоторого функционала, можно там посмотреть.
Здравствуйте, gandjustas, Вы писали:
G>Вы пишите нативный код на C\C++\Delphi
Машинный код (также употребляются термины собственный код, или платформенно-ориентированный код, или родной код, или нативный код — от англ. native code) — система команд (язык) конкретной вычислительной машины (машинный язык), который интерпретируется непосредственно микропроцессором или микропрограммами данной вычислительной машины.
писать нативный код, это, писать бинарник. на C\C++\Delphi вы пишите на C\C++\Delphi — а их компиляторы герерят нативный код, или объектные модули
.Net компиляторы генерят PE код, который потом CLR компилит в нативник, который и исполняется процессором.
G>С метриками туго, так как почти нет реализаций без разделения user\kernel. G>В доках по Singularity есть тесты некоторого функционала, можно там посмотреть.
Здравствуйте, thesz, Вы писали:
WH>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.
T>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).
Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно. WH>>Расскажи это писателям вирусов...
PD>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно
Он гонит Вирусы всегда лезли в ядро через софт. Устанавливаясь драйвером, например. Или записывая себя с существующие драйвера. Или переключаясь в режим супервизора сервисом ОС (в 9x, привет WinCIHу).
Хотя, на самом деле, есть ошибки в процессорах, позволяющие влезть в SMM. Правда, для этого сначала надо получить права супервизора. (Вернулись к тому, с чего начали). К тому же дальше PoC публикаций это не пошло, баги аффектятся к ограниченному кругу моделей, вендоры в курсе и баги уже исправили.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Исполнять его. Без верифицируемого процессора придется тебе все же исполнять неверифицируемые команды верификатора. Где гарантия, что этот код не содержит ошибки и сам не испортит что-то ? WH>bootstrap сводит эту вероятность практически к нулю. WH>И даже если что-то проскочит обновить софт куда как проще чем обновить железо.
PD>>В то время как в модели user/superwisor это решено аппаратно. WH>А где гарантия что нет ошибки в железе?
Здравствуйте, jedi, Вы писали:
J> Спасибо, рассмешил. J>Меня вот удивляет откуда такие знатоки всего беруися?
Дык а он у нас тут местный "знаток" всего на свете. Особенно в КСВ.
Здравствуйте, vdimas, Вы писали:
WH>>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить... V>Ну вот С++ на зависимых типах построен,
Чё?!
В С++ нет зависимых типов.
V>Для написания того же банального GC необходимы аналогичные способы реинтерпретации памяти... Так что насчет "всё проверить" очень спорно, разве что лишь имеется ввиду проверить "все остальное". А что по твоему разработчик ГЦ будет ручками память ковырять?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Тут зависимые типы не причем, достаточно строгой типизации.
Какой типизации?
V>А насчет "закрыт" — пусть этим подсистема общения занимается.
Какая еще система? Кто этой системе скажет что канал больше не нужен?
V>В общем случае не можно.
Можно. Учи матчасть.
V>Можно лишь специальным образом организованные рекурсии таким способом ограничивать. И то, более-менее доступно это пока лишь в С++, а в остальных местах на уровне игр и экспериментов.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IID, Вы писали:
IID>Он гонит Вирусы всегда лезли в ядро через софт. Устанавливаясь драйвером, например. Или записывая себя с существующие драйвера. Или переключаясь в режим супервизора сервисом ОС (в 9x, привет WinCIHу).
Мне-то ты зачем это объясняешь ? . Ему объясни. Хотя сомневаюсь, что это получится — если человек в состоянии назвать MySQL дисковой подсистемой, то объяснять дальше бесполезно
Здравствуйте, ili, Вы писали:
ili>т.е. я правильно понял, что мы сошлись на мнении, что нативник останется, но (может) будет верифицированным?
Нативник останется только деталью реализации.
Он никому кроме ВМ не будет виден. Так же как и сейчас никто не видит то что делает JIT.
ili>тот же нативный код — фундаментальное определение, и деться как таковой они кикуда не может (это по определению тот язык который понимает процессор, другого он не поймёт, а значит не выполнит, и тут хоть гвоздь в него вбивай, хоть расплавить угрожай — не поможет).
Вот только ты не сможешь загрузить из интернета нативный код и запустить его.
Можно загрузить только промежуточный верифицируемый код из которого будет сделан нативный на месте.
Те никакого распространения программ в виде нативных бинарников не будет это и есть смерть нативного кода.
ili>разделение режжимов ядра и прикладного\пользовательского — тоже, как минимум это защита операционной системы и ее данных. прикладной программист туда случайно не залезет и ничего не грохнет, ИМХО уже это оправдывает все накладные расходы (которые по сути то не так уж и велики, я вот от них еще никогда не страдал, и людей которые страдали — не знаю). опять таки детали реализации в данном случае ИМХО не суть важны. важно само явление.
Еще раз автор вопроса весьма не однозначно имел в виду аппаратную изоляцию, а не изоляцию вообще.
ili>про изоляцию приложений при помощи виртуального адресного пространства — собственно говорил выше. так или иначе, но оно все равно надо, как минимум для того, чтобы прикладной программист случайно не запорол память соседнего процесса. про детали равлизации вообще выше.
Если весь код верефицируемый то программист физически даже если очень сильно захочет не сможет ничего запороть даже в своем процессе не говоря уже про соседний.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Спасибо, рассмешил. 
А что по твоему разработчик ГЦ будет ручками память ковырять?
