OSDev

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

"Например, это жёсткий диск с его контроллером." - здесь "жёсткий диск" оевидно означает устройство, а не хранимые данные ( иначе абсурд: данные с их контроллером).
Далее "Контроллер диска действительно разделить нельзя" :)
Понимая "диски" в вышеприведённом контексте, "диски делить приходится постоянно" означает разделение не данных а устройств (а этого никто не делает).
Кто из нас тут говорит глупости? :lol:
Кстати, для SCSI это не вегда верно, но не будем лезть в дебри. :)

Ниже "диск" означает не устройство, а совокупность данных на нём.
Отображать виртуальный диск на физический можно либо транслируя LBA, либо " закрывая (делая недоступным) "чужой" раздел в MBR. Оба варианта имеют свои преимущества и недостатки.
И, конечно, ОС, разделяющие диск, никак не могут (и не должны иметь возможности) определить, что имеют дело с виртуальным диском.
Объясняю подробнее. Если нужно, чтобы две ОС имели доступ каждая к своему разделу диска, то этот диск выделяется не им, а серверу диска (третьей ОС), который предоставляет каждой ОС виртуальный диск, так что обращения к секторам виртуального дика преобразуются к обращениям к соответствующим секторам физического диска (кроме нулевого цилиндра). Понятно, или нужно разжевать ещё подробнее?
Кстати, Я предпологаю разделение дсика между ОС как "каждой ОС свой раздел". Это-ли Вы имели в виду? Если нет, то что?

Про x386 у меня где-то была ссылка с перечислением всех (как помню, 18) проблем (хотя достаточно и одной). Если найду, сообщу. А мне вполне достаточно того, что они есть, что означает невозможность написания простого гипервизора для x86 процессоров которые не имеют аппаратной поддержки виртуализации.
Кстати, для меня утверждения VMware, что если полостью полагаться на аппаратную поддержку, то получается несколько медленнее, чем у них, не являются достаточным основанием для существенного усложнения гипервизора.

В двух словах: никто не хакает network drive, то что у меня этот drive на виртуальной машине неелает его более уязвимым.

Система "склеенная из нескольких ОС" не может быть так-же легко поражена нападением извне, как монолитная система, в которой проникнувший вирус имеет доступ ко всему сразу.

Каждый сервер выполняет относительно простые действия (даже если он, например сделан из Windows, большинство их функциональности просто отключается, а Linux даже компилируется в урезанном виде). А если сервер - это "микро-ОС" написанная Вами, то она проста, ясна и, поэтому, хорошо отлажена.

Кроме того, у меня отсутствуют неучтенные "паразитные связи" между компонентами практически незбежно возникающие в больших и сложных ОС (обычно, они-то и есть причина уязвимостей). К примеру, buffer overrun не навредит никому вне тукущей ВМ, драйвер модема не сможет поставить search bar (бывает и такое - модем был немедленно отправлен в помойку).

А по поводу изоляции от железа:
- Легко достигается контроль за поведением программ.
- К сожалению производители сами пишут драйверы для виндов и никому не говорят как с их железкой работать. И что делать?
- Даже если Вы знаете, как работать с конкретной железкой, вам удобнее писать независимую программу (сервер устройства), чем взаимодействовать с "большой" ОС (писать драйвер).
- Каждый сможет писать свой сервер как захочет и все они смогут успешно работать вместе.
- Можно писать свои ОС не беспокоясь о разнообразии устройств.

alexei



Вы, уважаемый, говорите глупость, Вы. Делятся именно физические устройства -- диски, а разделение информации на них -- лишь следствие деления контроля над аппаратурой. Например, каждой из виртуальных машин выделяется часть диска (если угодно -- раздел, хотя это вовсе не обязательно). И от того, SCSI диск, ATA или вообще доисторический мэйнфреймовый, ничего принципиально не меняется. И как же Вы собираетесь работать с такими "разделёнными" дисками? Как я понял, Ваш ответ вот:



Начну с конца. "Каждой ОС свой раздел" -- это частный случай. Разделов может не быть вовсе (в конце концов, разделы в том виде, что мы имеем, обязаны своим появлением небольшой конторе из Редмонда и являются не слишком удачной идеей). Если говорить обобщённо, каждой виртуальной машине предоставляется произвольная часть диска, не обязательно состоящая из смежных секторов. Впрочем, это замечание не меняет картину принципиальным образом.

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

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

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



Знаете, Ваш ответ показывает, что Вы "слышали звон, да не знаете, где он", ну или говоря проще -- плохо знаете матчасть, в данном случае архитектуру IA32 (она же x86). Прошу не рассматривать это как личный наезд: как человек Вы мне совершенно неизвестны, и делать вывод, что в "общечеловеческом" плане Вы из себя представляете, мне просто не на чем. Мой наезд касается исключительно Вашей... гм... скажем так, квалификации в вопросах системного программирования.

Мне упомянутый список не требуется: если я посижу да подумаю, я и сам его составлю. Сходу могу назвать как минимум две причины: в IA32 есть целый ряд команд, которые сообщают программе пользовательского режима параметры, напрямую связанные с управлением памятью; кроме того, команды загрузки селекторов сегментов (типа mov ds, ax или там длинных переходов) также являются непривилегированными, что не даёт возможность проконтролировать их использование сколько-нибудь нормальным образом.

Итак, как технически, а не в общих словах, Вы собираетесь предоставлять доступ к одному диску нескольким гостевым системам?

Ну во-первых спор о том кто глупее по поводу "деления" диска, похоже, чисто лингвистический :) Делить (="share"="совместно использовать") диск в смысле "контроля над аппаратурой" нельзя, т.к. эта аппаратура совместное использование (т.е. параллельное обслуживание запросов), т.е. "разделение" не поддерживает.
Разделение устройств (например, принтера - shared printer) обеспечивается ОС путём последовательного использования аппаратуры принтера, при этом аппаратура прнтера не разделяется в смысле "не используется совместно" в смысле "не используется одновременно"..
Можно ли вместе пить из одной бутылки? Оба возможных ответа могут быть названы глупыми (с объясненияим основанными на противоположной интерпретации контекста).
Менять контекст по мере объяснения не приято.

MBR - формат весьма распространённый. См. наприер http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
Естественно иметь хоть какую-то совместимость с другими ОС.

Взаимодействие "гостевых ос" с сервером диска.
Коротко о "гостевых": у меня нет закреплённых Host и Guest "ролей", хотя в отношении конкретного ресурса можно говорить о Host-Guest отношениях.
Итак, Гипервизору (ГП) из описания сервера или от самого сервера известно, какой ресурс этот сервер предоставляет. Аналогично, некая ОС запрашивает и получает этот ресурс.
В ресурсом может быть:
1. виртуальное железо: емулятор на сервере, "обычный" драйвер на ОС
2. отображённое железо: транслятор на сервере, "обычный" драйвер на ОС
3. абстрактное устройство: socket на сервере, специальный драйвер на ОС
Естественно, п.3. может иметь множество разновидностей.
Предвижу вопрос: А какой конкретный протокол?
Ответ: любой, какой сочтёте нужным. ГП предоставляет поддержку для "inter-VM communications", т.е. межмашинного обмена. Предполагается, что автор сервера, использующего собственный протокол, опишет этот протокол и преставит клиента для одной или более ОС (ему он всё-равно нужен для отладки и тестирования).
Предвижу вопрос: А какую ГП предоставляет поддержку?
Ответ: предполагаю: pipes, shared memory, interrupts, read/write traps, хотя детали прояснятся в процессе разработки.

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

Кстати, "тогда гостевая ОС сможет похерить чужие разделы, поскольку будет считать, что занимаемое ими пространство не используется)" - неврно, т.к. MBR виртуальная даже в этом случае и сервер диска не даст её в обиду "гостям".

LBA+n, где n - это сешение выделенного раздела от начала диска.Чего тут объяснять?

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

Повторяю. Здесь обсуждается архитектура и возможности системы. Детали реализации важны только если они существенны для этого обсуждения.

Вообще-то хотел узнать мнение разработчиков "самодельных" ОС к моей концепции. Пока кроме вопросов ничего не получил :(

Управление памятью и распределение процессора гораздо более интересные темы...

Блин, клепают ведь оси на коленке, которые очевидно пойдут коту под хвост, а сделать среду, чтобы каждый не писал всё с начала, никому не интересно. :(

alexei

Ладно, лингвистический спор оставим в стороне.



П. 3 предполагает написание специальных серверов, а значит, исключает использование в их качестве уже существующих ОС. Ну а поскольку Вы предлагаете использовать в качестве серверов, пускай и "для начала", уже существующие системы, значит, остаются только пп. 1 и 2. Однако существующие ОС обращаются к аппаратуре напрямую и ни о каких "серверах", осуществляющих "трансляцию", не ведают. Таким образом, Вам необходимо перехватывать все обращения к аппаратуре и 'эмулировать' эту самую аппаратуру. Перехват проблем не представляет: грубо говоря, "серверы", в том числе гостевые ОС, работают в третьем кольце защиты, поэтому их попытка обращения к портам ввода-вывода или к ячейкам памяти, находящимся за пределами выделенных им областей, вызовет прерывание, которое попадёт на обработку гипервизору или другой программе, которую назначит на эту роль гипервизор. Однако эмуляция представляет собой очень большие проблемы. В частности, эмулировать придётся все стандартны устройства ПК и стандартные технологии вроде PnP, ACPI и т.д. -- без такой поддержки обычные ОС под этим самым гипервизором просто не будут работать. А значит, надо писать не некий абстрактный и простенький "гипервизор", а полноценную систему виртуальных машин. Эта работа посложнее будет, чем написать обычную операционку со всеми необходимыми драйверами.



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



Это из той же серии. "Гладко было на бумаге, да забыли про овраги". Что это возможно технически, я прекрасно знаю и сам. Но пока что, повторюсь, вижу только то, что Вы понятия не имеете, как всё это осуществляется на практике.



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



Пожалуйте без вопросов: если одним словом -- бред. Ну а почему я так считаю, в общем я уже говорил выше, но повторюсь: Ваша концепция предполагает создание полноценной системы виртуальных машин, т.е. полного набора эмуляторов "железа", что для ПК очень трудоёмко, долго и нудно; кроме того, создание эмуляторов сильно осложняется отсутствием спецификаций на часть "железа".



"Ватсон, это элементарно". Как раз управление памятью и разделение процессора не представляют никаких сложностей и реализуются очень просто. Если бы для написания ОС требовалось бы реализовать только многозадачность и виртуальную память, то ОС реально было бы написать и отладить за несколько дней, максимум -- за пару-тройку недель.



Такая среда -- это любая уже существующая работоспособная ОС. Там программист избавлен от необходимости разделять процессор, распределять память и управлять внешними устройствами. Но почему-то некоторым упорно хочется всё это реализовать собственными руками. Мазохисты, однако :)

alexei, я же тебе с самого начала сказал, что на практике это сделать нереально! Из аппаратуры настоящую эмуляцию позволяют выполнять лишь процы последних моделей, а о том, чтобы другое оборудование, с которым приходится иметь дело, поддерживало эмуляцию, сейчас речи вообще не идет - это неактуально. Поэтому тебе нужно либо эмулировать всю имеющуюся аппаратуру, либо продолжать теоретизировать дальше.

В общем-то любая ОС уже является такой средой, где не надо писать всё с начала. Поэтому если очень захочется использовать другую ОС, то проще внедрить свой драйвер или любой модуль в существующую ОС, без лишнего геморроя с виртуальными интерфейсами, которые ни кто ни когда не будет поддерживать.
Phantom-84, на самом деле эмулировать надо не всю имеющуюся аппаратуру, а только стандарные устройства. А остальные надо делать невидимыми через виртуализацию шины PCI (чтобы устройства не видели несколько ОС одновременно), хотя всё-равно придётся их как-то распределять.

Phantom-84


Ну так я пытался подвести Алексея к осознанию того факта, что его рассуждения, в которых он не желает опуститься на грешную землю и обратить, наконец, внимание на реальное "железо", его возможности и особенности, являются фактически переливанием из пустого в порожнее...

Chizh



PCI фактически относится к стандартной аппаратуре, а значит, нужно будет эмулировать и её (конфигурационное пространство PCI, точнее). Естественно, при опросе этой виртуальной шины надо будет показывать только стандартные устройства, к которым есть эмуляторы.

Правда, есть ещё один вопрос: а как быть с "нестандартными" устройствами? Например, есть какой-нибудь SCSI-контроллер, с которым гипервизор работать не умеет (нет драйвера). Удастся ли его просто передать в ведение какой-либо из гостевых ОС? Я над этим вопросом как-то особо не задумывался...