Принципы работы kvm и qemu

каждый гость это отдельный физический процесс хосте-машины

а как еще может быть?

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

каждый гость это отдельный физический процесс хосте-машины. Где же тогда изоляция виртуальной и реальной среды???

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

Сохраняют ли гостевые ос какие-либо данные в свопе хост-машины или только в своем свопе?

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

Да, гостевая ОС - отдельный процесс. Почему беспокоит именно своп? Если есть доступ к хосту - есть доступ ко всей его памяти. Пока что нет виртуалок/гипервизоров, которые можно было бы запускать на скомпрометированном хосте. Научные работы в эту сторону, хоть и медленно, но ведутся: Опубликованы исходные коды HElib

Цель не в том, чтобы запускать ВМ на скомпроментированных хостах. Цель ограничить все возможные утечки информации с гостя на физическую ОС (на жесткий диск, в частности из-за свопа).

Вот я и хочу узнать имеет ли смысл отключать своп только в ВМ или и на хосте нужно?

Цель ограничить все возможные утечки информации с гостя на физическую ОС (на жесткий диск, в частности из-за свопа).

С хоста на гостя? А какой смысл? Рут на хосте может снять полный образ памяти виртуалки.

Можно и не отключать. Можно зашифровать. И сказать посредством madvise на хосте, чтобы процессы qemu/kvm высвопывались в последнюю очередь.

С хоста на гостя? А какой смысл? Рут на хосте может снять полный образ памяти виртуалки.

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

образы виртуальных дисков там тоже доступны...

Ну, может речь о данных, которые обрабатываются чисто в памяти b не сохраняются на диск. Но всё равно желание странное.

тебе Xen подойдёт для этого или какой-нить экзотический lynxsecure или что-то в этом духе http://www.ghs.com/products/rtos/integrity_virtualization.html

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

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

Цель: гость выключается->удаляется все,что было о нем из озу и свопа.

А можно поподробнее про advice и какие средства шифрования...

KVM обеспечивает виртуализацию памяти с помощью /dev/kvm. Каждая гостевая операционная система имеет свое собственное адресное пространство, которое устанавливается, когда создается гостевая система.

Физическая память, которая назначается для гостевой операционной системы, является в действительности виртуальной памятью процесса.

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

Получается озу для kvm - своп физической ОС???

чувааак, почитай про виртуальное адресное пространство =)

Спасибо за совет, не поверишь, я представляю что это такое))

В процитированном написано так...

Xen не подойдет,там Linux в dom0, а нужна чистая хост машина,т.е. гипервизор поверх физ. ос.

Про madvise я ошибся, его недостаточно. Можно использовать mlock (http://linux.die.net/man/2/mlock), но с таким подходом легче выключить своп. Ещё можно попробовать как тут советуют http://unix.stackexchange.com/questions/10214/per-process-swapiness-for-linux

Что до шифрования - вот пример для убунты http://iwtf.net/2010/01/05/encrypting-your-ubuntu-swap-partition/

Ну, или можно зашифровать все разделы на хосте и использовать своп-файл на одном из них вместо раздела.

Получается озу для kvm - своп физической ОС???

Нет. Получается озу для kvm - это в том числе и своп физической ОС.

mlock было бы хорошим стандартным решением, но наверно проблемно будет найти начальный адрес, длину в памяти. mlockall с флагом MCL_CURRENT подошло бы - блокирует своппинг вызвавшего процесса,но как проникнуть в процесс гостя, перекомпилировать kvm если только.

Спасибо за ссылку, поизучаю этот способ

man shrade